Your growth as an engineer is mostly defined by your climbing of the ladder of abstraction. Everyone’s road is different, but the landmarks are pretty similar: you start out implementing facts, then features, then architectures, then ideas. The line of code begins as your primary currency, the artifact by which you know your job is done, but it recedes into the horizon.
This isn’t to say that I write less code than I did when I was a younger engineer; I probably write more. But the code is less important — implementation is more of an afterthought than a going concern.
Sure, the code is important. Correctness is important; readability is important; technical debt is important. I’m not saying any of these things aren’t, but I’ve recognized them more as lagging indicators of other aspects of engineering: things travel downstream, and leaky abstractions in code come from leaky abstractions in real life.
I’m asking myself “why doesn’t this code compile?” less, and asking myself “what don’t I understand about the underlying domain?” more.