Debug It!
If there’s one thing I like about programming computers, it’s the ability to tell a machine exactly what to do. –insert Skynet reference here– With that said, I wanted to learn some more tips, tricks and techniques to figure out what exactly computers are doing when they’re misbehaving. I decided to grab a copy of Debug It! by Paul Butcher just to see what a whole book on debugging could possibly be all about. Initially I thought it would run dry of good topics early on, but there’s plenty to read about in this title.
Finding and Fixing Errors
Part of debugging is the ability to locate and eliminate defects. The book gave some really helpful tips on how to reproduce and diagnose bugs. Some of these are common sense, others aren’t so obvious. The author talks about how you can benefit from another person looking at it as well as keeping a log of all the “things” you’ve tried. Oftentimes, if you’re like me, you might even forget that a bug is anything that the software is supposed to do, but doesn’t do!
Preventing Bugs
Working in a bug free environment is great, but keeping the bugs away is difficult. “The Bigger Picture” section of the book does a nice job of talking about maintaining quality and preventing bugs from popping back up. Zero tolerance for defects and giving bugs top priority has certainly helped a major project I’ve worked on be a huge success. Keeping track of your defects with tracking software right from the get go is a pretty good idea, you’ll hear about that when reading this book.
More on Code Quality
While the book is primarily focused on how to avoid and remove defects, Paul also goes in depth on many other software development practices that support quality. Unit testing, source control, automation and project management practices. There’s a lot more than bug-squashing in this book, there’s a lot of good info on writing code that works. We all love code that works!
What Did I Think?
Overall, this was a really good read. There wasn’t anything Earth shattering, but it did align with some of my approaches to defects, as well as reinforce the things I don’t always do so well. Pablo and I give this one 5 out of 5 donkeys! Here’s a few things I’m going to try to keep in mind as I debug in the future:
- Don’t allow for black magic
- “Weird, that must have just been an anomaly” – No, it probably happened for a reason. What reason? Find out!
- “For some reason it XYZ’d” – If it does it once, it could probably happen again.
- Reflect on defects more:
- Why did this bug occur or not get caught in the first place?
- How can we avoid something like this from happening again?
Who Should Read This Book?
I think that this book should be read by all new software developers as well as all junior or mid-level developers. There’s plenty to be learned by the senior developer types too. Even if you’ve been doing these things for a long time, this is a good read to make sure you’re keeping your feet planted firmly on the ground.