Engineering

The Shape of Engineer Burnout Creative burnout in engineering looks different than burnout in other fields. It’s not just exhaustion from long hours (though that’s part of it). It’s the specific fatigue that comes from: Infinite scope. Features that seemed scoped end up needing architecture work, documentation, refactoring, and support. The work expands to fill available time. Context switching. Ping-pong between your own work, meetings, code reviews, unplanned incidents, and people asking “quick questions” that aren’t quick. Invisible work. You spend days thinking about a problem before writing a line of code. To everyone else, you look idle. Pressure mounts. Decision fatigue. Every technical choice branches into five more questions. Should we use library A or B? Refactor or ship? Upgrade or wait? Your judgment gets spent before lunch. The expectation to be always-on. Slack notifications, on-call rotations, “can you just look at this?” messages at 6 PM. The mental boundary between work and life dissolves. This burnout doesn’t announce itself with a bang. It creeps in through a thousand small surrenders: skipping lunch, saying yes to projects you don’t have time for, staying late “just one more time,” working weekends to catch up. By the time you notice it, you’ve already lost the energy to fix it. ...

There’s a moment in every developer’s career when you realize the code is not the product. The product is the decision. For the last five years, I’ve watched this shift accelerate with AI. And it’s forcing us to confront something uncomfortable: the quality of what we build is almost entirely determined by the clarity of what we asked for. The Specification Was Always the Bottleneck In traditional software development, we treated the specification as a precondition to building. You write the spec. The engineers read it, find all the places where it’s ambiguous or incomplete, iterate back, and then they build. ...

For forty years, the engineering career ladder has looked like this: Junior → Mid-level → Senior → Staff/Principal → Architect It’s a smooth progression. You write more code, then you write less code but influence the shape of it, then you write almost no code and mostly make decisions about how things are built. This ladder is becoming obsolete. Not in five years. Now. The problem is not the ladder itself. The problem is that AI has already done something the ladder never anticipated: it’s collapsed the middle rungs by automating the step where you learn to execute well. ...