2

How can one become better at debugging in general? I do not mean specific tools or tactics that apply to a certain programming language or stack, but simply how to make your mind better at it, hopefully something beyond "just more exercise".

I am fairly good at "blank sheet" type programming problems: I can easily code something from scratch, even starting from the lowest level and coding the framework in the process than maybe extracting the framework and using it in another project or doing a fancy rearchitecture of a complex piece of software. But compared to most people I've worked with, I am extremely bad at detail oriented debugging, and by this I mean finding that little misinterpreted error code, those parameters passed in the wrong order that gave birth to a wrong sql query n-levels deep, or that little configuration bug that made the testing server behave totally different from the production one or other "micro" bugs.

I sometimes feel that my mind is not made for this. Even in other areas with a high-level vs. low-level separation I get something similar, like when I write something, regardless of the language, despite my decent knowledge of spelling and grammar, I'm spell-checking dependent - when I focus on what I write, my mind becomes blind and I make horrendous spelling and grammar errors. And almost everything I happen to be doing, my mind drifts away to the higher level views and concepts (my mind is somehow "made for" architecting stuff and viewing high level patterns) and I become mostly blind to low level stuff and I'm very bad at debugging the errors at these levels. I get this detail blindness even when the lowest level code is written by me.

So again, what do you do and know it works to get over this detail blindness and debugging induced mind-block and become better at the task of debugging yours or others code? (I'm looking for as much facts and as little subjective opinions as possible for this question...)

Note: I mostly work in Python, Javascript and unfortunately PHP and rarely delve into C and I'm currently learning Haskell FTR, but I'm not looking for a language or tech specific solution - its more a "how do I reprogram my mind to become better at this" problem.

gnat
  • 21,442
  • 29
  • 112
  • 288
NeuronQ
  • 221
  • 3
  • 8
  • maybe find someone to pair with? You're more likely to spot these kinds of errors as a pair, and (if you choose well) your partner can probably teach you a thing or two about debugging too. – hdgarrood Feb 13 '13 at 21:06
  • 1
    Volunteer for bug duty, nobody will complain because they don't want it. Fixing defects is a grade A way to learn a code base and develop your personal workflow for tracking down issues in that code base (which often works across many). – Jimmy Hoffa Feb 13 '13 at 21:07
  • The single thing that helped me the most: **Don't get frustrated.** It kills your ability to think. – Zachary Yates Feb 13 '13 at 21:12
  • @JimmyHoffa haha, that's good. Q: 'How to get better at something?' A: 'Do it a lot.' – Zachary Yates Feb 13 '13 at 21:15
  • When you do get frustrated, stop and do something mindless. Or just call it a day and let sleep clear your head. – Gort the Robot Feb 13 '13 at 21:18
  • 2
    Every outstanding troubleshooter I have met share one common characteristic. They retain information. They know where to look because they know where they have found simliar issues before or exactly which part of the application affects that particular problem or which database tables store the information and how they are populated. People who throw away information (because I can always look it up), tend to have more difficulty with debugging. Partly because by retaining information you start to see patterns in it that you won't notice if you only look up stuff. – HLGEM Feb 13 '13 at 21:34
  • @HLGEM you may be right. Being a bit of a "high level jack of all trades", my knowledge in lots of areas is the "I know how and where to find out about this in under a min" type of knowledge instead of the "I actually know this". Maybe I should free my lazy mind of other stuff and just find a way to just "load more of the codebase into it"... – NeuronQ Feb 14 '13 at 09:16

2 Answers2

10

David Agans wrote a pretty good book on the subject, breaking it down into 9 fairly objective rules:

  • Understand the system
  • Make it fail
  • Quit thinking and look
  • Divide and conquer
  • Change one thing at a time
  • Keep an audit trail
  • Check the plug
  • Get a fresh view
  • If you didn't fix it, it ain't fixed

I've always considered myself a fairly intuitive debugger, and saw it as more art than science, until I read that book, which verbalized a lot of the habits I picked up, making them concrete and objective.

The basic idea is to be methodical about it, instead of haphazard. If you get blinded by details, and distracted by the high-level view, write things down. Put temporary comments in the code to track your place, or keep track of what you've already tried on a whiteboard. Use a debugger, so you know exactly what arguments are being passed at the lowest levels of the call stack. Then once you're sure the lowest layer is good, work your way up, but write it down so you don't revisit the same thing over and over.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 2
    The most common failure case I see when people debug is to try a fix too quickly, and then assume it worked when it "works" in the originally reported failure case. If you can't say why it failed, you aren't done. The only rule I'd add is "take a break". I can't tell you how many bugs I've fixed within a half hour of arriving at work in the morning following a frustrating late day of failure the day before. – Gort the Robot Feb 13 '13 at 21:17
  • +1 just for your first bullet point alone (the rest is good too). I have learned the more I understand at the nuts and bolts level what I am fiddling with, more quickly I can debug problems by very effectively "Checking the plug", from the bottom up or the top down, either way pick a starting point an ending point and check each plug all the way along that path. Key to this is really understanding the system so you know all of the plugs it has. Also key in being efficient is again, understand the system so you choose the closest starting point and ending point to your problem at the start. – Jimmy Hoffa Feb 13 '13 at 21:19
  • Spent 6 hours today trying to debug something till I clocked off. Two hours after I realised how to tease apart the problem. I think the problem is my expectations where way off. Some debugging cases are really hard and require an ingenious solution to expose the bug. If you don't try to expend mental effort finding an ingenious solution you just end up wasting your time. – Tom Huntington Oct 04 '22 at 08:50
1

Well, to do debugging like you described, messed up sql queries and config and other misterious things, you have to know the system inside out. Especially for cases where the app runs seemingly ok but gives out wrong data. The outright crashes are relatively easy compared to logical errors.

But to fix those, you really have to know what that part of the application needs to be doing, and how it's doing it, and then you need a good understanding of how what it is doing now is wrong. Something like "it's just wrong data" is not enough. Look for patterns in the errors, because programs are not random. Spotting patterns can get you to that light-bulb moment when you realize, oh it must be something with the query, and then you track it down. This is something that is not easy if you are not familiar with the system, or have experience with similar systems, so I'm willing to bet that you're no worse at it than anyone else who's been given an app to maintain but not enough time to get to know it.

Also, learn to really read the errors that the language gives you. Get to know its codes/messages whatever. I see a bunch of people giving up when they get a cryptic exception. They don't know what it's saying and they start blindly poking around, which leads to frustration. Knowing exactly what can trigger that particular exception with that message can get you going in the right direction.

On a side note, I really hope you're using something like XDebug when working with PHP and not just throwing echo/var_dump/print_r statements around.

Ivan Pintar
  • 1,177
  • 1
  • 8
  • 15
  • yeah, xdebug is the only thing that makes PHP debugging bearable imho. But the people that I know to be "really good at debugging" can do way more with a lousy editor and var_dumping around than I can do with xdebug... so I know it's not a tools issue. – NeuronQ Feb 13 '13 at 21:23
  • I agree, but as you said, it makes it bearable, and those guys are probably all the better for it. – Ivan Pintar Feb 13 '13 at 21:25
  • 1
    Yes! Read the error message and understand what it means. I have seen so many posts here where the answer has aslight error in it and the poster comes back with some really obvious error code and no idea what it meant. I have seen people stuck for hours or even days on an error that I could fix in less than 5 minutes becausue I know what the error means. – HLGEM Feb 13 '13 at 23:00