Michael Riddle's Thoughts

It is widely known that there can be a ten or even hundred to one difference in the productive output of great programmers .vs. average ones. I’ve been trying to think of what some of the reasons might be, and how we can apply them to our own work.

The first thing I’ve come up with is that they are not intellectually lazy. They are willing to go the extra mile. I’m not talking about working hard in the sense of hours, or taking on difficult tasks. That goes with our territory. I’m talking about how we do our work.

This first became clear to me when I was thinking about debugging. Many programmer’s I worked with, and many I’ve hired, fix bugs the way Tylenol helps a cold – they relieve the symptom. When the location in the code responsible for causing visible bad effect is found, they insert a patch or work-around at that point, and the symptom disappears.

What very good programmers do is to use that as a wedge to pry loose a better understanding of how the program is actually working. They might invest an additional several hours, until the root conceptual cause, often the result of a structure or design decision, is understood. Then they fix the problem with that. The program moves towards better clarity: It becomes a better match for its design’s conceptual integrity.

Doesn’t that approach take more time? Certainly. In the short-term.

When viewed in hindsight, after a project has been successfully completed, it can often save a great deal of time. Debugging is expensive in both human time and psychological wear and tear – It is much more enjoyable writing code to implement new capability. By fixing the root cause of the problem, we have not plugged one symptomatic hole in the dam, but strengthened it entirely. The real bug would have surfaced in several other places, each requiring a symptomatic cure. The result when complete would be a patchy, hard to maintain, code base.

My personal point of pride is to attempt to fix bugs by removing lines of code. I try to find the cleanest way of expressing a function. The best bug fixes are fixes made during design time. The entire point of evolving code is that we realize that design, implementation, and testing are often best served by being overlapping concurrent tasks. (Lately this has been popularized as part of Agile Programming).

Fixing bugs during the design is especially effective because what we do as programmers is much less about coding that it is about taking a poorly understood process and reducing it to a clear vision. That is why it is so often the case that when we have finished writing a program, we understand it well enough to see how it could have been better accomplished (the “2.0 syndrome” aka “rewrite fever”).

Some of my favorite programming articles are the game postmortem articles in Game Developer magazine. The book, Postmortems from Game Developer, contains a nice set of these articles. Even if you have no interest in graphics or computer games, Game Developer is a magazine I recommend. These people are the ones pushing the frontier of our trade, both with hardware and in parallel programming and complex project organization.

 
Other books on the subject of debugging I can recommend:

The Debugger’s Handbook by J. F. DiMarzio, which talks about and gives examples of design-time debugging along with the usual material.

 
 
 
 
 
Why Programs Fail – A Guide to Systematic Debugging, by Andreas Zeller. A deep dive into the sources of failure, and approaches to detecting each type of cause.

 
 
 
 
 
Debugging by Thinking – A Multidisciplinary Approach, by Robert Charles Metzger. This book delves deep into approaches to take to debugging, and different ways of thinking about problems. Not the easiest read, but probably more information per page than any other book on debugging.

 
 

This entry (Permalink) was posted on Thursday, October 1st, 2009 at 7:15 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.