I keep hearing from engineers lately: there is too much going on. Too many parallel threads. Too much code being generated to actually read. Big features merged that nobody could honestly claim to fully understand. On-call for code you didn’t write and don’t fully trust. And underneath all of it, a quieter admission: the work isn’t teaching me much anymore, and it’s stopped being fun.

About a year and a half ago I wrote a framework for quantifying software engineer performance. The idea was simple: performance is a weighted combination of input, output, outcome, and impact, and if you score yourself weekly against agreed categories, you remove a lot of the friction and anxiety from review season.

In the last couple of weeks I’ve had a few separate conversations that, looking back, were all the same conversation. One was about community issues vs. customer asks. One was about whether we invest in new features or pay down engineering foundations. One was the usual short-term vs. long-term tension. Different details - but the same underlying problem every time: two things that both clearly matter, not enough capacity to fully do both, and a group trying to decide which one wins.

I’ve been thinking about this for a while now, and a recent Root Cause podcast conversation pushed me to finally write it down. In the podcast they talking about something that I suspect a lot of engineers feel but rarely say out loud: you might only need deep system knowledge 1% of the time, but that 1% is often the moment that matters most. And AI is quietly eroding exactly that.

I was reading The Software Development Lifecycle Is Dead and had some loud thoughts I want to share.