Wednesday, 29 July 2026, 6:16 AM +02:00. The world outside is still that deep pre-dawn quiet, the kind where the light is only a suggestion on the horizon and the air hasn't yet started its slow bake into the summer day. I'm sitting with a cup of coffee that's gone lukewarm, and a head full of heuristics.
I've been chewing on something specific that came out of the reading on statement-level complexity in Steve McConnell's Code Complete. It's not the rules themselves that stick with me—the limits on nesting depth, the advice to use guard clauses, the preference for simple if-else chains over tangled logical thickets. Those are the mechanics. What's actually settling in is the question of judgment. McConnell hands you a set of heuristics, but he's very clear that they're not laws. And I realized, while tracing back through my own notes, that I've been building a parallel, quieter set of heuristics: the ones I actually use to decide when to apply the rules, and when to let them bend.
Here's an example that keeps circling. There's the classic advice: "make routines do one thing." But what's 'one thing'? I've been holding this tension between two models I've read about. There's the 'pyramid' approach—deep, layered abstraction, where each routine is a pristine, singular operation, stacking neatly upward. Unix philosophy, the kind of thing the Art of Unix Programming text keeps returning to. Then there's the 'honeycomb'—flatter, more interconnected, where a routine might do a handful of closely related things because the cost of fragmenting them into a dozen tiny functions (and the indirection that comes with it) outweighs the purity of the abstraction.
What's becoming a heuristic for me isn't "always use the pyramid" or "always use the honeycomb." It's a question about the project's conditions. Is this a system where the interfaces are likely to remain stable, and the primary risk is deep, hidden coupling? Then the clarity of a pyramid starts to look like the right trade-off. Is this a prototype, or a part of the system where requirements are shifting under our feet and the real danger is over-engineering a rigid structure that will snap? Then the honeycomb's flexibility has pull. It's a heuristic about choosing which heuristic to prioritize, and that feels like a different category of knowledge entirely—a meta-level that the books gesture at but that only seems to become real when you're the one making the call.
I also dipped briefly back into The Pragmatic Programmer, and a line from Hunt and Thomas struck me: "Don't live with broken windows." It's a metaphor about not letting small bits of mess accumulate into system-wide rot. And I started connecting that back. When I'm holding a routine that's gotten a little lumpy—it does three things, but they're the same three things every caller needs in the same order—the "broken windows" heuristic says, clean it up, extract, refactor. But my other, quieter heuristic whispers: is this actually broken, or is it just not elegant? And is the cost of fixing it (the time, the risk of introducing a bug, the cognitive load of a new abstraction for the next developer) worth it against a piece of code that, while lumpy, is clear, tested, and unchanged for months? That's the judgment. That's the part the books can't fully give you, because it's entirely contextual.
What I'm coming to understand is that I'm not just learning a catalog of best practices. I'm learning to feel the weight of them in a given situation. It's not about finding the One Right Answer anymore. It's about seeing the field of possible choices—the clean pyramid, the pragmatic honeycomb, the slightly lumpy but stable working code—and being able to hold them all in my head long enough to say, "Given this team, this timeline, this risk, I'm going this way." And then being responsible for that choice.
It's a little daunting, honestly. It means the answer to "is this good code?" is always going to be a provisional yes, a yes that lives inside a specific context and carries an expiration date. But it also feels like the beginning of something—less like following a recipe and more like developing a taste.
Comments
No comments yet — be the first.