Welcome to the 76th edition of The Catch Block!

In this edition: Congrats! You fixed a bug. Now what? Plus: Minimal APIs and a new project structure; pipes and filters; new Visual Studio themes; exactly what is your job?; and building a weather station with JavaScript and Raspberry Pi.

So You Fixed a Bug. Now What?

That's the central thesis of Gérald Barré's new post:

I fixed a bug. What should I do now? - Gérald Barré
In this post, I describe how to fix a bug and prevent similar bugs from happening.

The mere act of fixing a bug is not enough, Gérald argues. You must do more, answer other questions that will help the people coming after you determine why the bug was a bug, what the fix was, why that fix was chosen, etc.

A large art installation of a preying mantic, made from oxidized metal.
Or, in this particular case, how big a swatter you need. Photo by NeONBRAND / Unsplash

Questions like:

  • What version of the app did you find this bug in?
  • What environment does the bug occur in? Production? On your local machine? Somewhere in between?
  • How easy was the bug to reproduce? What were the steps?
  • Did any of the app's dependencies come into play? Are they obsolete? Do you have them?
  • Is the project easy to get started on? Could an experienced programmer, with no knowledge of this app, get started working on it fairly quickly?
  • Where are the tests? Do they work?

Frankly, there's a lot to consider when fixing a bug. But we need to do so, because we want to make it easier on the next person who has to find a similar bug, which just might be us.

So, what do we do? We implement good debugging rules, which could include:

  • Pair programming or code reviews. Sometimes two eyes are better than one!
  • Turning on strict options for our compiler, such as treating warnings like errors.
  • Taking great care to prevent breaking changes, particularly in shipped APIs.
  • Fuzz testing, which takes randomly generated bad inputs and feeds them to a program, hoping to cause bugs.

Incidentally, this article reminded me of one of my favorite programming quotes:

"Everyone knows that debugging is twice as hard as writing a program in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -Brian Kernighan

This article is for paying subscribers only

Sign up now and upgrade your account to read the article and get access to the full library of articles for paying subscribers only.

Sign up now Already have an account? Sign in