Mistakes I Made in My Developer Journey - Hopefully You Don’t Have To
A software developer’s career rarely follows a straight line. Early on, you’re just trying to make the code work. Later, you’re thinking about frameworks, job switches, leadership roles, and sometimes even wondering what it’s all for. This article is my attempt to help you avoid the mistakes I made.
Over the years, I’ve noticed that most developers tend to experience similar turning points in their careers. Of course, not everyone will follow the same path, but I have observed that this pattern is surprisingly common. This article is organized around those stages, each with reflections on what I learned (often the hard way) and what I wish I had done differently.
“How Do I Get This Done?” Stage
Struggling to make sense of how the code flows, or why file and function names don’t reflect what they actually do? Welcome to the real world of software development.
You’ve learned one programming language and one popular framework. You’re assigned tasks, and it takes time to figure out what files to touch, what logic to change, and how to avoid breaking things.
At this stage, completing the task itself is the challenge. You’re driven by deadlines, and the goal is simple: just get it to work. As you gain confidence, you begin thinking about clean code and maybe a bit of refactoring.
You finally know your way around the codebase. But every task still feels like an uphill battle.
Here’s a mistake I made during this phase:
Mistake - I stayed too long in it
Building new features was fun. I didn’t mind writing tons of code, even if it meant copying the same logic to five different places. Feature toggles in ten different files? Sure, if it got the job done faster.
What I didn’t realize then is that software maintenance has a real cost. Copy-pasted code feels efficient in the moment, but over time, it becomes a minefield.
One habit I’ve developed since then: After finishing a task, I ask myself, ‘If a new developer joined tomorrow, how long would it take them to understand and enhance this feature?’
Don’t just finish tasks. Leave them in a state you (or someone else) would want to revisit.
“I Want to Learn Something New” Stage
Once you’ve gotten comfortable building features, things can start to feel… routine. You start noticing all the exciting frameworks, libraries, and tools you’re not using at work, and that sparks a familiar itch: to chase the next shiny thing.
At this point, developers typically go in one of two directions:
- Look for jobs using new technology
- Start side projects to explore new frameworks and tools
Both are valid, but in my experience, building side projects is far more valuable over time. It gave me hands-on experience and helped me understand whether I actually liked working with those technologies. Reading tutorials is fine, but writing real code in a project of your own makes everything click.
What I did wrong during this phase:
Mistake - I focused too much on chasing frameworks, and too little on computer science fundamentals
If I could go back, I’d invest earlier in:
- Data structures and algorithms (not for interviews - practically)
- Database design and indexing
- Operating systems and networking basics
These concepts give you the mental models needed to debug production issues, reason about performance, and understand trade-offs in libraries and tools.
Like, once I truly understood how B-trees work, database indexing stopped feeling like magic.
“I Want to Be a Team Lead” Stage
After gaining experience, developers tend to diverge: Some stay on the individual contributor (IC) path, while others feel drawn toward leadership roles, often because it’s the default next step. But leadership isn’t for everyone, and it shouldn’t be taken for granted. In fact, it’s often easier to evaluate your fit for the IC path based on technical growth and performance.
If you’re considering a leadership role, ask yourself:
- Do you enjoy mentoring others?
- Do you have patience, empathy, and a genuine desire to help teammates grow?
These are the traits that make someone a good leader, not just experience or tenure.
In my view, effective team leads and engineering managers need more than strong people skills. There’s a heavy emphasis on technical leadership and management. You’re not just running one-on-ones or giving feedback - you’re identifying and clearing roadblocks, shaping the technical roadmap, managing tech debt, and ensuring the team is making smart technical decisions. Leadership in tech is about guiding both people and systems.
Here are the mistakes that I made:
Mistake 1 - Don’t choose the IC path just to avoid working with people
As an individual contributor, you may not be doing performance reviews or managing career plans, but that doesn’t mean you’re working in isolation. You’ll still be expected to mentor teammates, lead technical discussions, and engage in collaborative decision-making around infrastructure and architecture. As you grow, your responsibilities naturally expand to cross-team initiatives, where strong communication and collaboration become just as critical as your technical skills.
Mistake 2 - You need to actively develop your people skills
Even if you’re a team lead, giving meaningful feedback, running effective one-on-ones, mentoring juniors, and helping others grow doesn’t come automatically. Just like technical skills, these require deliberate practice, reflection, and continuous learning. Whether it’s practicing active listening, becoming more thoughtful in how you communicate feedback, improving your ability to navigate conflict, or coaching and mentoring others, these are all people skills you can intentionally grow with time and effort.
Whether you choose the IC or leadership path, people skills are essential. Collaboration, mentoring, and communication are just as important as writing good code.
The “What Am I Doing With My Life?” Stage
Turns out the mid-life crisis is real :). Maybe this is the point where you stop looking for answers in code and start searching for meaning beyond it. I’m still figuring this one out - and I imagine many others are too.
