In theory, programmers spend lots of time developing new software. But in practice, developers spend a great deal of time debugging, trying to figure out why their code doesn’t do what they expect. The problem is that most debuggers operate similarly to how debuggers did 20, 30, or even 40 years ago. In particular, there’s no way to run a program backwards; part of debugging means that you need to catch the problem as the program runs, and then examine the state. In this talk, George Hotz introduces the idea of “timeless debugging” — in which the debugger knows how to unwind history, letting you backward as well as forward.
All developers have to debug their code at some point. But there are particular practices that, when used, can make debugging significantly easier, faster, and most efficient. One overall perspective that can help is that of the scientific method. In this talk, Stuart Halloway describes how he approaches debugging using a scientific approach, and how doing so makes debugging less of a depressing and tedious chore, and more one that helps to move a project forward and provide the developer with greater understanding. His examples all employ the Clojure language, but the lessons learned can be generalized to many languages.
Pry is an improved REPL (read-eval-print loop) for Ruby programmers, replacing the standard IRB tool. You can use Pry as a debugger, as well. In this talk, Joel Turnbull demonstrates how we can use Pry as a debugger, to analyze, fix, and even plan Ruby and Rails applications.
How do you debug software? Bithe Rocher, with a PhD in physical chemistry, suggests that we use the scientific method — which will not only help us to find problems in our code, but also help us to learn.