Description
If you're pushing the envelope of programming (or of your own skills)... and even when you're not... there will be bugs in your code. The speaker has lots of experience perpetrating, finding, and fixing bugs. Most schools don't cover bug-hunting in programming and computer science classes. I cover the attitudes and skills that are most helpful to minimize your bugs, track them, fix them, ensure they never recur, and deploy fixes to your users.
In this talk, I describe how to start tracking down those pesky bugs, where they like to hide, how your brain tricks you, making it harder to find the bugs, and the processes that will help avoid them (or catch them early). Testing, pair programming, code reviews, open source ("given enough eyes all bugs are shallow"), when to use a bug-tracker, are just some of what I cover.
Of all the advice I impart in the talk, the one most important bit: once you've confirmed the existence of a bug, never start "fixing" it until and unless you have reproduced that bug in a unit test. Often this task surprises you by showing the bug is elsewhere than you originally thought - and in any case, writing the test, ensuring it breaks, fixing the code, running the test again to confirm it now passes, and leaving the test (small, simple, fast) in your unit test suite forever, is the only way you can ensure that bug doesn't slip in again without you noticing... (Some push this even further and apply "test-driven" or "behavior-driven" programming - far from bad ideas, if you find you can be productive using them!)
Most bugs tend to be concentrated in small parts of the code—the ones using too-advanced concepts, perhaps, or the ones where your original understanding of the problem (and thus the related architecture) was imperfect. You may discover where you have been too clever for your own good, and then you need to simplify those parts of the code. As Kernighan put it, "debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"