Monkeywrench
The most dangerous person in any tech organization is the one with “Engineer” in their title who hasn’t touched a compiler in three years.
Not dangerous because they’re malicious. Dangerous because they don’t know it. They have opinions. Confident ones. About architecture, timelines, tooling choices. And those opinions are built entirely on things they read, not things they’ve broken.
I’ve watched this pattern long enough to recognize it by smell. Literally. There’s a specific kind of meeting, usually right before a project blows up, where everyone is talking in abstractions and nobody in the room can explain what the system actually does at the code level. You can feel it. The air has a certain staleness to it.
That’s the moment I knew we had a problem. Not with the project. With the profession.
The Job Title Held On. The Job Didn’t.
Something happened over the last decade that nobody put in the press release. The role of “Software Engineer” quietly split into two completely different jobs that kept the same name.
One version still writes code. Reads stack traces. Debugs things at 11pm with a cold cup of coffee and a mechanical keyboard that either sounds like a woodpecker with purpose or a smoke detector with commitment, no in between. This person knows what’s actually happening inside the system.
The other version goes to meetings about the system. Reviews architecture diagrams. Approves pull requests without running them. Talks about scalability on Zoom calls. Has strong opinions about which project management tool the team should use to track the work they’re not doing.
Both versions get the same LinkedIn title. Neither version is going to correct the confusion. One because they’re too busy shipping code. The other because the confusion is comfortable.
The problem isn’t that the second type exists. Organizations need coordination. The problem is that the second type now outnumbers the first in a lot of places, and leadership often can’t tell the difference until something breaks badly.
What Gets Lost When Nobody’s Actually Building
Here’s what I wish someone had baked into my programming five years ago, when I was spending time optimizing processes around systems I should have been learning at a deeper level: abstraction is useful right up until it isn’t, and you will not know when that line is until you’ve crossed it in the wrong direction at speed.
When the people managing a system have no real hands-on fluency with it, a few specific things happen. None of them are good.
Estimates become fiction. Not intentional fiction. Sincere fiction. Someone who hasn’t written production code recently has no instinct for where complexity hides. They’ll look at a two-week estimate and cut it to five days based on vibes and Gantt chart aesthetics. The engineer who said two weeks knew about the three legacy dependencies and the undocumented API behavior. That knowledge doesn’t survive the translation into a status update.
Decisions get made by whoever speaks most confidently. When nobody in the room has ground truth, the argument goes to whoever argues best. Confidence gets mistaken for competence. The person who actually knows why the proposed solution won’t work is often too junior to have standing in that meeting, or too technical to translate it fast enough.
The junior engineers have nobody to learn from. This one hits different. If the senior people have floated upward into pure coordination, who’s teaching the next generation how to actually build things? Not a bootcamp. Not a YouTube tutorial. You learn this craft by watching someone who’s been doing it for fifteen years work through a problem in real time. That transfer doesn’t happen in a retrospective meeting.
I wasted time, five years ago, chasing process improvements instead of technical depth. I thought getting better at organizing the work was the same as getting better at the work. It isn’t. Process is a multiplier. If you’re multiplying zero, you just get more organized nothing.
The Incentives Are Doing Exactly What Incentives Do
None of this happened because engineers got lazy. The incentive structure just pointed in a specific direction and people followed it.
Technical work is mostly invisible until it fails. Nobody schedules a meeting to celebrate the fact that the database migration went smoothly. Nobody gives a performance bonus because the codebase is cleaner than it was six months ago. But project management work is visible by design. Every meeting is a meeting someone can see you having. Every status update is a record of your activity. Every stakeholder relationship is a thing that can be put on a performance review.
The engineer who spends three days refactoring a critical module to prevent a class of bugs that will never happen now, that work is essentially impossible to reward properly. The engineer who ran five coordination meetings and updated the roadmap? That’s a slide in someone’s quarterly review.
So people respond rationally to irrational incentives. They drift toward the visible work. Over time, the invisible work, the actual building, gets done by whoever is stubborn enough or junior enough to still be doing it. And then we wonder why systems are brittle.
The craft is being quietly defunded by the performance review cycle. Nobody voted for that. It just accumulated.
What Actual Technical Depth Looks Like
It’s not about knowing every syntax. Languages change. Frameworks come and go. The engineers I’ve respected most weren’t the ones with the longest list of technologies on their resume.
They were the ones who could look at a failing system and ask the right question before anyone else knew which question to ask. They’d read a log file the way a mechanic listens to an engine. Pattern recognition built from actual repetition, not certification coursework.
They had opinions with load-bearing walls. Not opinions shaped by whatever article got shared in Slack that week. Opinions that came from having been wrong before and having to figure out why.
That kind of depth takes years of actually doing the work. It doesn’t survive a three-year stretch of mostly attending meetings. It atrophies. Quietly and completely. And then you have a senior engineer with institutional authority and junior engineer intuition, and that combination is exactly as dangerous as it sounds.
The Org Chart Got Taller. The Foundation Got Thinner.
More managers. More process layers. More tools to coordinate the tools. And somewhere in the middle of all that organizational weight, fewer people who can actually sit down and build the thing.
I’m not romanticizing the lone genius coder archetype. That person has problems too, mostly around communication and documentation and not treating their codebase like a private language only they speak.
But the pendulum swung hard. And what we ended up with in a lot of organizations is the appearance of engineering without much engineering in it. Velocity metrics. Sprint ceremonies. Roadmaps. Lots of movement, lots of artifacts, and underneath it all, a shrinking core of people who can actually tell you what’s happening when the system does something unexpected at 2am.
Those people are tired. They’re doing the work of three positions because the other three positions got converted into coordination roles. They’re not visible enough to be retained, because visibility and technical depth are inversely correlated in most organizations.
And when they finally leave, nobody knows what they actually did until something breaks and stays broken.
The engineers who can still build things are holding up more than their job descriptions say. When they’re gone, you’re going to find out exactly how much that was.
