「程式設計師最重要的特質是，當你對電腦下達一個指令時，腦海裡能夠看見電腦如何完成這個指令。」作業系統核心 Hurd 的開發者 Marcus Brinkmann 在一次訪談中提到。這句話我非常認同，每次寫程式有這種感覺時，這支程式通常不會有任何問題，且很容易修改。相反的，如果下指令時無法預見執行流程，那這支程式一般說來會有錯誤，且難以找出錯誤所在，也不好修正問題。

　　文章中另外提到了「多數程式師在預測程式效能方面的能力非常糟糕」、「你為機器撰寫程式，但也是為人而撰寫程式。」這些意見都是 Marcus Brinkmann 多年來累積的經驗，再加上參與 Hurd 開發的心得所歸納的結論，值得有心成為「專業」程式師的人細細品味。

　　下面節錄訪談中講到這方面的段落。訪談全文在此。

Advice for new programmers

Nikolaos S. Karastathis: I am sure that many of the people who read this interview are considering becoming programmers. Could you please provide some advice for aspiring software developers? Do you think it is better to learn many programming languages at once, or just stick with one language and learn it extensively? What are the most important qualities that programmers should possess?

Marcus Brinkmann: You should have a look at as many different languages as you can get hold on (and as you have time). Also for all other tools. You can not get proficient in all of them, or even any substantial number, but you should know your way around them and expose yourself to as many ideas as possible. However, note that a language is merely a tool of expressing your ideas programmatically. As every other tool, you need to learn when and how to apply it to a given problem. And as with every other tool, it can help you or be in your way.

To become an expert programmer, you need to know what tools are available, but you also need to pick some tools that suit your needs particularly well and become good at them. So, for some languages you will want to learn them really, really well. Unfortunately, as so often in life when you leave the plane of abstraction and get down to the details of the implementation of an idea, tools like compilers cease to be black boxes. When you become a better programmer, you will be exposed to implementation details about your tools, including the hardware of your computer, that you never wanted to know. For example, you will start to worry about things like in which pattern your program will access memory, and how that interacts with the CPU’s memory cache. You won’t find this knowledge in most books. The best way of learning this is by doing and experiencing it.

Here is an example from the real world. Many years ago I bought a PDA with GNU/Linux on it, the Agenda VR3. The device had many problems and was not very successful. One particular problem was that the calendar function was very slow. Somebody profiled the code and found out why. It happens that the calendar used the bits in an integer field as flags, that’s a standard idiom. But instead using the shift operation “1 << n” to access the individual bits, the programmer used the math function “pow (2, x)", and on that architecture, all floating point arithmetic was just painfully slow. We don’t know what the author of that code thought. Clearly, the code was “correct” in that it achieved the goal. Maybe the programmer thought of pow() as a black box. Maybe he knew that he was using floating point arithmetic, but thought that the compiler could optimize it to a shift operation. In this case, the author didn’t know the language and his compiler good enough (if I recall correctly, the type casting rules prevented such an optimization).

This illustrates that the most important quality of a programmer is to visualize in your mind what the computer is doing when you give it certain instructions. This is important both to be confident that your code is correct, and at a greater level of detail to give a good estimation of your code’s performance when it is actually compiled into a program and run. Most programmers are notoriously bad at predicting the efficiency of their code. The better you know your tools, and the more experience you got, the better will be your ability to say with confidence what the computer will actually do with your code, and you will be able to fine tune your program to make the system behave more the way you want it. Of course, on a global scale, you will need profilers and debuggers to help you with this.

I want to add one more thing: You program for a machine, but you also program for human beings. Never forget that. Even the best performing code can be useless if no human can figure out what it is doing and why it is doing it the way it does. So, another important quality is that you can write documentation and good comments into your source code, and that you can structure your source code in a way that it is accessible to your fellow developers. Most of the important programming in the world today is a team effort. Read high quality source code to pick up common idioms and follow coding style guidelines.