Over the summer I published a series on coding tactics: the everyday craft of ifs, loops, and the reasoning behind them. Eight posts, one thesis, best read in order. This is the map.

When I read consistent, cohesive code, I have a feel for its author. I may disagree with the ideas, but I can feel where the author is driving it. Other times the feel is split-brain — the code’s “energy” is fractured, the work of unaligned hands each solving its own small problem, none with an idea where the whole is going. Immediately I feel it should be rewritten or refactored holistically.

Here is the paradox. Most of us are dedicated professionals with years of experience, and bad code is everywhere. Programmers I respect produce it; my own code is far from perfect. Why?

The first time I said “code is cheap” out loud in a meeting, a manager waved at the budget — headcount, salaries, the tooling line — and asked which part of that looked cheap. He wasn’t wrong about the number — he was wrong about what it was buying.