Several months ago, I was breaking a story into tasks when I realized that a year earlier, it would have been an epic. A small team would have spent months on it. I was planning to finish it alone in two weeks, and that was normal.
Software engineering has always been in perpetual motion. New languages, frameworks, and design principles appear every year. But the pace of change in 2026, combined with a fundamental shift in the core skill of the job, made this year different in kind. It is so easy to lose intention when you are working at that pace.
When building software was slower, the slowness itself acted as a check. You could feel yourself slowly drifting in the wrong direction before you had invested much energy. Now you can build a lot of the wrong thing before you notice, and it looks finished. Velocity multiplies the impact of direction, so heading the wrong way becomes more expensive.
Before I write a line of code, I break the work into pieces that can each be verified on their own, and I spend just as much time understanding the seams between them, because that is where unforeseen issues hide. I exercise each piece as it fits in, which keeps the system under test small. Quality assurance on a huge merge request is too late. Knowing what to type in a text editor is no longer the dominant skill. The work has moved one layer up, to how the pieces meet. A watchmaker can create a flawlessly finished pallet fork and escape wheel, but the movement will seize if the geometry between them isn’t attended to.
It is easy to forget that software is a fundamentally human act. When you are done, a person is going to spend a significant part of their life staring at the thing you built. An application built with a sense of humanity respects the user’s time and intent. Does the app have a consistent information hierarchy that makes it obvious what the next step is? If something can’t or shouldn’t be done, is that obvious? A user shouldn’t learn that only after wasting their time and receiving an error message.
Steve Jobs famously said that Apple’s greatest success comes from operating at the intersection of technology and liberal arts. The technology half of his intersection is now abundant. What remains scarce is understanding the problem and the people you are building for, and that comes from listening, reading, and curiosity, not technical skill. A sharper analogy comes from my experience as a classical pianist: engineering is increasingly becoming interpretation. Every pianist has the same notes to work with. The art lies in each small interpretive decision, building upon the last, that makes those notes yours.
My first piano teacher, Paul Parker, reminded a very young version of me that a note and a rest carry the same importance. Similarly, the timing of the end of a note is just as important as its beginning. This was a formative lesson in restraint. What you purposefully leave out of an application is just as important as what you add. A new feature is now just a prompt away. Resisting that urge, understanding what your app is for and where the value lies, and focusing your effort where it counts is more important than ever.
When building is nearly free, what do you do with the surplus? For me, in 2027, it goes to people, not features. If a story shrinks from something a team does in a few months to what I can do in a few weeks, that dividend goes into flow: making the impossible obvious, not increasing scope. And it goes to restraint. What I leave out should be just as deliberate as what I include.