Are you beginning your journey as a developer? Well, I've got something for you. In this article, I want to share a few subjective points on the advice I give my junior devs.
Over the years I've noticed recurring patterns, mistakes, and a few trends I really don't like. So I figured it was time to write them down.
⚠️ Warning: Before you start reading my takes, I'm assuming one important thing — that your tech leads aren't assholes and genuinely want to help you flourish. If you're not so blessed... boy, am I sorry for you.
TL;DR for the impatient:
- Bring your guess when you ask a question
- Seniors are wrong sometimes — push back
- It's our code, never his code
- Feeling like you know nothing? That's the job
- Use AI, but read what it gives you
- Don't compare yourself to others
- It's just a job. Sleep.
Alright lets start...
When asking a question, also share what you think the answer is
Let's say you're past the "how do I even start" phase and have a concrete question.
If your question is genuinely complex, it's probably hard for the senior dev to answer too (unless they're Wozniak). It takes their time, and you might also miss context that's important for the solution.
That's why I recommend pairing most questions with your own proposed answer. It can be a totally stupid guess — that's fine. What you'll notice is that a surprising number of times, you end up answering your own question while formulating it. And when you don't, you've given the senior a much better starting point for the conversation, which makes it far easier to get the answer you actually need.
Note: after writing this, I realized it's basically rubber duck debugging. :D
Your mentor/senior dev can also make mistakes
Seniors aren't oracles. We've just been wrong more times than you have, which is mostly what experience is.
If something a senior tells you doesn't add up — push back, ask why, dig in. A good senior will respect that far more than silent agreement. And occasionally, you'll be the one who's right. That's a great feeling, and it's how trust gets built both ways.
It's our code, not yours or mine
This is the most common issue I've encountered across almost every team. Someone pushes code that has a bug. I ask what happened. The first response is: "It was XX, he should fix it."
I hate it.
You're creating an environment where people are afraid to take risks. No risks means slower progress. Slower progress kills motivation. You see where this goes.
Take ownership of the project as a whole team. Build is broken? Instead of pointing out who did it, suggest how you think it could be fixed. There will be times your colleague makes a mistake. There will also be times you make the mistake. Don't forget — you all share the same goal.
Do you feel like the more you learn, the less you know? Good.
Development is genuinely complex. If you think everything is easy, you're either a genius or you're only scratching the surface. The discomfort of "I don't know enough yet" is actually a sign you're starting to see the real shape of the problem space. Get comfortable with it — it doesn't really go away, and that's a feature, not a bug.
AI is great, but please always try to understand the code
AI tools are amazing accelerators, and I'm not going to tell you to avoid them. But there's a difference between using AI to help you build something and using AI to build something for you.
If you ship code you don't understand, you can't debug it, you can't extend it, and you can't defend it in code review. Worse, you don't grow. Treat AI output the same way you'd treat a Stack Overflow answer from 2014 — useful, often correct, but always something you should read, question, and actually understand before it becomes part of your codebase.
Stop comparing yourself to others — everyone moves at their own pace
Someone on your team picked up Kubernetes in a weekend. Someone else seems to know every keyboard shortcut ever invented. Someone got promoted before you.
It doesn't matter.
You don't see their full picture — the years they spent on something before you met them, the things they secretly struggle with, the parts of the job they're worse at than you. The only useful comparison is with the version of you from six months ago. If that person would be impressed by where you are now, you're doing fine.
In the end, it's just a job — your health matters too
I'll be direct: no project is worth burning out for. Not the deadline, not the production incident at 11 PM, not the feature your PM "really needs by Friday."
Sleep, exercise, friends, hobbies that have nothing to do with code — these aren't distractions from your career, they're what make a long career possible. The best devs I know in their 40s and 50s all figured this out early. The ones who didn't... mostly aren't writing code anymore — they're running a goose farm somewhere.
A note for the seniors reading this
This article is for juniors, but if you're a senior or tech lead who made it this far — a quick word for you too.
Remember that you also started somewhere. Someone (hopefully) was patient with you when your PR was a mess, when you asked the "obvious" question for the third time, when you broke the build on a Friday afternoon. You didn't become a senior by accident — someone invested time in you, even when they probably didn't have it to spare.
Yes, the deadlines are tight. They're always tight. There will never be a quarter where you have plenty of free time and your juniors happen to need exactly that much mentoring. That's not how it works.
But please — don't skip the mentoring part. The 30 minutes you spend explaining why, not just what, is the highest-leverage time you'll spend all week. A junior you actually invested in becomes a mid-level dev who unblocks themselves, then a senior who unblocks others, then — eventually — the person carrying the team while you're on vacation.
Skip that investment and you'll be the bottleneck forever. Every question routes through you. Every tricky bug lands on your desk. Every architectural decision waits for your review. That's not seniority, that's just being permanently on-call for your own team.
Helping juniors isn't charity. It's the most selfish long-term move you can make. Future-you will thank present-you for it.
To anyone on my current or previous teams reading this: the stories are definitely not about you. The timing is purely coincidental. :)
If this resonated — or if you violently disagree — drop a comment or even send me mail. I'm especially curious to hear from other tech leads about what mindsets you wish your juniors had earlier.