1. 21
  1.  

  2. 5

    One way of dealing with this that I’ve learned and find effective is to let the person that asks for help do the driving with you directing. Doing so slows down the debugging itself but greatly expands on the learning of both parties. You need to be confident enough to tell ‘sorry, I’m interested in what you have tried, but I have no way of judging what you say in terms of the current code you’re working on, so please show me what’s going wrong and how the code looks’.

    Often, I found, just slowly walking through code together will highlight the problem in and of itself, without having needed the extra expertise that may be present in the one helping. Plus, having the respect to work at each other’s speed definitely breeds trust and confidence, and helps working together as a team.

    1. 3
      6 is my favorite part: “How did that ever work?”

      Normally it is during this phase of debugging that you find some oddball construction which just so happens to work in a majority of cases, but then degrades the very second an edge case occurs.

      1. 2

        The reason I take the “step aside and let me drive” approach is often because the person I’m trying to help is diving into details that I have no idea about (maybe it’s code I’m not familiar with, or maybe it’s something new they’ve written so I haven’t had a chance to see it before), so I need to poke at it myself before I can talk to them about the problem or tell them how to solve it.

        1. 1

          “Just the facts, maam.”