[kenjackson]

For the poor performers they may be nothing you can do. But for the merely "very good" are there practices that Balestra can teach them?

For example, one thing I've seen that can increase productivity by a factor of ten is good debugging skills -- which are generally teachable. The other thing is to get people on things they're excited about. Mentally checking out is another area I've seen strong people lose time.

[agavin]

Good debugging is key, and as anyone who ever worked with me will note, I'm a fantastic debugger (in no small part because I'm cold, rational, and rarely get upset). I keep meaning to write up a post for my blog with "Andy's rulez of debugging." There are really very simple, but very effective.

Like: "don't assume" and "divide and conquer" (they do require a bit of explanation)

[jcheng]

Please do write that post, I for one would love to read it.

[EmployedRussian]

I wonder if you have much to add to http://www.amazon.com/Debugging-Indispensable-Software-Hardw... (which I really like).

Rule 5: "Quit thinking and look" is (I think) equivalent to your "don't assume".

Rule 6: "Divide and Conquer".

[agavin]

I'll have to check that out. Although my advice will be free :-) But I'm sure that many many other good debuggers have developed the same basic techniques independently. Still, the vast majority of programmers could use some improvement in this area. "Quit thinking and look" is exactly what I mean by "don't assume." People tend to get wrapped up their own view of things and forget that empiricism really wins the day. There is often even fundamental denial, as in "what bug? I haven't seen it." Clearly if someone saw it, unless they were hitting the crack pipe, it's real.

[joe_the_user]

I often find that looking at the code hard and adding the appropriate tests and asserts can be better than immediately pulling out the debugger. Assert are continually testing your assumptions where you can only see them once in a debugging session.

[ntoshev]

Debugging is almost always about uncovering wrong assumptions, but I don't see how you can do without assumptions. Every line of code assumes certain state of the program that it operates on.

[agavin]

You can't have no assumptions. But half the time I help someone debug something they begin with, "it can't be in this part of the code" which is often unfounded. Now if you PROVE that it isn't, that's a different matter.