Programmers' Day: the 256th day and a second pair of eyes

Today is the 256th day of the year. Two to the eighth, the number of values a byte can hold, which is why some programmers picked it as their day. In a leap year it lands on September 12; this year it's the 13th. We like that the date itself needs a little computing.

So happy Programmers' Day to everyone who writes code for a living, for fun, or at 1 a.m. because the build is red and the release is at nine.

The oldest quality tool

Ask a room of developers what catches the most bugs and you'll get a lot of answers: types, linters, unit tests, staging. All good. But underneath them is something older and simpler. Someone else looks at your work.

Code review, pair programming, a teammate reading your pull request over coffee, a tester trying the feature in a way you never thought of. The second pair of eyes works not because the other person is smarter, but because they don't share your assumptions. You know what the code is supposed to do, so you read what it's supposed to do. They read what it actually does.

One of us still remembers a review comment from years ago that just said "what happens if the cart is empty?" Three hundred lines of careful checkout logic, and nobody had tried zero items.

When the author is a model

A lot of code now has a different first author. An assistant writes the function, a person skims it, it looks right, it ships. That's not a complaint. It's how many good teams work today, and it's why we started building Testomatica.

But it changes what "second pair of eyes" means. If the model wrote the code and the same model, or a similar one, reviews it, those aren't really two pairs of eyes. They share the same blind spots, the same habit of producing something that looks plausible. Agreement between them proves less than it seems.

That's a big part of why we split the jobs the way we did. The LLM suggests, and code decides. Our explorer agents are good at the "what happens if the cart is empty?" kind of curiosity. They wander, try odd paths, poke at the edges. But whether something is actually broken gets decided by rules and by a referee that replays the steps with no model involved. Different eyes, on purpose.

It's the same distinction James Bach and Michael Bolton draw between checking and testing. Checks confirm what you already expected. Testing is the human, curious part that asks what you didn't expect. You need both, and they shouldn't come from the same place.

A small suggestion for today

If you're reading this on the 256th day, here's a low-effort way to celebrate. Pick one piece of code you merged this week that nobody else really read. Maybe an assistant wrote most of it. Ask a teammate to spend ten minutes on it, with one question in mind: what would break this?

You'll probably find nothing. Sometimes you'll find the empty cart.

We're getting ready to point our own second pair of eyes at a real staging site soon. Until then, happy Programmers' Day, and thanks to everyone who's ever left a review comment that started with "what happens if."