- mentoring
- career
What I tell junior engineers to do in their first six months
Seven things I keep saying in Swift-Hyderabad sessions. None of them are about writing better code. Most of them are about what you do around the code.
I mentor a small number of engineers in their first job. Most of them are two to six months in. The questions I get in those sessions are not about algorithms. They are about the texture of the work — what to pay attention to, what to ignore, how to calibrate.
These are the things I find myself saying over and over. None of them are novel. That is the point.
Read every PR on your team for two weeks before opening your own
I mean read them. Not skim. Open the diff, follow the review thread, notice what the senior engineers comment on and what they quietly pass over. You are trying to build a model of what your team thinks is worth arguing about. That model is the thing that decides whether your own PRs will move quickly or get stuck.
You will learn the house style faster by reading ten PRs than by reading any style guide. You will learn which people take reviews personally, which do not, and who is worth asking for a second look before you hit Request Review.
Write good commit messages first, not last
Most first-job engineers write a commit message at the end, because the branch is ready and the PR button is calling. By then the history is already a mess. Force yourself to write the message before you stage. If you cannot explain what the commit does in one sentence, split it.
This sounds precious and isn't. In six months you will want to git log your own work to see how you solved something. In three years someone else will git blame a line that now looks wrong. Both of those people are you, borrowing your attention through time. A sloppy commit message is a small debt to a future version of yourself.
Keep a "lessons broken" note
A plain text file, private, on your machine. Every time you break something — production, staging, your laptop, someone else's laptop — write a line. What you did, what broke, what you did not expect.
Do not write lessons. Write incidents. The lessons will emerge on their own when you re-read the file a year later and see the same class of mistake three times.
Most engineers do not break enough things to need this file. Those who do, wish they had started it on day one.
Say "I don't know" early, loud, and often
The instinct, in a new job, is to pretend you understand the thing your tech lead just said. The instinct is wrong. The cost of saying "I don't know what that is" is a few seconds of mild embarrassment. The cost of pretending is three hours of Googling later that night to avoid being found out, and a slightly worse relationship with your lead forever.
The senior engineers you work with know the team's knowledge map better than you do. They are going to find out what you do not know. You get to choose whether you tell them, which they will respect, or whether they discover it by accident, which they will not.
Ask who owns the thing, not what it does
When you are handed a piece of the codebase, the first question is not "what does this do?" It is "who owns this?"
Ownership tells you who to ask when it breaks, who to write when you want to change it, who will be annoyed if you touch it without a conversation. In a large codebase, the social graph matters as much as the dependency graph, and it is far less documented. Figuring out the owner of a piece of code is half the work of making a safe change to it.
If the answer is "no one owns it" — notice that. Unowned code is a trap. It is where bugs live longest and where your "simple fix" will find its way into a production incident someone else has to answer for.
Learn to read a flame graph before you write a performance patch
Every junior engineer eventually gets pulled onto a "this is slow, can you look at it" ticket. The temptation is to guess, add a cache, and call it a day. Do not do that.
Spend an afternoon learning how to read a flame graph in the language your service runs. Learn what "self time" versus "total time" means. Learn to spot the false bottom — the frame that looks like the hot path because it is wide, when actually the hot path is inside a library it calls. Once you can read a flame graph, you stop guessing, and your instincts about performance start catching up with your instincts about correctness, which are probably already pretty good.
The tool does not matter — pprof, async-profiler, the Chrome Performance tab. The skill is reading the picture.
Underline this one
The single most important thing you can do in your first six months is finish the things you start.
Not finish them well. Not finish them in a way you are proud of. Just finish them.
Junior engineers tend to over-collect work in flight. A ticket half-done here, a PR with three unresolved review comments there, a bug investigation nobody closed. It is not laziness. It is the gravitational pull of starting new things, which always feels more productive than closing old ones. But the engineers I trust — the ones who get promoted, the ones I stop worrying about — are the engineers whose name on a ticket means the ticket is going to be closed. Not instantly. Not always cleanly. But closed.
Everything else on this list is a shortcut. This one is the job.
The ritual, if you can make it one: every Friday afternoon, spend twenty minutes closing open loops. A review comment you were procrastinating on. A ticket you forgot to update. A draft PR that has been sitting at 80% for two weeks. Close them, or explicitly punt them to next week with a note explaining why.
Junior engineers who do this for six months stop being junior engineers. Nobody told me that when I started, and it cost me about a year.