Or: How I learned the hard way that experience can’t be googled.
When I started as my software journey, I thought I had it all figured out. Documentation was my teacher, Stack Overflow was my mentor, technical blogs were my friends and GitHub was my university. Every problem had a solution somewhere online, every concept could be learned through tutorials, every framework mastered through practice.
I was wrong about a lot of things.
Don’t get me wrong - being self-taught taught me invaluable skills. I learned to dig deep, to understand systems from first principles, to not be afraid of diving into unknown codebases. But there’s a crucial difference between learning how to code and learning how to build a career in software development.
Without experience, everything seems doable and rosy. Want to build a real-time trading platform? Just use WebSockets and Redis. Need to handle millions of events? Easy, just scale horizontally. Building an AI-powered document extraction system? LLMs can do anything, right?
This confidence is both a blessing and a curse. It makes you take on challenges you might otherwise avoid (good), but it also makes you underestimate complexity and make poor career decisions (not so good).
I spent my early years saying yes to everything:
Without mentors, you learn everything through trial and error. And while making mistakes is valuable, some mistakes are more expensive than others.
Technical mistakes are relatively cheap and recoverable:
Career mistakes are much more expensive:
I made plenty of both types, but the career mistakes hurt more and lasted longer.
Looking back, here are the insights that a good mentor could have shared with me:
I spent years honing my Python skills, learning every framework’s quirks, optimizing database queries. These skills are important, but they’re also learnable by anyone willing to put in the time. What’s harder to learn is how to understand business requirements, how to communicate effectively with non-technical stakeholders, and how to make trade-offs that actually matter.
I took roles based on salary bumps and interesting technical challenges. A mentor might have asked: “What’s the team like? How do they handle conflicts? How do they give feedback? How do they handle failure?”
This is something I’ve learned to value in others, but I wish someone had taught me earlier: When you hit a wall, do you immediately ask for help, or do you dig in first? The best engineers I know try to understand the problem deeply before seeking assistance.
Early career? Go broad. Learn different languages, paradigms, domains. Mid-career? Start specializing. Pick a domain (AI, systems, frontend, etc.) and go deep. I spent too long being a generalist when I should have been developing expertise. The sea of tech is vast and I wanted to see it all. A good mentor would have guided me to the right domain based on my interests and skills.
The people you work with early in your career become your network for life. That junior developer you help today might be the CTO who hires you in five years. I wish I’d understood this earlier and been more intentional about building relationships. I was just too focused on fixing that bug, or building that feature or getting that PR merged.
I’ve come to believe you need different types of mentors at different stages:
Someone who can review your code, challenge your architectural decisions, and push you to understand systems deeply. They teach you that good code isn’t just code that works - it’s code that can be maintained, extended, and understood by others.
Someone who’s navigated the career path you want to follow. They can help you understand what skills actually matter, what opportunities to pursue, and what mistakes to avoid.
Someone who understands the broader landscape - market trends, company cultures, technological shifts. They help you see the forest, not just the trees.
Someone who’s figured out work-life balance, dealt with burnout, and maintained perspective through the ups and downs of a tech career.
The challenge is that formal mentorship isn’t common in our industry. Most learning happens through osmosis - working alongside experienced developers and picking up knowledge through proximity. But if you’re self-taught or working at smaller companies, you might not have that luxury. Most people are struggling themselves or just plainly don’t care enough.
Here’s what I’ve learned about finding mentors:
Look for teachers, not just experts. The best engineer on your team might not be the best mentor. Look for people who enjoy explaining concepts, who ask good questions, who can gently nudge you towards the right path and who remember what it was like to not know something.
Mentorship doesn’t require a formal relationship. Some of my best lessons probably happened unexpectedly. I learned from their code reviews, their technical blog posts, their answers in Slack channels. I wish I had realised it then and I wish I would have been more intentional about being mentored.
Give before you get. Help others with problems you’ve already solved. Document solutions. Write blog posts. Teach what you know. People who see you contributing are more likely to invest in helping you grow.
Ask specific questions. Instead of “Can you mentor me?”, try “I’m struggling with how to structure this API. Could you help me think through the trade-offs?”
The lack of mentorship in my early career had compound effects. Mistakes led to more mistakes. Poor career decisions led to environments where I couldn’t learn and grow as quickly. It took me longer to develop both technical skills and professional judgment.
But here’s the thing - it also made me more self-reliant and forced me to develop strong problem-solving skills. When you can’t ask someone for the answer, you get good at figuring things out yourself. It’s not what I would choose if I could do it all over again but it’s a skill that I am grateful for.
Now, with 9+ years of experience (including all those expensive mistakes), I try to be the mentor I wish I’d had. I review code with care, explain the “why” behind decisions, and share career insights with junior developers. I try to be more direct as a mentor rather than just occasionally checking in. I don’t want to push them towards the way I learnt but I want to push them towards the way I think they should learn.
Because the truth is, we all need guides. Software development is too complex, careers are too nuanced, and the industry changes too quickly for anyone to figure it out completely alone.
The senior developers who take time to explain concepts, who share career advice, who challenge you to think differently - they’re not just making you better. They’re making the entire industry better.
If you’re early in your career and reading this: seek out mentors actively. Ask questions. Learn from others’ mistakes instead of making them all yourself. And when you reach a point where you can help others - pay it forward.
If you’re experienced and reading this: remember that your knowledge and perspective are valuable to others. Take time to mentor, formally or informally. The industry needs more guides.