"The Best Programming Advice I Ever Got" with Rob Pike
Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTICLE.
* See informit.com/terms
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.