Makers Academy Day 16

Sometimes debugging can feel this sad

Today we had a workshop on debugging strategies. After debugging a program we regrouped and had a really interesting discussion about the sort of skills debugging involved, and were tasked to come up with some advice for new programmers. Some Makers key words about debugging include:

“Tighten the loop — Get Visibility — Bugs only happen on one line — Find it — Print — Follow the flow — Diagram relationships”

The key thing about these steps are that when you’re debugging you never try out things randomly, or without a hypothesis. It’s critical to tighten the loop on the bug by finding the one line to work debug, then use tools systematically and strategically to solve the problem. Getting visibility on the problem by printing allows you to check if your assumptions are correct, following the flow in a systematic way means you can keep moving forward in the debugging process. The important thing is to always keep your hypothesis clear and systematically work through one thing at a time, reading all error messages as you go to get helpful information on the bug. Debugging must be hypothesis driven development: you’re the sniper not the automatic gun!

Sam our coach on debugging

Sam made a really interesting observation about why junior developers can often take the wrong approach in debugging. He described two mindsets a Programming mindset and a Debugging mindset:

Programming mindset: you have a problem- how do I solve that problem? Often a creative process.

Debugging mindset: you are not problem solving- you are hunting things down rather than creatively trying to problem solve.

When debugging you need to use metacognition tools, to firstly recognise what problem you have (I.e. a debugging rather than a programming problem) and then have a strategy for thinking about that problem. Hence why so many developers have a rubber duck when debugging, to go through the process of reasoning out loud.

We identified three key forms of error messages:

  1. Rspec failures- lots of helpful information in the message, these are best form of errors
  2. Error/Exceptions -maybe a test wasn’t created
  3. Silent failures- worst kind of error messages (see first image) skipped a convention is a common one

Finally to wrap up, here is some debugging advice that our group came up with:

  • Sense check accuracy in naming across files
  • Learn to read what an error says- try to break down lines
  • Know how to read the stack trace- where to start
  • Don’t try random changes- everything you do you should be able to justify/ rationalise
  • Everytime you’re about to change something have a strong hypothesis about what has to happen
  • Reason with pair (or rubber duck) about debugging steps before making changes
  • Don’t rely on just one tool — maybe another tool will give you more helpful feedback (tool configuration issues)
  • Simplify problem by removing stuff go back to 1 line- narrowing vision down to 1 line
  • Simplified version of the problem can make it easier — config setup can be difficult
  • Spend 5 mins to find flow of code- what does code do?
  • Hypothesis: keep this clear & stop continuously changing
  • Separate out if it’s ‘tools’ (E.g. configuration issue) or a ‘code’ bug