I took a sales job I hated every single day for 10 months.
That was not the plan. I was an engineering graduate with big expectations. But the market did not care about my expectations. Most engineering jobs wanted 3 to 5 years of experience. I had zero. So I took what was available and spent 10 months doing work that had nothing to do with why I studied engineering.
It was one of the darkest times I have faced. My dreams for an engineering career shattered, like glass falling on a hard floor.
Then I made a decision. I quit, enrolled in a 6-month programming course, and spent 12 to 16 hours a day at the institute. I went home to sleep and eat. That was it. I came back and did it again.
That period led to 3 job offers as a web developer. And the start of a 26-year development career.
I'm sharing this because career planning advice usually comes from people who had a smooth path. Mine wasn't. If yours isn't either, keep reading.
Your first 2 to 3 years: build the foundation
The biggest mistake junior developers make is trying to optimize too early. They want the right company, the right tech stack, the right title. But in your first 2 to 3 years, you don't have enough information to optimize anything.
What you should do instead is absorb everything.
New concept you don't understand? Go deep on it. Production issue at 11pm? Stay and fix it. Bug that takes 4 hours when it should take 30 minutes? That's not wasted time. That's where the real learning happens.
Tutorials teach you the happy path. Troubleshooting teaches you how things actually work.
When something breaks and you have to figure out why, you end up learning 3 things you didn't know you needed to know. That compounds. A developer who has debugged 200 real problems is not the same as a developer who has watched 200 tutorials.
Go the extra mile in the first 2 years. Work late when it matters. Volunteer for the hard problems. Fix things nobody asked you to fix. This will help you build a reputation and a skill set faster than the timeline your job description allows.
You earn more trust fixing a production issue than writing perfect code in a vacuum.
How to spot and ride a technology wave
In 2002, Microsoft released .NET. I was already proficient in ASP, VB, and SQL Server. Most developers I knew were comfortable where they were. I saw .NET as a way to get ahead of the curve.
So I started learning it on my own time. I migrated my work projects into .NET to practice. Within a short time, I was one of a small group of developers who actually knew it. That led to a senior developer role at India's 5th most prominent software company.
The lesson is not "learn .NET." The lesson is: find the wave early, commit fully, and go deeper than everyone else.
I didn't have a formula back then, but looking back, here's what I was actually doing:
- It should be backed by a major platform or company (Microsoft, Google, Meta, AWS)
- It should solve a real problem, not just generate hype
- Adoption should be early but growing, not already mainstream
- It should connect to your existing skills so you're not starting from zero
Looking back, .NET checked every box: backed by Microsoft, solved real problems with the old ASP model, adoption was early but growing, and I already knew VB and SQL Server.
Right now, AI development, cloud-native architecture, and applied machine learning fit that description. But picking the trend is only step one. The developers who win are the ones who go deep, not wide. Pick one and commit to it for at least 12 months.
Now that you know how to spot opportunities and build skills around them, here's how to structure your overall career direction.
The bottom-up approach to career planning
This approach starts with where you are right now.
You look at your current skills, your current role, your current company, and you project forward. If you keep doing what you're doing and keep growing at your current pace, where will you realistically be in 3 to 5 years?
This works well for developers who are early in their careers or who want a clear, structured path. Most companies have a defined progression from junior to mid to senior to lead. Your manager or HR team can usually walk you through it. Use that information. If your company doesn't have a clear progression, ask senior developers in your field what the path typically looks like.
The bottom-up approach is grounded in reality. It tells you what's possible given your current trajectory. The risk is that it can keep you thinking small if you don't challenge the assumptions behind the projection.
Use it to understand your baseline. Don't use it as a ceiling.
The top-down approach to career planning
This approach starts with where you want to end up.
You pick a goal 3 to 5 years out and work backwards. What skills do you need? What experience? What certifications, roles, or companies would get you there?
This works best when you have some clarity about what you want. It requires you to be honest about the gap between where you are and where you want to be, and then build a plan to close it.
For example: if your goal is to become a staff engineer at a product company in 4 years, you work backwards. What does a staff engineer at that type of company actually do? What do their LinkedIn profiles and career histories look like? What experience do they have? Then you identify the steps and start taking them.
The top-down approach is more intentional. The risk is that it can feel overwhelming if the gap is large. Break the goal into annual milestones and focus on the next 12 months.
The hybrid approach: how to use both
I used both, and I think most developers should.
I used the top-down approach to set my long-term direction: become a senior developer at a highly reputed company. That was the goal. Everything else was in service of that.
I used the bottom-up approach for short-term decisions. When .NET came out, I assessed my current skills and saw a clear opportunity to get ahead. That was a bottom-up insight that served a top-down goal.
The combination looks like this: set a clear 3 to 5 year direction using the top-down approach. Then use the bottom-up approach to make smart short-term moves that keep you on track.
Review your plan every 6 months. Careers take unexpected turns. The plan should be a guide, not a contract.
Takeaways
If you're in your first 2 years:
- Stop optimizing.
- Start absorbing.
- Work hard.
- Troubleshoot everything.
- Go the extra mile.
You're building a foundation that will carry you for decades.
If you're past the first 2 years:
- Get intentional.
- Assess your skills, your interests, and the trends in your field.
- Pick a direction and build toward it.
- Find one technology wave worth riding, and go deep on it.
Shallow knowledge of many things is less valuable than deep knowledge of one thing that matters.
- Use the bottom-up approach to understand your current trajectory.
- Use the top-down approach to set your destination.
- Use both together to build a plan that's ambitious and grounded.
Your career is a long game. And that's the beauty of a development career: it can take many shapes and directions.
The decisions you make in the next 12 months matter, but they're not final.
Stay curious, stay patient, and keep moving.
Every week I send one practical tip to help you grow faster. No fluff, just what works. Join the newsletter.
