Debugging and lessons in coding and life.
Kay led our first lesson of the day and we started with our first introduction to debugging: what it was, how to use it and best techniques for effective problem solving. Debugging didn’t sound like the work of the rock star coders but Kay pointed out that during a 12 week period as coders we could spend as much as 2 weeks of our lives debugging. We worked together to define what debugging was: tracing errors?, analysis?, insects?, error in code?, conflict?, unexpected behaviour? We came to the paradoxical question: if there is no test is there no bug?
At the end of our group discussion we concluded that a bug is when a test fails either in the program or the implementation. In unexpected machine behaviour we must have human expectation. Kay drew us back to Test Driven Development and pointed out that having expectations in code in tests is more reliable than having expectations solely in our heads. Our first instincts should always be to build a test for the solutions that we were trying to implement through our programs. At all times we should repeat the Makers mantra: “Tighten the loop, get visibility” in order to resolve bugs in the programs that we wrote.
Kay gave us a clear process to follow for finding errors. First we should look for the error type. Then we should examine the error and follow the stack trace to work out where it originated. Of course we could look for bad smells in the code and see if anything jumped out but the most important point was that effective response to the bugs required knowledge. Kay drew our attention to a second amusing paradox: we wrote the bug so working from our own first impressions to solve problems was a clear recipe for development hell.
The essence of the expert as Kay pointed out was the person who recognised that they were in an unprofitable situation and then decided to change this. The best way to do this was to get visibility on the problem, tighten the loop and only once we knew what was wrong try to fix the problem. Kay’s words of wisdom echoed through our heads like the oracle of Delphi: “Wisest are they who try only one thing to fix the problem.” It was easy to create more problems as we tried to correct bugs so we should be conscientious about recording and building on our thought processes in correcting code. We then settled down to practice exercises checking over gem files and code errors including our tutor Sam’s inventive take on the Geocoder gem ‘broken-geocoder’: https://rubygems.org/gems/broken-geocoder/versions/1.3.6
After a thoughtful morning practicing our debugging skills we returned to pair coding on our week challenge (writing a Boris Bikes app). I worked with the consummate Ainsley who had gained three years experience in computers although this was a first foray into coding with Ruby. We quickly developed a thoughtful working relationship as we methodically explored each of the Sam’s careful step by step challenges. One particularly interesting problem involved working out how to show error exceptions when there were no bikes available in the DockingStation class. To complete this challenge we made a block for the raise_error rspec command and also used # to specify a method within the DockingStation class. After a challenging day, we had a clearer idea of the importance of testing for code development and also how to specify tests more clearly.