http://www.informit.com/articles/article.aspx?p=1941206
Rob Pike, now a Distinguished Engineer at Google, worked at Bell Labs as a member of the Unix Team and co-created Plan 9 and Inferno. He was central to the creation of the Go and Limbo programming languages. Rob shares an experience at Bell Labs that changed his approach to debugging.
Be sure to check InformIT for a new article every Wednesday. See more advice from other programmers here.
Name:
Rob Pike
Job Experience:
I worked at Bell Labs for many years. I was in the Computing Sciences Research Center, the (surprisingly small) lab that created Unix, although I was not there until after the Seventh Edition was released. Since 2002 I’ve been at Google, working on various pieces of infrastructure and infrastructure infrastructure.
Most Notable Achievement:
I’m probably best known for my books with Brian Kernighan, The Unix Programming Environment (still in print almost 30 years on!) and The Practice of Programming. The most widespread thing I’ve done was develop UTF-8 with Ken Thompson. But I’ve also done significant work in computer graphics, operating systems, software tools, and most recently helped develop the Go programming language.
Most Frequently Used Programming Language:
For too long to admit to here, C was my language of choice, but I have used many languages through my career. Nowadays almost everything I write is in Go; it is the most productive language I have ever used and has displaced C completely from my toolbox.
Advice:
A year or two after I’d joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all. When something went wrong, I’d reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we’d just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, “I know what’s wrong.” He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he’d intuit where the model was wrong or where our code must not be satisfying the model.
Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.
I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.
Replies to the post:
DaveyH • 18 hours ago
So often I’ve sat staring at a monitor without being able to figure out a problem, then got it on the drive home. Sometimes you’ve just got to step back from the code.
Alan8 • 11 hours ago
That happens to me too! Many times!
fayyaz lodhi • a day ago
Though might be slightly obvious and a million dollar advice particularly for novices since debugging is not something which is taught formally, i would still like to argue that it does not apply to all scenarios. For instance, how about when you joined a new company with a large code base of a product, you get a high level idea of how things flow and what do they do. But you actually don’t have the mental model there. Not at least on a deep level enough to fix bugs. You develop that model by going through code, line by line or function by function. Whether you just read through the code, or you actually add prints / see values in debugger is a matter of choice. But the point here is, you are developing that mental model as you go along through the code. In industry, more often than otherwise, a person is mostly debugging / fixing / maintaining code which was NOT initially written by himself. The above advice is applicable only when you are the designer of the program itself and there was a disconnect between your design and working implementation. Most of the features we add in legacy code / fix bugs arise due to a list of other reasons. Such as change of requirements, initially developed as throw away code, feature addition and the list goes on….Just my two cents. But certainly this habit is the right way to learn debugging.
Doug_B • an hour ago
“how about when you joined a new company with a large code base of a product, you get a high level idea of how things flow and what do they do. But you actually don’t have the mental model there.”
Read my futher post. You don’t. You are just a cog. They don’t care about you. Thanks to globalization ‘they’ think you are as replaceable as a grunt from India.
Programming is now a 3rd world, blue collar job.
Doug_B • 6 hours ago
Comp Sci has been good to me. I’ve been programming for over 40 years. In the early 80′s I was able to start a software company, and sell a considerable amount of software nationwide.
Unfortunately, globalization, financialization, and nano-management have turned a once refreshing occupation into a Dibert type, cube farm, heads down enviornment.
With continual change the value of an experienced person lessens. Those doing the hiring have no idea what ‘experience’ can bring to the table. They are too deaf to hear about it, too blind to read it from a resume.
My best programming advice for young people is to persue some sort of trade which can’t be outsourced or overly managed.
Tim • 14 hours ago
I agree mostly with this advice, but I have worked with programmers who sit and think to long without understanding the state of the code before the bug happens. You need to debug to understand the state of all of the key variables to help understand why your code is not following the design. Once this is known, you can go through the mental work of finding the solution. My first goal when debugging is to find out the first place the code started going wrong, and to find that you need to run the debugger, and trace code.
r_mosaic • a few seconds ago
Yes, Ken Thompson was programming then, so he *knew* the logic underneath and that’s why he needn’t debug too much. For code that was not written by the programmer who maintains it, it is necessary to debug into it.