For most of my career I treated tests the way I treat flossing. I knew I should. I felt vaguely guilty that I didn't. And I had a long list of reasons why this particular week was too busy to start.
Then I shipped a bug that took down checkout on a Friday afternoon. The fix was one line. The bug had existed for three weeks. A test I could have written in ninety seconds would have caught it the day I introduced it.
I'm not going to tell you to write more tests. Everyone says that and nobody listens, including past me. I'm going to tell you about one small habit that snuck testing into my work without the dread.
The habit that changed everything: write one test the moment you fix a bug, before you close the ticket — a test that fails on the old code and passes on the fix. It's tiny, it's motivated by real pain, and it slowly builds a safety net out of your actual mistakes.
The short version:
The standard advice fails because it's shaped wrong. "Achieve high test coverage" is a giant, abstract, joyless mountain. You look at an untested codebase and the task feels infinite, so you do nothing.
It also arrives at the wrong moment. People tell you to write tests when you're starting a feature — exactly when you're most excited to build and least interested in writing what feels like homework about code that already works in your head.
The motivation is all wrong. You don't feel the value of a test until something breaks. So writing tests up front is an act of pure discipline, and discipline is a terrible thing to depend on. Building habits that don't lean on willpower is a recurring theme in the brutal truth about becoming a senior developer, and testing is the clearest case of it.
The trick is to hijack a moment when the motivation is already there. And there's one perfect moment: the instant after you've been burned.
Here's the entire habit. It's almost embarrassingly simple.
That's it. You've added one test, written at the exact moment you cared most, that documents a real failure mode and guarantees it never comes back.
The genius is the motivation. You don't have to will yourself to write this test. You want to, because you just felt the pain. The test is your revenge on the bug.
Do this for a few months and something quiet and wonderful happens. Your test suite stops being a chore and becomes a scar collection — a precise record of every way your software has actually hurt you, each one now guarded.
There's a deeper principle hiding in this habit, and it's worth saying out loud.
The most valuable tests aren't the ones covering the most code. They're the ones covering the code most likely to break in ways you'll regret. Bug-driven testing finds those automatically, because reality tells you where they are.
Think about where you'd rather have a safety net:
| Code area | Likely to break? | Cost if it breaks | Test priority |
|---|---|---|---|
| Payment / billing | Sometimes | Catastrophic | Highest |
| Auth and permissions | Sometimes | Severe | High |
| Core business logic | Often | High | High |
| A static marketing page | Rarely | Low | Skip |
| A simple display helper | Rarely | Low | Low |
Chasing a coverage percentage spreads your effort evenly across all of this, including the boring corners that never break. Following the pain concentrates it exactly where it pays off. Let your bugs do the prioritization for you — they're brutally honest about where the weak spots are.
I started this purely for safety. The surprise was what it did to the code itself.
When you have to write a test for a bug, you're forced to make the code testable — and testable code is almost always better code. Tightly tangled functions are hard to test. So little by little, fixing bugs with tests nudged me toward smaller functions, clearer inputs and outputs, fewer hidden dependencies.
I wasn't trying to improve my architecture. The testing habit dragged it along behind me.
A test is a question you ask your code: "do you still do what I think you do?" The terrifying part of legacy code is that you can't ask.
This is also where good developer tools earn their keep. A fast test runner that gives you results in a second, a watch mode that reruns on save, a framework that makes writing the test almost frictionless — these turn the habit from a sigh into a reflex. It's the same compounding effect I describe in the engineering habit that doubled my output: a small repeated motion that quietly pays for itself. Industry data backs this up too — the Stack Overflow Developer Survey consistently shows automated testing among the practices high-performing teams actually keep. The lower the friction, the more the habit survives a busy week.
If you have no tests at all, the mountain feels unclimbable. Don't climb it. Just start the habit on the next bug and let the suite accrete.
A few things that lowered the barrier for me:
Within a few months I had a suite I trusted, built entirely from bugs I'd actually hit, with not a single hour of dedicated "let's add tests" drudgery.
Something I didn't expect: once the bug-driven habit was firmly in place, it started to leak forward in time.
At first I only wrote tests after a bug burned me. But after enough of those, I began to recognize the shape of code that was about to bite me. Tangled conditionals. Functions that did five things. Logic that handled money or time or permissions. My instinct started whispering "this is the kind of place a bug lives" before any bug had appeared.
And without forcing it, I started writing tests for those risky spots up front — not out of discipline, but out of pattern recognition. The pain of past bugs had trained me to smell the next one. The habit that began as revenge on bugs became a quiet early-warning system.
That's the deeper payoff. You don't just build a safety net; you build an intuition for where the net needs to be. The tests become a side effect of a sharpened sense for fragility.
I also noticed it changed how I reviewed other people's code. I stopped scanning for style and started asking "what would break here, and is it tested?" — which is a far more useful question. The bug-driven habit didn't just make my own code safer. It made me a better reader of everyone's.
If you'd like more small habits like this one that compound over a career, it's worth following along with the rest of the series.
Q: Should I really not chase code coverage? Coverage is a useful diagnostic, not a goal. A high number from tests nobody trusts is worse than a low number from tests that catch real failures. Let coverage be a byproduct of testing what matters, never the target itself.
Q: What about testing before there are any bugs — like TDD? Test-driven development is great once testing already feels natural to you. But it's a hard place to start if you have testing dread. Bug-driven testing builds the habit and the comfort first; many people graduate to writing tests up front once it stops feeling like work.
Q: My bugs are often in messy, hard-to-test code. Now what? That's a signal, not an obstacle. If a bug lives somewhere untestable, the untestability is part of the bug. Extracting just enough of that logic into a testable piece is usually the cleanest fix — and you improve the design while you're at it.
Q: How long until this pays off? Sooner than you'd guess. The first time a test you wrote for an old bug catches the same mistake before it ships, the habit sells itself. For me that took a few weeks.
You don't need more discipline to test more. You need to stop fighting your motivation and start using it. The moment after a bug is the moment you care most — so spend it building the thing that prevents the next one.
Write one test, for the bug that just hurt you, before you close the ticket. Do it again next time. That's the whole habit, and it's the one I'd hand my younger self if I could.
What's the last bug that cost you a Friday? Write the test for it now. It's the cheapest insurance in software, and you already paid the premium in frustration.
I spent years saving the hardest task for when I 'felt ready.' Doing it first instead quietly fixed my focus, my dread, and my output.
I tracked every distraction for a week and was horrified by what I found. Then I fixed the three that mattered most.
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!