-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path2012-08-15_rob-pike_the-best-programming-advice-i-ever-got.html
107 lines (107 loc) · 4.62 KB
/
2012-08-15_rob-pike_the-best-programming-advice-i-ever-got.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 2.0.20">
<title>The Best Programming Advice I Ever Got</title>
<link rel="stylesheet" href="../css/paq-dark.css">
</head>
<body class="article">
<div id="header">
<h1>The Best Programming Advice I Ever Got</h1>
</div>
<div id="content">
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>(Aug 15, 2012)</p>
</div>
<div class="paragraph">
<p>Original: <a href="https://www.informit.com/articles/article.aspx?p=1941206" class="bare">https://www.informit.com/articles/article.aspx?p=1941206</a>.</p>
</div>
<div class="paragraph">
<p>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.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_name">Name</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Rob Pike.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_job_experience">Job Experience</h2>
<div class="sectionbody">
<div class="paragraph">
<p>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.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_most_notable_achievement">Most Notable Achievement</h2>
<div class="sectionbody">
<div class="paragraph">
<p>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.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_most_frequently_used_programming_language">Most Frequently Used Programming Language</h2>
<div class="sectionbody">
<div class="paragraph">
<p>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.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_advice">Advice</h2>
<div class="sectionbody">
<div class="paragraph">
<p>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 <strong>how</strong> that problem could happen, he’d intuit where the model was
wrong or where our code must not be satisfying the model.</p>
</div>
<div class="paragraph">
<p>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.</p>
</div>
<div class="paragraph">
<p>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.</p>
</div>
</div>
</div>
</div>
<div id="footer">
<div id="footer-text">
Last updated 2024-07-10 23:33:47 +0300
</div>
</div>
</body>
</html>