8 articles
Sunil Pai's “senior engineer death spiral” describes what happens when engineers start managing perception instead of reporting reality. The deeper problem may not be individual pride or fear, but organizations that make uncomfortable information too expensive.
A recent discussion on how AI was used effectively made me wonder what "effective" or "better" meant, because there's no way to test the alternative any more to compare. I still don't know how to characterize my own results, but I think it makes me better because it gives me a chance to work out who I am and what I mean to say, but not really how to say it.
Andrew Oram asked why programming languages rise and fall, and quoted the answer without noticing. Programming is a vocation, an art, and a job. Make any of those harder than they need to be, and your language survives exactly as long as it can't be replaced.
Andi Roberts wrote up Alex Pentland's research on why some teams outperform others. The research is good; the practical advice mostly assumes a watercooler you may not have. Some additions from the trenches: what Brooks actually said, two cheap levers for building the idea flow, and when you want the opposite.
Christian Ekrem's 'The Tacit Dimension' carries Polanyi's 'we can know more than we can tell' into software engineering. He's right that experience works that way. Knowledge doesn't, and the essay never separates the two.
Jordan Lord lays out three constraints he applies before building anything: a one-page description that survives without padding, a piece of core tech that can outlive the product, and a single defining constraint that shapes the user experience. Scope, leverage, and identity - one filter each. Great stuff.
The "10x engineer" may be a real phenomenon, in that some people really do vastly outperform their peers along certain metrics, but "10x output" is the wrong thing to optimize for: you want to find the people who create exponential output for the whole team. AI makes this kind of optimization urgent, because these people not only help their team members, but curtail the worst aspects of AI aid, too.
Most teams don't trust their code - they trust the people who wrote it, or the streak of days without incident. That's not the same thing, and the difference is becoming harder to ignore. Trust in a system isn't social capital or accumulated momentum: it's demonstrated, repeatedly and verifiably, by the system itself. If you have to read the code to know it works, you don't know it works.