What I Wish I Knew 20 Years Ago as a Software Engineer
Key lessons I wish I had known earlier in my career—focusing on problem-solving, collaboration, and lasting impact.
When I started out, I thought being a good engineer was all about writing complex, elegant code. I spent hours optimizing for performance, thinking that shaving off milliseconds was the key to building great software. But over the years, I’ve realized that none of that matters if your code can’t be maintained or scaled.
Here’s what I’ve learned:
Solve the problem, not just the code.
Too often, we get caught up in the technical details and forget the bigger picture. The best engineers start by understanding the problem deeply before even thinking about a line of code. The solution always starts with clarity on the problem itself.
Documentation isn’t optional.
This was a lesson I learned the hard way. In fast-paced environments, documentation often feels like a nice-to-have. But six months down the line, when a new feature breaks and you’re sifting through undocumented code, you’ll realize the true cost of skipping it. Good documentation is an investment in your future self.
Refactoring is an ongoing process.
I used to think refactoring was something you did when the codebase was a mess. Now I realize it’s a constant part of development. Clean, maintainable code isn’t the result of a single effort—it’s a habit. Every time I touch a piece of code, I ask, “Can I make this clearer? Can I reduce complexity?”
Your team matters more than your code.
Early in my career, I thought being a great engineer meant being the smartest person in the room. What I know now is that the best engineers are the ones who lift up their team. Great communication, mentoring, and collaboration will take your career much further than optimizing a single function ever will.
Technology changes, principles don’t.
The tech stacks I worked with 20 years ago are outdated now, but the principles of good software design haven’t changed. Focus on mastering concepts like SOLID principles, clean architecture, and system design. These will outlast any framework or language.
If I could go back, I wouldn’t change the technical challenges I obsessed over, but I would change how I approached them. The real goal isn’t just writing great code—it’s about creating solutions that last, working well with your team, and building software that makes a real impact.