Dear 2019 me: You're about to start a journey that will take you from copy-pasting from Stack Overflow to leading technical decisions at a company you respect, and the path between those two points is not the one you're imagining. You think the path is about learning technologies — React, then TypeScript, then Node, then whatever comes next — and technologies are part of it, but they're not the part that matters. The part that matters is learning how to think about problems, how to communicate about solutions, and how to work with people. The technologies will change; the thinking, communicating, and people skills compound. Invest disproportionately in the things that compound.

You're going to make mistakes that feel catastrophic at the time and that you'll barely remember a year later. The first production bug, the first missed deadline, the first bad architectural decision — each will feel like evidence that you don't belong in this profession, and each will actually be evidence that you're learning. The mistake isn't the important part; the response to the mistake is. Fix it, understand why it happened, change the process so it can't happen again, and move on. Carrying the mistake as evidence of incompetence is a weight you don't need to carry, and it's a weight that slows down the learning it's supposed to be enabling.

The thing you're most wrong about is the importance of being the smartest person in the room. You'll spend your first two years trying to be the smartest, and you'll eventually realize that being the smartest is a losing strategy, because the room keeps getting bigger. The actual strategy is to surround yourself with people who are smarter than you in different ways, and to focus on being the person who helps them do their best work. That's a harder skill than being the smartest, and it's a skill that scales further, because one person can only write so much code, but one person can help a team write much more.

Seven years in, I'm still figuring out the balance between technical depth and breadth. The early career is about depth — getting genuinely good at something — and the mid-career is about breadth — understanding enough about adjacent areas to be useful across them. The late career, if I'm reading the trajectory correctly, is about depth again, but a different kind: not depth in a specific technology, but depth in the principles that underlie all technologies. I can look at a system I've never seen and identify the trade-offs in its architecture, not because I know the specific technologies but because the trade-offs are universal. That kind of depth is what I'm working on now, and it's the kind that doesn't obsolete when technologies change.

I'm also still figuring out the balance between building and leading. Building is satisfying because the feedback is immediate — you write code, it works, you ship it. Leading is satisfying on a longer timescale — you help someone grow, you shape a decision, you build a culture — but the feedback is delayed and ambiguous, and it's hard to know whether you're doing it well. The temptation is to retreat to building, because the feedback is clearer, but the leverage is in leading, because one person's building is bounded by their own capacity while one person's leading is bounded by the capacity of everyone they influence. The balance I'm working on is staying technically engaged enough to be credible while spending enough time leading to be impactful, and the balance is different every quarter.

The things that stayed constant over seven years are the things I'd tell my 2019 self to invest in from the beginning. Reading code is more important than writing code, because you spend more time doing it. Communication is more important than technical skill, because technical skill without communication doesn't scale. Curiosity is more important than knowledge, because knowledge obsoletes but curiosity compounds. Patience is more important than speed, because the fast solution that's wrong takes longer than the slow solution that's right. And kindness is more important than being right, because the relationships you build are the foundation of everything else, and being right at the cost of a relationship is a bad trade.

The other thing that stayed constant is the joy of building things. The technologies changed, the roles changed, the scope changed, but the feeling of taking an idea and turning it into something that works — that feeling is the same in 2026 as it was in 2019. The joy is why I started, and the joy is why I'm still here, and the joy is what I'd tell my 2019 self to protect above all else. The profession will try to turn the joy into obligation, the industry will try to turn it into productivity, and the career will try to turn it into advancement. Protect the joy. It's the only thing that can't be replaced, and it's the thing that makes everything else worth doing.