I Kept a Bug Journal for 200 Days. My Bugs Were Not What I Expected

On a Monday in January I started a plain text file called bugs.txt. Every time I spent more than 15 minutes on a bug, I wrote one entry: the date, how long it took, what the bug was, and what finally fixed it. I kept it up for 200 working days, which ended in late October.

The file has 143 entries. I categorized them on a rainy Saturday afterwards, and the results were humbling.

What I thought I would find

If you had asked me in January, I would have said my weak spots were concurrency, async code, and anything involving time zones. Those are the bugs that feel hard. They are the ones I tell stories about at lunch.

Concurrency bugs made up 7 of 143 entries. Time zones, 4. Together they accounted for about 9 percent of my bug time. They were memorable because they were long, sometimes a whole day each, but they were rare.

What I actually found

The largest category, by far, was something I ended up labeling "did not read the whole message". That was 31 entries. An error message or a log line or a stack trace contained the answer, and I had read the first line, formed a theory, and gone chasing it. Typical example: a test failed with a long assertion error, and the real cause was in the last line, which said a config file was missing.

The next categories were:

• Wrong assumption about data shape — 26 entries. I assumed a field was always present, or a list was never empty.
• Stale state — 19 entries. Old build artifacts, a cached dependency, a container running an old image.
• Environment differences — 17 entries. Works locally, fails in CI.
• Actual logic errors — 22 entries. The bugs I would have called real bugs.

The rest were a long tail of typos, wrong branches, and one memorable case where I was editing a file in the wrong copy of the repository for forty minutes.

Changes I made

Once I saw the numbers, the fixes were almost embarrassing.

I now read error messages from the bottom up. For stack traces in most languages, the bottom is closest to the real problem. I literally scroll down first.

I added a make clean-all command to every project that wipes build outputs, caches, and restarts containers. When something is weird, I run it before thinking. It fixes the stale-state category about half the time in under a minute.

For data shapes, I started writing small validation at the boundaries of my code, where data comes in from an API or a file. It is boring and it saves hours.

The value is in the boring entries

The exciting bugs are the ones we remember, so they shape how we think about our own skill. The journal showed me that most of my lost time was in boring, preventable mistakes. That is actually great news. Boring mistakes are easy to fix with habits.

I have started a second file this year. So far, the "did not read the whole message" category is down to 4 entries in three months.