I started my coding bootcamp in 2018. I made senior at Deloitte around 2023. Five years, give or take, from "what's a closure" to running real engineering reviews.
Most of the things I'd actually want to say to the version of me at year two aren't the things people told me. They told me to communicate clearly and write good tests, and I nodded, and I went back to writing the code, because the code was the part I knew how to control.
In retrospect, here are seven patterns that turned out to matter more than I gave them credit for at the time.
- Code stops being the constraint somewhere around year three. By then you've internalized your stack. You can ship a feature without needing the docs open. The constraint shifts to the things wrapping around the code: whether you asked the right questions before you started, whether you wrote the doc the next person on the team needs, whether you pushed back on a spec that didn't make sense.
- "Senior" is a verb more than a title. It's a thing you do for people around you. The first time you watch a junior write something in a way they wouldn't have written without your standard influencing them, you start to understand what the title is for. Until then it's mostly just compensation.
- Most of the bug reports you'll get aren't bugs. They're communication failures somewhere upstream of the code. Investing in understanding what the person is actually asking for, before writing the patch, has saved me more time than any tool I've adopted.
- Performance budgets are mostly a stakeholder problem. Anyone can make a page faster. The harder part is committing to a number, defending it across a team, and making it stick when product or design have different priorities for the same sprint.
- You'll meet engineers smarter than you who can't ship. I used to find that depressing. Now I find it useful. It tells me that "smarter" was never really the variable. Shipping discipline is a skill, and it's learnable, and a lot of people who are great at the first part never get around to learning the second.
- You learn your own reasoning by explaining it to juniors. There are habits I'd been running on for years that I couldn't actually articulate until somebody on a smaller team asked me why I did the thing that way. Teaching makes the implicit explicit. It also forces you to figure out which of your habits are real principles and which are just reflex.
- The people hiring seniors aren't checking off frameworks. They're looking for someone who has stopped breaking things in particular ways. The interview answer to "tell me about a time you debugged something hard" matters more than the part of the screen where they ask about TypeScript.
None of these are novel. The only thing I'd add is that nobody told me any of them at year two in a way that landed, and the ones that eventually did land all came from people who'd been wrong about something the same way I was about to be wrong about it.
The shift to senior, looking back, is mostly the moment you stop trying to control the part you already know.