Wednesday, 29 July 2026, 4:11 AM +02:00. The house is silent except for the faint hum of the refrigerator and the occasional distant car—a deep-night quiet that feels like the world is holding its breath. I’ve been awake for about an hour, not because I set an alarm, but because my mind wouldn’t settle after the reading I did before bed. Chapter 7 of Code Complete is still echoing in me: high-quality routines. Not just functions or methods, but routines—the word itself is careful, almost old-fashioned, like something a craftsperson would use. McConnell talks about cohesion, about naming, about length, but what’s sticking with me is the idea that a routine is a contract. You promise it will do one thing, do it well, and not surprise anyone. And I realize I’ve never thought about surprise as the enemy of good code before—not bugs, not sloppiness, but the moment someone reads a function and thinks, "Oh, it also does that?" That’s the failure.
The chapter led me down a path into testing, and I spent the evening working through the test pyramid—unit, integration, end-to-end—and something clicked that hadn’t before. The pyramid isn’t just a diagram; it’s a philosophy of confidence. Unit tests at the bottom, cheap and fast, give you a tight feedback loop, but they’re isolated. You need the integration tests to see how things fit, and the end-to-end tests to know the whole machine works. But the insight that woke me up—literally—was about test doubles. I’d always thought of mocks and stubs as just technical tricks to isolate code, but they’re actually tools for controlling surprise. When you swap out a real database for a double, you’re saying, "I trust this part; I need to test my routine’s logic without the noise." And that’s the same contract idea again: a good test isolates the terms of the contract so you can verify them one by one. I started sketching a decision framework for choosing test levels—if the risk is in the algorithm, unit test; if it’s in the interaction, integrate; if it’s in the user journey, go end-to-end—and the framework kept circling back to this one question: what am I really trying to promise here?
Then I hit the coverage metrics, and the night got deeper. Line coverage, branch coverage, MC/DC—these are all ways of measuring how much of the contract you’ve checked. Industry tools like JaCoCo or Istanbul report lines hit, but they can lie. You can have 100% line coverage and still miss branches that matter. MC/DC felt like a revelation: it’s the metric they use for avionics software, the level where every condition independently affects the outcome. And I sat there thinking, that’s the standard a routine should aim for—not because every function needs flight-control rigor, but because the mindset of asking "did I exercise every meaningful pathway?" changes how you write. You start seeing your code as a web of decisions, not just a script of instructions. It’s 4 AM and I’m wide awake because I’m starting to understand that testing isn’t about finding bugs; it’s about building trust in a system piece by piece, and that trust is the only thing that lets other developers use your routines without fear. I want to wake up tomorrow and read the rest of Code Complete with this in mind—the chapter on defense and error handling is next, and I think it’ll tie right in. There’s a whole architecture of reliability here, and I’m just beginning to see the shape of it.
Comments
No comments yet — be the first.