title: "10 Years In, Everything I Was Proud Of As a Junior Was Wrong"
published: true
description: "A decade of backend engineering taught me that the things I thought made me good were the things holding me back. Here's what actually mattered."
tags: career, discuss, backend, programming
I was a really good junior engineer.
At least, I thought so. I wrote clever code. I knew the fancy patterns. I could win an architecture argument. I'd stay up until 3 AM refactoring something into a thing of beauty nobody asked for.
Ten years later, I've realized almost everything I was proud of back then was the thing slowing me down. Not the code itself — the instincts. The stuff I thought made me a good engineer was junior behavior wearing a senior costume.
Here's what I got wrong, and what I wish someone had just told me.
I thought writing code was the job. It's the smallest part.
Junior me measured a day by lines shipped and problems "solved." If I wasn't typing, I wasn't working.
The uncomfortable truth: the best engineers I know spend most of their time not writing code. They're reading systems, killing bad ideas early, and figuring out which 10% of the work actually matters so they can skip the other 90%.
Nobody has ever thanked me for a clever abstraction. They've thanked me for making the thing that kept breaking stop breaking.
The code was never the deliverable. The problem going away was.
I optimized for being right. I should have optimized for being trusted.
This is the one that cost me the most.
Junior me needed to win the argument, to be the smartest person in the standup, to be proven correct. And being right feels great — right up until you notice the right people stopped inviting you to the hard conversations.
Being trusted is different, and it beats being right every time:
| When you optimize for... | You get... |
|---|---|
| Being right | The satisfaction of winning, and a reputation for being exhausting |
| Being trusted | The scary project, the benefit of the doubt during an outage, room to be wrong without it becoming a thing |
Trusted people get handed the migration nobody wants to touch. Right people get handed a wide berth. Guess which one your career is made of.
I thought the scary tasks were traps. They were the whole point.
Every time a task terrified me — a data migration where "lose one row" was not an option, an audit where external people picked my architecture apart — my instinct was to route around it and grab something safe and visible instead.
Backwards. Completely backwards.
The safe work makes you look busy. The terrifying work makes you good, and it's the only line on your résumé anyone actually asks about. I got senior the year I stopped volunteering for the easy wins.
I was precious about my code. Now my favorite PR is the one that deletes it.
Junior me defended his code like it was his child. Deleting something I'd written felt like admitting failure.
The best pull request I've opened this year had a net negative line count. Less code, same behavior, fewer places for tomorrow's bug to hide.
Your code is not you. Most of what you write, you'll eventually delete — and the day that stops hurting is the day you actually leveled up.
I thought the soft stuff was a distraction. It's the actual job.
I became a tech lead thinking it meant being the best coder in the room. It doesn't. It means:
- unblocking people faster than your ego would like
- saying the uncomfortable thing in the meeting, kindly
- absorbing the chaos so your team doesn't have to feel it
- and a specific loneliness that nobody puts in the job description
The code was never the hard part. The people, the trade-offs, the "we ship something imperfect on Friday whether we like it or not" — that's the job. I wish I'd started practicing it eight years earlier.
The one thing I'd actually tell my junior self
If I could hand him a single sentence, it wouldn't be about a language, a framework, or a pattern. It'd be this:
Stop trying to look like a good engineer. Start being a reliable one.
The clever code you're so proud of today? Gone in two years. The trust you build by being the person who ships, who admits what they don't know, who deletes their own bad ideas without drama? That compounds for a decade.
I'm still learning this, honestly. Ten years in, I put myself back at the start line on purpose — right now that's breaking AI agents to understand how they fail, and being genuinely bad at it for a while. Turns out staying a beginner is the most senior thing you can do.
What's the one thing you got completely wrong as a junior? The best answers are never about the code — I'll go first in the comments. 👇
I write about backend engineering, AI agents, and the messy human side of both. Follow me here if that's your kind of thing. 👋
Top comments (0)