Rob Pike: The best programming advice I got

Rob Pike: The best programming advice I got

Rob Pike, one of the most famous software engineers of Google, once a member of the Bell Laboratory Unix development team, the principal leader of plan9 operating system development, and the principal leader of Inferno operating system development. He is the core character of the Go language and limbo language. The following is an experience he shared with everyone who has worked in Bell Labs. This experience has changed his understanding of bug debugging.

Major job experience:

I have been working in Bell Labs for many years. I am at the computer science research center, and you will be surprised that this is a very small lab, but here it creates Unix. When I came here to work, Unix has released the seventh edition. I have been working on Google since 2002, mainly developing some system infrastructure.

Major achievements:

I should be most familiar with two books, the Unix programming environment and the practice of programming, jointly written by me and Brian kernighan, a key member of the Unix development team) (30 years later, it is still being printed and published today !), One of the most influential things should be that I and Ken Thompson have jointly developed the UTF-8 encoding format. In other aspects, such as computer graphics, operating systems, and software development tools, a lot of work has also been done. Recently, Google is developing the go programming language.

The most commonly used programming languages:

C language is my programming choice for a long time, but I have used many languages in my programming career. At present, I have developed D using the go language, which is the most efficient programming language I have ever seen. It has completely replaced the C language in my toolbox.

Advice:

After joining Bell Labs for more than a year, I began to develop Pair Programming with Ken Thompson on a real-time compiler for a very small graphic exchange language designed by Gerard Holzmann. I typed fast, so I sat in front of the computer and Ken stood behind me to watch my programming. We developed very quickly, but we often encounter problems, and we can see that errors have occurred-after all, this is a graphical programming language. When an error occurs in a program, I can easily jump into the problem, check the error tracing information, add debugging and print statements, start the debugger, and so on. However, the Ken is just standing there and thinking, I will not view the problematic code we have written. After a while, I found a rule. Ken often finds out where the problem is first, and suddenly shouted, "I know where the problem is ." Every time he makes a correct decision. I realized that Ken had already built a code model in his mind. When something went wrong, it was a problem with the model in his mind. When thinking about why these errors occur, he can intuitively find out what is wrong in the model or find that the written code is different from the mode.

Ken taught me an extremely important habit: Think before correction. If you get stuck in the problem, you may only solve the code that is currently experiencing the problem. But if you think about this error first, how did you introduce this bug? You usually discover and correct a higher level of problems, and then improve the system design to prevent more bugs.

I realized that this programming thinking mode is very important. Some people are obsessed with one line and use various tools to debug everything. But now I believe that thinking-without looking at code-is the best way to debug, because it allows you to develop better software.

Original article: "The best programming advice I ever got" with Rob Pike
Translation: It comments from external journals

Rob Pike: The best programming advice I got