5 ms·

Maybe the other person in the pair is forgetting to use their tools because they are stressed out by the aggressive person standing over their shoulder looking

Maybe the other person in the pair is forgetting to use their tools because they are stressed out by the aggressive person standing over their shoulder looking for any excuse to grab the keyboard?

kctess5 10y ago
Sometimes, this might be the case, however after the nth time of nicely saying "oh btw you can just do [insert shortcut] and find it right away!" it's hard to not get frustrated. I have definitely worked with people who for whatever reason, absolutely refuse to learn their text editors and debugging aids.
- hinkley 10y ago
  Usually this becomes an interpersonal issue when you're working with someone who has a track record of only changing 90% of the code that needs to be changed to implement a feature/bug fix because they keep missing one spot where the information is used.
hinkley 10y ago
cough I have no idea what you're talking about. Mostly I think the exploratory phase of debugging is a battle between your limited short term memory and your imagination. It's a think you need to do alone and without someone stopping you to ask why every fifteen seconds. I think that's why people are so big on repro steps, so they can go off and start the process of elimination without having to dump state while defending checking possibility A before checking possibility B. I think the only reason (besides tenacity) that I fix bugs that others gave up on is that I have tricks that let me walk the code faster, which lets me make forward progress on deduction before I forget WHY I was looking under this rock in the first place. My debugging practices look not unlike a guy looking for his missing keys. You have to be careful about when to hit him for questions, and most of the time it's better to just start your own parallel search if you want to help.
- kbenson 10y ago
  > which lets me make forward progress on deduction before I forget WHY I was looking under this rock in the first place. There's nothing quite as deflating as finally getting to the end of diagnosing a particularly pernicious bug just to have the understanding trigger the realization that you've encountered this bug before a year or two prior, spent just as much time originally figuring it out, and had somehow forgotten about it the interim. Yay for wasted days of our lives.
  - erikpukinskis 10y ago
    Whenever I unravel a hard-to-diagnose bug, my first step is always to put a better error message in the place where it would have been properly diagnosed.
    - kbenson 10y ago
      Sure. I can't recall the last bug that brought this feeling (sigh, the circle continues), but I vaguely recall it being a weird interaction or behavior when interacting with some remote system, and it wasn't in fixing a bug that popped up, but in implementing a new feature or system that interacted in a similar way, but the prior implementation was either in a different project or had since been discarded. I know that's vague. That probably means I'll encounter this again and not identify it as the same problem. :/ I think I need to make a concerted effort to get more sleep.
  - hinkley 10y ago
    // Increment this number every time you end up here // time spent = 30
  - TeMPOraL 10y ago
    If you haven't recognized your "old bug friend" during the figuring-out process, maybe the path that lead to the bug was different this time? I.e. you have an old bug in a new context, which is almost like a fresh new bug. Personally, when I find out / solve something tricky I note down the details in a notes file exactly for cases like this. I'm yet to use it though, because I usually remember the weirder bugs I've seen.
coldtea 10y ago
Yeah, it's not that. Lots of programmers inherently don't use the tools at their disposal... something which also shows on the code they right...
- mixedCase 10y ago
  Maybe tooling doesn't always go deep enough where it matters. For example, your spell checker didn't help you at all in that last sentence.
  - coldtea 10y ago
    I didn't use it, which further proves my point!
    - lomnakkus 10y ago
      How would it have? What you have isn't a spelling error, it's a grammatical/word choice error.
      - coldtea 10y ago
        Spell checkers also have grammar checking modes...
  - fenomas 10y ago
    Assuming you mean right/write, it would need to be a grammar checker, and a damned good one at that.
    - coldtea 10y ago
      Or just one that uses statistical probabilities...
- pjmlp 10y ago
  A good example, graphical debuggers. Already in late 90's I couldn't believe what UNIX coders considered state of art, versus what we had on Mac/Windows/Amiga environments (the ones I knew before UNIX).
lmm 10y ago
Maybe sometimes. I've certainly worked with someone who explicitly said "if your first instinct on seeing an error is to reach for a debugger you're probably not a good programmer", and as a result he'd spend hours tracking down a bug that could be solved in minutes by someone willing to actually use tools. Even more unfortunately, a lot of the junior programmers on the project listened to him and wouldn't use debuggers either.

Maybe the other person in the pair is forgetting to use their tools because they are stressed out by the aggressive person standing over their shoulder looking for any excuse to grab the keyboard?

kctess5 10y ago

Sometimes, this might be the case, however after the nth time of nicely saying "oh btw you can just do [insert shortcut] and find it right away!" it's hard to not get frustrated. I have definitely worked with people who for whatever reason, absolutely refuse to learn their text editors and debugging aids.

hinkley 10y ago
Usually this becomes an interpersonal issue when you're working with someone who has a track record of only changing 90% of the code that needs to be changed to implement a feature/bug fix because they keep missing one spot where the information is used.

hinkley 10y ago

cough I have no idea what you're talking about. Mostly I think the exploratory phase of debugging is a battle between your limited short term memory and your imagination. It's a think you need to do alone and without someone stopping you to ask why every fifteen seconds. I think that's why people are so big on repro steps, so they can go off and start the process of elimination without having to dump state while defending checking possibility A before checking possibility B. I think the only reason (besides tenacity) that I fix bugs that others gave up on is that I have tricks that let me walk the code faster, which lets me make forward progress on deduction before I forget WHY I was looking under this rock in the first place. My debugging practices look not unlike a guy looking for his missing keys. You have to be careful about when to hit him for questions, and most of the time it's better to just start your own parallel search if you want to help.

kbenson 10y ago
> which lets me make forward progress on deduction before I forget WHY I was looking under this rock in the first place. There's nothing quite as deflating as finally getting to the end of diagnosing a particularly pernicious bug just to have the understanding trigger the realization that you've encountered this bug before a year or two prior, spent just as much time originally figuring it out, and had somehow forgotten about it the interim. Yay for wasted days of our lives.
- erikpukinskis 10y ago
  Whenever I unravel a hard-to-diagnose bug, my first step is always to put a better error message in the place where it would have been properly diagnosed.
  - kbenson 10y ago
    Sure. I can't recall the last bug that brought this feeling (sigh, the circle continues), but I vaguely recall it being a weird interaction or behavior when interacting with some remote system, and it wasn't in fixing a bug that popped up, but in implementing a new feature or system that interacted in a similar way, but the prior implementation was either in a different project or had since been discarded. I know that's vague. That probably means I'll encounter this again and not identify it as the same problem. :/ I think I need to make a concerted effort to get more sleep.
- hinkley 10y ago
  // Increment this number every time you end up here // time spent = 30
- TeMPOraL 10y ago
  If you haven't recognized your "old bug friend" during the figuring-out process, maybe the path that lead to the bug was different this time? I.e. you have an old bug in a new context, which is almost like a fresh new bug. Personally, when I find out / solve something tricky I note down the details in a notes file exactly for cases like this. I'm yet to use it though, because I usually remember the weirder bugs I've seen.

coldtea 10y ago

Yeah, it's not that. Lots of programmers inherently don't use the tools at their disposal... something which also shows on the code they right...

mixedCase 10y ago
Maybe tooling doesn't always go deep enough where it matters. For example, your spell checker didn't help you at all in that last sentence.
- coldtea 10y ago
  I didn't use it, which further proves my point!
  - lomnakkus 10y ago
    How would it have? What you have isn't a spelling error, it's a grammatical/word choice error.
    - coldtea 10y ago
      Spell checkers also have grammar checking modes...
- fenomas 10y ago
  Assuming you mean right/write, it would need to be a grammar checker, and a damned good one at that.
  - coldtea 10y ago
    Or just one that uses statistical probabilities...
pjmlp 10y ago
A good example, graphical debuggers. Already in late 90's I couldn't believe what UNIX coders considered state of art, versus what we had on Mac/Windows/Amiga environments (the ones I knew before UNIX).

lmm 10y ago

Maybe sometimes. I've certainly worked with someone who explicitly said "if your first instinct on seeing an error is to reach for a debugger you're probably not a good programmer", and as a result he'd spend hours tracking down a bug that could be solved in minutes by someone willing to actually use tools. Even more unfortunately, a lot of the junior programmers on the project listened to him and wouldn't use debuggers either.