2013/Programming Is Debugging, So Debug Better
Debugging: The schedule destroyer, the confidence sapper, the mire in which thousands of working hours are lost every day. It’s time to stop staring at those four lines of code, desperately willing the bug to appear. This session is about the philosophies that will steer you around bugs, strategies for dealing with them, and tools that can shorten a four-hour debugging session to five minutes.
Speaker: Yoz Grahame
Return to this session's details
Contributed notes(Add your notes here!)
Yoz Grahame http://neo.com/ firstname.lastname@example.org @yoz
Chrome DevTools course http://discover-devtools.codeschool.com
“They Write The Right Stuff” - Charles Fishman, Fast Company Magazine, December 1996 “The Bug”, Ellen Ullman
“If you want to hear about the kinds of bugs you hit in virtual worlds... I will tell you about saving ice-skating horses from starvation.”
Pony Thieves - bad or unhelpful compilers, debuggers, libraries, editors, tools (taking away cake and ponies time, fun time)
1. Read the error (No, actually read the error) We usually make a lot of assumptions about what is going wrong, ignoring actual data about the error. Turn on syntax checking. Would love to see alerts from test runners when errors CHANGE. Fast iterations maintain momentum. "Anything you can do to cut down debugging time helps maintain your momentum" Compiler errors and warning are your friends
2. Check the stack trace If you can, print a trace on paper
3. Google the error Library/framework? Sometimes new frameworks have bugs, usually shared experience on google. Go look up the github repo issues or similar. "If you spend an hour staring at four lines of code, the bug is probably not in those four lines."
4. Get it out of your head (via your mouth) Rubber Duck debugging: talk to someone, even a rubber duck. "Visualizing the code with diagrams usually helps me work through them" Valerie Aurora, Ada initiative, linux file system
5. Create a repro test (reproducible bug) Tests are great because:
- super fast - automated setup/teardown - green/red is a definite yes/no - prevent regressions - remove the daunt & bugs from refactoring - great for metrics and analysis
Prevent bugs with automated analysis: linters, coverage checkers for tests, complexity analysis
Test & analysis automated quicky & cheaply: run tests automatically with continuous integration service (Travis-CI, CircleCI, Solana)
Static Code analysis: Code Climate for ruby, many open source tools for all languages Run web app tests across different browsers: Selenium, Sauce labs, browserling
6. Divide and Conquer - Isolate bad behavior
- Make the test smaller - Split up the method being tested - It’s caused by data? split up the data - Chrome DevTools Course
7. Validate your assumptions! "But this should work!" Go through each assumption you are making and check them individually
Bugs can lead to stress, confusion, disappointment, anger. Don't let it stop you thinking! [Step one, get to "impossible", step two, get past it.]
"We're here because some of your beliefs are wrong." "You have to treat it like an empirical science: go through your assumptions and try to disprove each one." -Lisa Dusseault
What's actually going on in your code?
Visual Studio - still best debugger in the business
Print statements suck as a debugging method: awkward to insert, dumb and non-queryable, hard to spot in output, easy to commit by accident. Remind me which decade you're in?
Command-line debuggers aren't great: obscure commands, bad visual structure
Web framework debuggers: Ruby: Better_errors (ruby web debugging framework) for rails/rack - exceptions get dressed up for info and code! Python: Werkzeug, django-debug-toolbar Perl: Plack::Middleware::Debug
Traditional debuggers have problems Too slow to invoke and get to the relevant code Step in/out/up/down dance is horrid … and often goes wrong
(shouldn't we have state trees for this?) "We should be past this by now"
Bret Victor - talks, learnable programming "The people who build the tools are too close" usability is about taking a step back and reinventing
Panorama Demo (based on new tools for ruby2) Panorama doesn't step through in execution, instruments it when its running and works out what its been doing
Web view, highlights each invocation, arguments in, result out, hover over ANY line for local variable states (tried to get coloring in for executed lines, [could color conditionals?]) https://github.com/yozlet/panorama
print statement vs visual debugging - Form a TESTABLE HYPOTHESIS vs just looking around. (different tools for different approaches)
There's so much more: Security Holes Database Consistency Resource leaks OS-Level problems ConcBururencgys Failures in production Performance problems Network debugging Text encoding Hardware Flaws Time & Date Everything Else
"Most dangerous people who don't know what they don't know"
"We surround ourselves with complexity we don't understand, and it crashes down on top of us."
This is the way the world ends, not with a bang, but with a bug.