There’s a special little moment that happens when you explain a system to a programmer. You’re cruising along, describing how everything works, and then they ask the dreaded question:
“How often does that happen?”
And you, being a reasonable person, say: “Oh, hardly ever.”
Their left eye twitches.
“Hardly ever?” they repeat slowly.
“Yeah, almost never,” you add, trying to be helpful.
Their right eye twitches.
What you’ve just witnessed is the exact moment a programmer realises they are going to have to code for the thing that almost never happens, because “almost never” is not “never,” and the gap between those two words is where systems go to die.
The Two Buttons
Let me give you a deliberately silly example. Pretend you’ve got a process where a customer is shown two buttons:
- Button One gives them $100
- Button Two gives them $1
You sit down with the programmer and say, “Look, everyone clicks the $100 button. Just code that one.”
And the programmer goes, “Hang on. How often does someone press the $1 button?”
“Hardly ever.”
“So… sometimes? It can happen?”
“Yeah, but it’s so rare you don’t even need to worry about it.”
“What happens when they press it, though?”
“You don’t have to worry about it, it barely ever happens…”
“No, no. I need to worry about it. When that button gets pressed, I have to handle it.”
“Oh. Well, we give them a dollar instead of a hundred. Easy.”
“Right. So 99% of the time people do one thing, and 1% of the time they do another thing. Which means I need to code both.”
And there it is. The whole job, summed up in one twitchy little exchange.
Managers tend to handle how often something happens, Programmers want to know about the number of ways something that can happen.
Why Our Brains Trick Us
Here’s the thing: when we describe a process, we naturally think of what happens most of the time. It’s not laziness; it’s just how brains work. The common case is loud and obvious. The weird edge case is quiet and easy to forget.
There’s another reason too.
Back when these processes were manual, the weird stuff never really disappeared; it just got quietly absorbed by a human.
Someone in accounts. Someone in a vaguely-named miscellaneous admin department.
A person who’d notice something odd, make a phone call, sort it out over a cup of coffee, and move on with their day. The edge cases were always there. They were just being handled by a human firewall you never thought about.
Then You Automate
And this is where it gets spicey. The moment you hand the process to a computer, that human firewall is gone. The computer doesn’t make phone calls. The computer doesn’t have a hunch that something looks off. The computer does exactly what it was told, and absolutely nothing it wasn’t.
Those damn computer only doing what we ask them to – not what we want!
So if a case shows up that the programmer never knew about and never coded for? The system doesn’t quietly improvise. It falls over. Loudly. Usually at 4:55pm on a Friday.
That’s why a programmer can’t think in terms of “what usually happens.” They have to think in terms of “what is every single thing that could possibly happen here, and what do we do about each one?” The $100 button and the $1 button and the what-happens-if-they-press-nothing button and the what-happens-if-they-press-both-somehow button.
Be Gentle with your Programmers
So next time a programmer asks how often something happens, and you hear yourself reaching for “hardly ever,” just know what you’re really saying is: “This will absolutely happen, probably to your most important customer, and we should definitely code for it.”
It’s not that programmers are pessimists. It’s that “hardly ever” and “almost never” are both just polite ways of spelling “yes.”
And that, me old mates, is why both their eyes are twitching.