Why Developers Are Luckier Than Most
A friend who works in product asked me the other day: "You programmers write code all day — how do you know if what you wrote is correct? Do you have to manually test everything after each change? That sounds exhausting."
I told her: "No manual testing. Just run the tests and you know."
"What are tests?"
"Basically an automatic checking system. After you change code, the system tells you what's right and what's wrong."
"Sounds like a medical checkup report."
That comparison was perfect. What I learned today — coverage testing — is essentially a health checkup for code.
Green and Red
Opening the coverage test HTML report, the screen shows lines of code marked by color:
- Green: covered by tests, has been executed
- Red: never touched by tests, never run
Just like a doctor reading lab results: normal indicators are green, abnormal ones are red. No guessing. No deduction. One glance and you know where the problems are.
I stared at the screen for a while. Not because I didn't understand — because it was so direct.
You wrote 100 lines. The report tells you: 80 green, 20 red, 80% coverage. Which specific 20 are red? Click in, line by line, all marked.
For someone in product, this precision of feedback is probably hard to imagine.
Most People Don't Get This Kind of Feedback
My friend said: "You programmers are lucky — you know immediately if you got it right."
She's right.
She shipped a new feature. User feedback: "feels off somehow." What's off? Who knows. Is it the interaction flow? The copy? The overall positioning? You can only slowly analyze data, slowly dig through user interviews.
Job interviews are the same way. You bomb it, but you don't know which answer was wrong. Maybe three months later you vaguely guess what you should have said.
At least doctors have lab results. But most things in life? There's no report marking things green and red telling you: this was right, this was wrong.
You rely on intuition, on experience, on trial and error.
Coverage tests just say: these 20 lines of code have never been executed. Not "maybe," not "possibly." Definitely.
This fast, precise, unambiguous feedback is a privilege of this profession.
What Tests Really Are: Daily Rounds
My friend asked: "So what exactly are tests doing? Making sure there are no bugs?"
Yes, but not just that.
I used an analogy: imagine a hospital with one doctor responsible for all patients. When there are few patients, they remember each person's condition. But with more? 100 patients, each with medications, contraindications, allergy histories — impossible to remember everything.
So what do you do? Daily rounds, checking charts.
The medical chart is the test. It records key information for each patient. The doctor doesn't rely purely on memory — one glance at the chart and they know how to proceed.
Code is the same. Small project, you remember what every line does. Big project, 100 files, tens of thousands of lines — change one line, will it break something else? Hard to say.
Run the tests:
- All green? Relax, nothing broken
- Some red? Read the error message, it tells you what went wrong
Tests are medical charts for code. You don't have to keep all logic in your head. Outsource it to the testing system.
The Wisdom of Layering
There's a deeper truth here that my product friend would understand: good systems are layered.
Human brains have limits. Doctors can't remember 100 patients' conditions, so we invented charts. Programmers can't remember tens of thousands of lines of logic, so we invented tests.
Outsource the "remembering" part. The brain only needs to focus on the small piece currently being handled.
Coverage tests go one step further — they're charts for the charts. They tell you: which code is your testing covering, which isn't.
Tests test code. Coverage tests test tests. Layer by layer, each layer catching what falls through.
A Thought
After this lesson, I understand "feedback" differently.
Building products, designing, doing any creative work — the hardest part often isn't execution. It's not knowing whether you're doing it right.
Programmers are lucky. We have tests, coverage reports. Change code and know the result in seconds.
For anyone building products, I'd say: if you can establish a "fast feedback system" in your domain, that's a huge advantage.
Even if it's not as precise as code testing, anything faster than "find out three months later whether it was right" is worth investing in.
That's probably the insight I'm taking from today's technical learning that transfers to other domains.
Top comments (0)