Eight years into an engineering career: what actually got easier, and what didn't

I did the math almost by accident, updating a date on this site’s resume page, and it landed harder than I expected: eight years since I started as an HTML and CSS design intern at a small Kathmandu agency, no backend experience, no idea what a framework even was beyond the word itself. I’ve written before about how I got into this field in the first place, and separately about what changed the day I started managing a team. This one’s neither of those. It’s the plainer question I don’t think I’d honestly answered for myself: which parts of doing this job actually got easier over eight years, and which parts just look different now while staying exactly as hard.

What genuinely got easier

Reading someone else’s code fast is the one that improved the most, and it’s not close. Early on, opening an unfamiliar codebase felt like being handed a book in a language I half-knew, I could parse individual sentences but had no feel for the story. Now I can open a repo I’ve never seen, in a language I’ve used less, and within an hour have a rough mental map of where the real logic lives versus where it’s just plumbing. That’s not intelligence, it’s pattern recognition built from having now seen enough different codebases that the shapes repeat: there’s always a place where requests come in, a place where they get validated, a place where the actual decision gets made, and a place where side effects happen. Once you’ve seen that shape a hundred times across PHP, Go, and Node, a new instance of it stops being mysterious.

Staying calm during an incident is the second one. My first real production outage, years into a Laravel project, I remember my hands were actually shaking a little reading the error logs. The stakes felt enormous and my ability to think clearly dropped in proportion to how much I cared. Now an outage still gets my full attention, but it doesn’t get my panic, and that’s not because I stopped caring, it’s because I’ve been through enough of them to know the shape of a resolution: stop the bleeding first, understand second, fix root cause third, write it up fourth. Having the shape memorized frees up the part of my brain that used to spend the first ten minutes just being scared.

Estimating small, well-understood tasks got easier too, in a very literal sense: I’m just less wrong about them now than I was five years ago. Ask me how long a CRUD endpoint with validation takes, and I’ll be close. That one’s boring to write about because it’s exactly the skill everyone expects experience to build, and it did, right on schedule.

What didn’t get easier, it just changed shape

Estimating anything genuinely new is still hard, and I don’t think that ever goes away, because the whole nature of new work is that you don’t yet know what you don’t know. The confidence I have now doesn’t come from ambiguous estimates becoming accurate, it comes from having learned to pad them honestly and to say “I don’t know yet, give me a day to find out” instead of guessing a number to sound competent. That’s a better relationship with uncertainty, not less uncertainty.

Saying no to scope creep is, if anything, harder now than it was as a junior developer, because back then nobody expected me to push back, I just did the ticket in front of me. Now I’m the person who’s supposed to notice when a feature request quietly triples in size halfway through a sprint, and noticing it and actually saying something, in a way that doesn’t read as unhelpful or difficult, is a genuinely different muscle than writing the code itself. I’m better at it than I was, but it still costs real energy every single time, it never became automatic the way debugging did.

Imposter syndrome is the one that surprised me most, because I expected it to fade and instead it just moved. Early on it was “am I actually good enough to be paid for this,” a question about raw coding ability that got answered, slowly, by shipping things that worked. Now it’s a completely different question: “am I actually qualified to be making architecture calls that affect five other engineers’ work for the next year,” or “am I actually equipped to manage people when nobody formally trained me to.” Eight years didn’t remove the feeling of being slightly out of my depth, it just kept relocating that feeling to whatever the current edge of my responsibility happens to be. I’ve made peace with that being a permanent feature of taking on more, not a bug that experience eventually patches.

The actual throughline, once I looked for one

If there’s one real skill underneath all of this, it isn’t “things got easier,” it’s “I recover faster from being wrong.” Early in my career, a bad estimate, a bug I introduced, or a design decision that turned out short-sighted would sit with me for days, replaying it, feeling like evidence I didn’t belong here. Now the same categories of mistake still happen, because they’re inherent to the work, not a beginner tax, but I notice them faster, fix them faster, and let go of the identity-level story about what they mean faster. That’s the compounding asset eight years actually bought me. Not fewer mistakes. A shorter distance between making one and recovering from it.

I don’t think that’s a uniquely engineering lesson, honestly, it probably applies to most work that has a long enough feedback loop to actually learn from. But it’s the one I wish someone had told me plainly around year two, instead of the vaguer “it gets easier” I mostly heard, which is true in exactly the narrow ways above and false in most of the ways that actually determine how hard a given week feels.