What truly made me a better Software Engineer
Lessons I wish I had learned earlier in my career
Background
Every job experience I had taught me something new, and I always took notes about the soft and hard skills I needed to improve. Over time, I compiled a list of underlying topics that, in my opinion, every developer should know.
So, I’m here to pass along the knowledge that actually made me a better Software Engineer.
Fundamental Principles
Testing
In my first years as a Software Engineer, I worked at companies that didn’t write a single line of tests. Because of that, I picked up the bad habit of creating side-projects without writing tests either. Later, testing became a more frequent topic in my life. I was listening to several experienced engineers and studying engineering more seriously, and they gave me convincing arguments that made me realize tests are not just “nice to have”, they are essential.
I tried to adopt tests around my second year of experience, but at that time, I wasn’t fully convinced. I had the classic beginner thought: “Tests slow me down.”
I believed writing tests was making my development slower, and many Junior and Mid-level engineers feel this way.
After gaining more experience, I realized the complete opposite: tests make development faster. They prevent bugs, they give confidence, and they save enormous amounts of time in the long run. And depending on the type of project you work on, a bug can kill people or waste millions, even billions of dollars.
Ariane 5 Rocket Failure (1996):
A $370 million rocket self-destructed 40 seconds after launch because a small piece of software was reused without re-testing it under the new rocket’s conditions.
Guidelines that I currently follow:
Create tests for every feature: Your tests should mainly cover the business rules. Avoid writing the implementation first. Start by creating the test suite, reviewing the requirements, writing your first failing test describing exactly what the feature should do, and then refactoring the code until the test passes.
Create tests for every bug fix: Write a test that reproduces the bug (and make sure it fails). Fix the bug and the test should pass. For every bug fix, write a new test to reproduce the issue. This prevents the bug from ever coming back.
TEST YOUR CODE.
Accountability
I think this is one of the most important abilities you can have as a Software Engineer. This isn’t about code, this is about who you are as a professional.
You need to develop a strong sense of ownership. Yes, you’re an employee, but you should act as if the SaaS is yours, as if the company is yours. Bring ideas. Think ahead. Push the company forward. People notice when you work like an owner.
When you receive a task, everyone should feel confident that you will deliver it. Becoming a trustworthy engineer is one of the most valuable things you can build in your career. Everyone wants someone reliable on their side.
We’re all paid to solve problems, so solve the problem someone is paying you for. Be good at this. Be consistent. Be transparent. Be reliable.
And most importantly: if you break something, say: “It was me. I’m fixing it.”
When people trust you, they give you more autonomy, more freedom, more important tasks, and more opportunities. Trust compounds fast.
Accountability is what turns you from a coder into an engineer.
Saying "No"
This is something I took a long time to learn. The business doesn’t understand the complexity of implementing feature X or Y, that’s your job. You need to think about possible approaches, bring pros and cons, and explain them clearly.
Sometimes stakeholders aim for deadlines that are simply impossible. And you don’t need to be “convenient” and say YES to everything. Your job is to say: “This is not feasible for this date.”
That's our responsability.
I made this mistake many times. I was afraid to say something wasn’t feasible, and it led me to spend several extra hours trying to hit unrealistic deadlines. This is unsustainable. Even worse: sometimes I delivered rushed “happy path only” solutions without proper testing just to meet a date. That makes you a bad engineer, a mediocre engineer. Quality is always your priority.
Your mission is to say: “Yes, this is feasible and it’ll take X time” or “No, this isn’t feasible because of X or Y.” And if something goes off track, communicate immediately. Plans change the moment reality changes. Owning that is part of being a professional.
Stakeholders will trust you more, and your company will profit more.
Communicating
Some engineers think that because they work remotely, they should “talk less.” It’s actually the opposite. When you work remotely, you need to be more proactive and communicate clearly and asynchronously.
If something is going off track, you must tell your tech lead or your team. They need to know. Silence creates bigger problems.
Assume
Don’t assume anything. Always confirm. Double-check information. Wrong assumptions waste the most valuable asset we have: time.
Assumptions lead to financial loss, security issues, data loss, and in some cases, literal destruction.
The Ariane 5 disaster is a perfect example. Engineers assumed that a software module from Ariane 4 would behave the same way in Ariane 5. It didn’t. The rocket exploded. $370 million gone because of one assumption.
Never assume. Validate everything.
Tech Debts
Don’t accumulate tech debts. If you know something is a code smell, avoid it. If you really need to ship quickly, take notes immediately and revisit it later. Don’t ignore problems you know will eventually explode.
Start documenting bugs, tech debts, and edge cases. Create tasks for them.
Future you and your team will thank you.
Books References:
The Pragmatic Programmer (Andrew Hunt)
The Clean Coder (Uncle Bob)