Early in my career, I kept an informal scoreboard in my head. Every framework I learned, pattern I memorized, or problem I could solve without looking anything up felt like proof that I was becoming a better engineer.
That knowledge mattered. It still does. But it also made it easy to start solving the first version of a problem before I understood whether it was the right version.
Eleven years in, I still want strong technical answers. I just care more about asking the question that makes the problem smaller.
I stopped reaching for the rewrite
I was reminded of this while working on Rails pages that took 8–12 seconds to load. A rewrite would have been easy to propose. It would also have been expensive, risky, and based mostly on a feeling that the old code must be the problem.
So I measured first. Query plans and request behavior pointed to missing indexes, N+1 queries, and large JSONB columns being loaded when the page did not need them. Fixing those issues brought the pages down to 2–3 seconds.
Nothing about the fix was glamorous. That was part of the lesson. The job was not to create the most interesting project. It was to find where the time was going and make the existing product faster.
Clear code saves context
I used to enjoy clever code more than I do now. Clever code feels good while all of the context is still in your head. Six months later, it charges the next person interest.
I want a future reader to understand the boundary, what must remain true, and why a choice was made without reconstructing my entire thought process. That does not mean every system should be simple. Some domains are genuinely complicated. The goal is to avoid adding accidental complexity on top of the real kind.
This is also why I care about names, small functions, useful tests, and comments that explain a decision instead of narrating the code. They preserve the context that otherwise disappears when the original author moves on.
Feedback changes what a team can safely do
Tests, logs, preview environments, and direct code review are often treated as process around the engineering work. I think they are part of the system. They determine how quickly we can learn whether a change did what we thought it would do.
A straightforward design with good feedback can evolve. A sophisticated design with weak feedback becomes difficult to touch because every change carries too much uncertainty.
That matters even more now that AI can produce a large patch quickly. Faster output is useful only if the team can review it, verify it, and understand the result.
The user never sees our intentions
I can care deeply about architecture and still ship something that makes a person wait, guess, or start over. The user does not know that the internals are elegant. They know whether the product helped them finish what they came to do.
So I try to serve both sides. The system should be understandable for the team that maintains it and clear for the person using it.
I still learn new frameworks and patterns. I just no longer confuse knowing more tools with knowing what to build. The skills that have stayed useful are clarifying the need, measuring the real system, shortening the feedback loop, and being willing to choose the boring fix when it is the right one.