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:
Post a Comment