Want to write some code? Get away from your computer!
想编写计算机程序吗？离开你的计算机！
I’ve recently realised something. The best place to write code isn’t in front of your computer, with your compiler, IDE and tools. The best place to write code is far, far away from any of these tools – somewhere where you can think properly. For a language with which you are fairly familiar, the mechanics of translating the program in your mind to a program that the compiler can compile (or the interpreter can interpret) is fairly easy – it’s coming up with that program in your mind which is hard.
最近我成功地完成了一件事。编写计算机程序最好的地方，不是用IDE或其它的编译工具，坐在计算机前，而是远离那些编译工具，一个你可以自由思考的地方。对于你非常熟悉的程序语言来说，把你的想法编译成另外一种编译器能翻译的程序（或者说解释程序能够解释的），是再简单不过的事情-尽管你想出的程序非常难。
The other day I was on a train journey. I had my laptop, but no internet. Unfortunately I was using a commercial programming language (IDL, as it happens) for which I need to use my university’s site license. As I didn’t have access to the internet, I couldn’t get hold of the site license, so couldn’t run the compiler and IDE. Say what you like about commercial programming languages which require expensive licenses, but it stopped me from actually writing code in my editor with the compiler. And…guess what…it actually made me think!
有一天，我坐火车在旅途中，我有一台便携式电脑，但无因特网接入。不幸的是，我必须登陆我所在大学网站并得到许可，才能使用一种商用程序语言（IDE）。但是，我上不了因特网，所以我不能找到大学网站，因而也不能运行编译程序和IDE。商用程序语言需要花不少钱才能得到许可，请指出你喜欢这种语言的地方，但是，得不到许可我就不能用编译器真正地编写程序语言，而且、、、，你猜怎么着，这逼着我开始思考！
I guess this post is somewhat along the lines of Does Visual Studio rot the mind? and the following quote:
我想解决问题的标志在《可视化编程语言让思想腐朽吗？》这篇文章和下面的语录中：
One of the best lessons I learnt from my first boss was: “when your code doesn’t behave as expected, don’t use the debugger, think.”
我从我的第一位老板中学到的最好一课是：“当你的程序没有达到你期望的效果时，不要用编译器，思考！”
That is what being away from your compiler forces you to do. It’s very easy to slip into the mindset of:
也就是说，远离强迫你编写程序的汇编语言，这样很容易进入下面的思维模式：
Write a bit of (fairly bad) code Compile and run Test with a poorly chosen test case Find it doesn’t work Make small change to the code on the off-chance that it might solve the problem Repeat…
1、写一点程序（很糟糕）；
2、编译并运行；
3、用随便挑选的事例来进行测试；
4、结果不运行；
5、对程序做一些小的改动，尽管解决问题的机会极小；
6、重复、、、
Of course this leads to code in the end that is ill-understood by the programmer, probably fairly buggy and not well tested.
当然，这会最终导致一个由编译者不大明白的程序，很可能程序错误很多，且不能很好地通过测试。
Being away from the computer forces you to run through all of the thoughts in your head – which tends to take longer than getting a computer to compile and run your code (for small code bases at least…). So you don’t tend to make tiny changes and re-run things, you tend to actually think about what the code is doing. Until I did this on the train the other day, I hadn’t actually run a piece of code on paper (that is, written down columns for each of the variables and worked out what each value will be at each stage in the program) since my Computing A-Level exam!
远离计算机，它会强迫你运行你大脑中的想法-这比让你的电脑编译并运行程序要花更长的时间（至少对小的程序来说是这样的、、、）。所以你工作的方向不是做小的改动并重新运行程序，而是真正地思考程序在干什么。 那一天，在火车上，当我在纸上运行一段程序时（即一行一行地写下每个变量，并计算出其在程序中每个阶段的值），我才明白这一点，因为我的计算机运行得了最好成绩。
In the case of the code I was writing the other day, I managed to produce some high quality, fast, bug-free code by writing it in long-hand on a piece of paper, thinking about it, gradually typing up bits of it, thinking some more, and then after a long time trying it in the compiler. The code (which was some region-growing image segmentation code which involved lots of recursion) was eventually copied from my piece of paper to my IDE, compiled (with only one syntax error – impressive I think) and ran correctly first time (and completed all of the tests that I had also devised on paper).
通过那一天在火车上编写程序这件事，我想方设法编写出了一些高质量的、运行速度很快的、没有程序缺陷的程序，花几个小时在纸上编写，反复思考，一步一步地在打字机上打出来，留出更多的时间来思考，经过很长一段时间，最后用汇编语言在计算机上试运行。这种纸上写的程序（有点象生长区概念的分段程序，每段程序都包含很多递归循环），最后由纸拷贝到我的IDE，编译（只有一个句法错误，给我影响太深刻了！）并首次运行正确（纸上设计的程序全部通过测试）。
Job well done, I think, and a useful piece of advice, I hope.
我想纸上编写程序很不错！我也希望这是一个不错的建议。
