The Super Productive Programmer

One of my goals is to be a super productive programmer. Lately I have been logging notes about bugs when I get stuck.  Here are a few entries:

“I made a change. Then I made a second change, and found a bug. I falsely assumed the bug was from the second change.”

“Today I had a bug that a confirm box wasn’t showing.  The debugger confirmed it was calling the show method... but was getting cleared because it was running other code, that I didn’t expect to run.”

It goes on like this, one faulty assumption after the next.  So I started thinking... these assumptions are bad.  I am getting stuck by making these faulty assumptions.  However, as became aware of it, I noticed I make these type of deductions regularly and 99% of the time they are correct.  Often times solving “trivial” mistakes because I quickly deduce what the problem is.  

As a simple example, if I just made a change and there is an error, the changed code is more likely the problem, than say, a bug in the operating system.  So about 1% of the time these deductions and assumptions fail.  Usually there is an iterative process of inspection, perhaps with the debugger or logging, and I adjust my deductions. Sometimes I google for error messages.  Sometimes I use “confessional” debugging, when I explain the problem to others and the error becomes obvious when I articulate the problem.  Occasionally I post on stack overflow.  Typically these problems don’t last very long.  I would guess it’s a long tail graph.  Most errors are solved in less than a minute. Once every day or two a problem that stretches 15, 30, 45 minutes... once every month or two a problem that takes an hour or more, once every year or two a problems that stretch into days.

Is this other programmer’s experience?  
Is this getting stuck issue a good way to think about and judge programmer productivity?
What else can be done to reduce this wasted time and become a super productive programmer?

No comments: