Build a dev career for the long haul
Unsolicited career advice for young[er] devs
I’d like to believe I’m not old enough to hand out career advice with authority.1
Although, occassionaly, I am on the receiving end of innocently hurtful comments from fresh grads who say, “Oh, I didn’t realise you’re more than 10 years older than me”2.
I consider myself fortunate to have been around some amazing mentors.
At the very least, I hope this turns out to be a distillation of advice I’ve received over the years from people smarter than I am.
It’s a longish read, but if you are in a hurry here’s the most important advice:
Hunt for a great mentor and just latch on to them. If you can’t find one, then hunt for one outside of your current workplace/environment.
The surest way to upskill yourself is to be taught by someone who is very good at what they do.
[Choice of] Place of Work
A wise person once said, “A good place to work is one where the feeling of loserishness is prevelant”.
Simply put, you’re at the right place if you feel like a loser next to the folks around you.
The around you part is important. Admiring accomplished coworkers from far off won’t help you level up.
If possible, try to be part of a team with someone you look up to.
A large part of your learning will come from your immediate peers. Surround yourself with folks who are more accomplished, more hungry and more driven than you are - you’ll feel like a loser in front of them, but you’ll learn the most too.
I know, working closely with someone you look up to can be intimidating.
But apart from ridiculously fast paced learning, there is a great side effect to it too. When you carefuly observe people, you realise that everyone is human and has their own shortcomings.
This makes it less intimidating over time and encourages you to build a thought process that is inspired by, but hopefully free from, your mentor’s biases.
Stick to Projects
Substantive learning comes from feedback. As a developer, you’ll get feedback from all quarters - peers, managers, team leads & perhaps even customers.
Your code gives you feedback too. The code you write & the product it brings to life are constantly evolving.
That abstraction you crafted will become too brittle in a few months.
That API you so agonized over will no longer be used.
If you’re lucky - you’ll get to see your code undero major refactoring or even a rewrite!
It is imperative that you stick around to witness this. Only through multiple iterations does one develop an intuition about what really matters when you code.
In my last company, we had taken the decision of not using any ORM.3
When a new recruit asked why, I simply said that it’s because all ORMs suck.
He was semi-offended at that. He mentioned he’d used <foo-ORM> in a dozen or so services in the past without encountering any issues.
I tried to explain how as the code ages & the data model gets complex, you end up having to manage the ORM more than manage your own code.
Since we’re a startup, our data models would see constant flux for the foreseeable future. Hence, it was much easier to pick vanila SQL than to wrangle with an ORM
What I said didn’t appeal to him very much and was evidently not convinced with our collective reasoning.
I gave him various scenarios where simple things like multi table queries, frequent migrations with backward compatibility etc with <foo-ORM> would become a hassle.
Some of these seemed to bring him round a bit, but he mentioned he still liked the convenience <foo-ORM> offered.
On further introspection, we realised that the convenience is merely that of a few saved SQL queries.
During our conversation, I also found out that in his previous company, he had not been able to stick around a project for more than a quarter or two.
Thus, while he had used <foo-ORM> during the initial setup, he had never been in a position to have felt the pain I spoke of.
If he had had the opportunity to stick around long enough, he would have learnt a bit about the trade-offs that come with it.
Iteration brings this wisdom. When you’re face to face with your past choices, you innately learn about how valuable they really were.
Of course, there is no one universal truth - your experiences will shape how you think as an engineer.
Perhaps requirements will change too often and you’ll end up hating PMs.
Perhaps you’ll hit scale sooner than expected and start taking observability & infrastructure choices more seriously.
But at at a bare minimum, you’ll learn about at least one thing that matters in the long run and about a dozen other things that really don’t.
Take up a Shitty Maintenance Project
Now, I know you think I’ve gone completely bonkers!
But, trust me, that is not career suicide!
The very first project that I took up as a ‘Lead Engineer’ was a bug infested, Oh-Lord-How-Does-This-Even-Work, Step-Child-Of-7-People nightmare of a project.
To make my nights more fun and interesting, it was suddenly designated as a core platform project. The multi billion dollar company I worked for wanted to rely on it to provide critical alert functionality for their biggest upcoming October Sale.\
There’s a saying, “Always code as if the person who ends up maintaining it is a violent psychopath”. Obviously, people who wrote this junk hadn’t heard it.
I was the psychopath, but I couldn’t turn violent because I didn’t have time for that! Since violence wasn’t an option, my subconscious mind chose to reconcile itself through literal nightmares instead.
Despite the pressure, I can safely say that I learnt a ton from other people’s mistakes (and without the blame/guilt that comes with making them!)
Moreover, it helped me with some valuable skills
- The ability to read code and make sense of it!
- The confidence of being able to take up any code base (as shitty as can be) and be able to mould it as my own4.
Both are something I pride myself on, and have come in extremely handy over the years.
Be Patient
During one particular evaluation cycle, I really thought I deserved a promotion but I didn’t end up getting one.
Coincidentally, I was also changing teams at the same time. So my performance discussion happened with my to-be manager in the same room along with my ex manager.
I explained how I had clearly outperformed compared to what was expected, deserved the promotion and was being treated unfairly. I was outright rude.
Rather than being alarmed by such hostile behaviour, my new boss uttered the single most profound advice I’ve received - “So?”
The fuck did he mean by that?5
“Did you get to work on interesting stuff this past year?”. Yes
“Do you think you gave it your best and are a better engineer today than you were a year before?”. Yes
“Do you care about the little bit extra money you’d get if you were promoted?”. No
“So how does it matter? Just suck it up and do what you’ve been doing”. Profound.
And of course it didn’t matter! What matters more is that it’s been 5 years to the day and he’s still someone I go to whenever I need some honest, no bulshit advice.6
I know - perhaps you’re skeptical. Thinking it doesn’t apply to you since you’re in a competitive, politicaly charged environment and these things matter.
No they don’t. Trust me, I’ve been there. The above advice snapped me out of it and made me realise that how much you improve each day/week/month/year at the craft you care about & the relationships you build over time are what matters.
One missed promotion, one missed opportunity doesn’t matter. If you’re hungry - you’d get round to the next one.
Footnotes
People are always remarking how young I look. Surely they can’t all be flattering me. Hopefully. Maybe. ↩︎
Sunny, it’s been 2 years but it still hurts :) ↩︎
This was taken before I joined - and boy was I glad! ↩︎
I have a blueprint now. Something I can write about some other time ↩︎
Well, I didn’t use those exact same words - it was too early to show my true colors :) ↩︎
I’m sure he doesn’t remember this one bit. He’s too busy being high on life. ↩︎