百年前，人们在亚马逊河两岸砍伐树木时，发现一种十分奇怪的现象，在电锯的轰鸣声中，所有的动物 都逃离了，惟有一种叫做树虎的动物没有走，而据记载，树虎是非常怕人的。工人们深感奇怪，不明白这些树虎为什么不走。他们找来动物学家桑普，桑普说，一定 有一只树虎被树胶沾在了树上了，所以其他的树虎才不走。大家仔细搜寻，果然发现树干上有一只树虎。原来，一千只树虎里，总会有一只被树胶粘住，从此再不能 动弹。但这只不能动的树虎仍然能活很多年，因为周围的树虎都会来轮番喂它。伐木工人听了被深深感动，他们将整棵树移到森林的深处，于是所有的树虎也都跟着 迁移了。

但后来，树虎还是在世上灭绝了，因为它的毛皮非常昂贵。有人先将一只树虎用胶粘在树上，其他树虎便相继跟来，寻食喂养这只不能动的树虎。善良使它们纷纷落入猎人的圈套，被贪婪者一网打尽。

一只北极鼠，被猎人的夹子夹住了后腿，夹子又被缠在了树上，动弹不得。但它没死，直到一年后，它的后腿脱落，一瘸一拐地逃生了。而这一年中，总会有几只母鼠来喂养它。于是，人类又利用北极鼠的善良，将北极鼠捕获。慢慢的，北极鼠同样也被灭绝了。

南 非沙漠里有一种沙龙兔，它们能在沙漠里成活不被干死，完全是因为团结。沙漠每两年才会下一次像样的雨水，这对于任何生命都极为珍贵。这时，成 年的沙龙兔都会跑上几十里，不吃不喝，直到找到水源，又以最快的速度跑回去告诉大家。大队大队的沙龙兔，会在这只首领的带领下，跑上几十里去喝水。而那只 成年沙龙兔，一般都会在到达目的地后，因劳累而死去。又是人类，利用沙龙兔的这一特点，故意设制假水源，当大批沙龙兔到达地点后，却发现那里根本没有水而 渴死在沙地上。于是，捕猎者便不费吹灰之力把它们装入口袋。

动物的善良与奉献精神，让人类感动。而人 类的残忍，却让人类自己胆寒。据世界动物组织的调查表明，许多动物，如此善良、如此献身的精神，正是它 们繁衍的需要。这种善良与献身，是它们代代相传、永远生存下去的基础。世上没有任何天敌能够战胜善良，只有人类在做着灭绝善良的事，照这样下去，人类自身 的命运将如何？

今天无意中在网上看到一个C的程序，简单，却深奥。据说是个大师写的，实在是令人感到恐怖。

这样的程序竟然也能运行？ 没想到吧 ！ 什么事情都有可能发生，而且这样的事情还多着呢？如果你只是被它的结构迷惑，那没关系，不过…… 程序的运行结果可能会让你更加吃惊了。这不得不让我想起“The Tao of Programming”中的一句话“编程大师的程序再凌乱，也用不着测试，因为它是正确的”。

程序的源代码如下：

我试着在GCC下编译以下，居然通过了。而且成功地输出的结果：

我今天痛下决心暂时放弃使用了近2个月的Linux系统。不是因为我用不惯，也不是无法工作在Linux下，更不是因为我不喜欢；只是因为，过多的应用系 统，尤其是我很喜欢的很多金融系统，比如工行、招行、福汇、MT等，都只有建立在Windows和Mac系统的软件（尤其是国内产品，更是酷爱 Windows）。

我曾经不止1次和招行软件中心的人提到Open Source，其实金融产品被Open Source后，必然涉及安全问题了。而且对于Dev的要求过高。

另外看到，福汇、MT这种东西居然也只支持Windows。唉，没办法。而且目前和比别人谈论外汇的时候，最好的方式还是QQ，因为有即时贴图（Linux版就没有），方便讨论。

所 以，鉴于此，我决定暂时舍弃Linux平台，回归Windows。但这并不意味着我将放弃Linux。在有朝一日，我有超过1台电脑的时候（LapTop +DeskTop或者DeskTop+DeskTop），我会为了我自己装一个Linux；为了金融，装个Windows的。

不仅如此，VI、Emacs等Open Source的工具，仍将成为我工作的不可或缺的部分，即便我工作在Windows平台。

I realized that, paradoxically enough, good programmers need to be both lazy and dumb.Lazy, because only lazy programmers will want to write the kind of tools that might replace them in the end. Lazy, because only a lazy programmer will avoid writing monotonous, repetitive code – thus avoiding redundancy, the enemy of software maintenance and flexible refactoring. Mostly, the tools and processes that come out of this endeavor fired by laziness will speed up the production.

This makes a lazy programmer a good programmer. Of course, this is only half the truth; for a lazy programmer to be a good programmer, he (or she) also must be incredibly unlazy when it comes to learning how to stay lazy – that is, which software tools make his work easier, which approaches avoid redundancy, and how he can make his work be maintained and refactored easily. (By the way, the word “unlazy” has 14,400 hits in Google; I’m sure this makes it legal.)

Second (and I will elaborate a bit more on this because I find the concept to be less known than the first) a good programmer must be dumb. Why? Because if he’s smart, and he knows he is smart, he will:

a) stop learning
b) stop being critical towards his own work

Point a) will make it hard for him to try to find new techniques to allow him to work faster. Point b) will give him a hard time debugging his own work, and refactoring it. In the endless battle between a programmer and the compiler, it’s best for the programmer to give up early and admit that it’s always him and never the compiler who’s at fault (unless it’s about character encoding issues, which is the part even the compiler gets wrong).

But there’s a more crucial point why a good programmer must be dumb. That’s because for him to find the best solutions to problems, he must keep a fresh mindset and manage to think out of the box (or rather, know its actual shape). In a way, this leads to the mindset of a child; incredibly creative because he never heard “no” for an answer.
The direct opposite approach would not be very constructive; to be knowledgeable about the parameters at hand, and accept them. Because who knows how many limits you think are there are for real? The less you know, the more radical will your approaches be; the better the tools you develop, and the better the product you develop with them.

I know from my work that a good programmer, when confronted with a problem from management, will adopt this mindset of being dumb; he will start asking the most simple, child-like questions. Because he doesn’t accept the parameters suggested to him that someone thinks make up the problem. Here’s a typical conversation from the lost land of web development:

“Since yesterday, our client can’t see the logo on the web site.”
“Did he restart his browser?”
“Yes.”
“Did he restart his computer?”
“Yes.”
“Did he empty his cache?”
“Yes.”
“Does he run Internet Explorer 6?”
“Yes.”
“Is he sure he can’t see it?”
“Yes.”
“Did he look at the web site on the screen?”
“What?”
“Well, he might have printed it out.”
“No, he was looking on it on the screen.”
“Did he also not see other images besides the logo?”
“What? Well, I will ask him.”

For the sake of argument (and this was entirely hypothetical) let’s say the client indeed turned off images in his browser. Or his son did. Whatever the case, this answer could not have been found if you would work in “smart” mode*. None of the questions asked by the programmer required any programming skills. No; simply because the problem is so stupid, only stupidity can tackle it.

*Some years ago, I had a long telephone discussion about the whole web site being messed up since my last update… it turned out the guy disabled stylesheets in his browser. Back then, I would have suspected everything but such a simple solution and was listening to half an hour of complaints about quality standards etc. In the end, the assumption that my update was at fault was just that… an assumption. You better listen to facts only if you start debugging, and never to what people think might be the reason.

In similar fashion, when one of my co-programmers asks me: “Why isn’t this working?” most of the time it’s because they’re working on the wrong file (e.g., they linked to library 1 but they’ve altered library 2, and their revision isn’t showing, or they simply didn’t link the library at all). When you ask a colleague for help, particularly in programming, you want him to know less about your project… so he will ask the stupid questions you sub-consciously avoided asking yourself because you thought you knew the answer, when in fact you didn’t.

There’s another side to it. The too-stupid person will just run off and, without a second thought, do something wrong. The too-smart person will sit down and plan something right, without taking any action. A pragmatic programmer is sort of in-between; he knows making the wrong decision 1 out of 10 times doesn’t hurt the goal as bad as making only right decisions 5 out of 10 times, and making no decision at all the other 5 times.

It’s like the story of the centipede. The centipede was very good at walking with its hundred legs. It never spent a thought on just how it could walk. Until one day, when a big black bug asked the centipede “How can you manage to walk with all those feet? Don’t you find it hard to coordinate their rhythm?” The black bug already left, when the centipede was still sitting down, pondering how it could walk, wondering, and (for the first time in his life) even worrying a little bit. From that day on, the centipede couldn’t walk anymore.
So you better not think too much if you want to achieve something. And of course this is only half the truth, too…

by Philipp Lenssen