1. ⼀一 番 の
プ ロ グ ラ ミ ン グ ア ド バ イ ス
@ S M A G C H

2. １年くらい前、Rob Pikeさん
の書いたWeb上の記事を
読みました。
H T T P : / / W W W. I N F O R M I T. C O M / A RT I C L E S / A RT I C L E . A S P X ? P = 1 9 4 1 2 0 6

3. R O B P I K E っ て 誰
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.

4. 要 約 す る と 、
ベ ル 研 究 所 で ⻑⾧長 く 働 い て い て 、
そ の 後 は グ ー グ ル で 働 い て い る 。
Rob さん（中央）Ken Thompsonさん（右）

5. R O B P I K E っ て 誰
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.

6. 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.

7. P A I R P R O G R A M M I N G
略して、ペアプロ

8. ペ ア プ ロ の 様 ⼦子

9. 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.

10. 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.