我曾经说过，程序员不是一般的人， 是具有某种超能里的人。但问题是，程序员往往意识不到自己的这种特异功能，在他们的眼里，会认为自己很普通，跟常人一样，所以，程序员能做到的事情，其他 人——比如他们的客户/软件用户——也应该很容易做到。但事实上，由于大部分人——绝大部分人(包括软件开发公司的客户/购买软件的用户)——都是电脑小 白(对电脑知识/计算机知识/软件知识知之甚少的人)。一个对于程序员来说很显而易见的软件操作，换成让用户来操作，就会出现各种各样奇怪的事情。这让程 序员非常痛苦。
记得有一次，一个客户打电话给我，说他电脑桌面上的大e找不到了，我没听懂，什么大e找不到了？客户解释说：就是那个长的像大个儿的英文字母e的图标找不到了。我倒。终于明白了他指的是桌面上的IE浏览器的图标不见了。
还有一次，有个客户提出一个需求，要求在页面上增加一个搜索功能，我问它，系统里有搜索功能，为什么还要在这个地方新增一个搜索功能，他说他要的不 是那个搜索，他要的是在这个页面上搜在某个关键词。经过进一步的沟通，我明白了，他要的是浏览器上的快捷键CTRL+F的功能。
因为用户的这些特征，导致了程序员认为完美的程序，到了客户的手里，却变成极其难用的软件，投诉电话如乡下骂街的泼妇似的响个不停。而事后分析发 现，根本原因都是应为程序员高估了用户对软件的掌控能力，低估了自己对软件的创造能力，于是导致了他们看这些客户使用他们开发的软件时，都是那样一种可笑 的行为，如下图：
如果是脾气暴躁的程序员，遇到这种情况，难免会对着客户发一顿牢骚，而且，程序员的脾气一般都不是很好，所以，通常跟客户沟通时，项目经理一般都是跟着一起，以免事态激化。
用户虽然给程序员带来很多麻烦，但其实程序员的所有荣耀感都来自客户，因为只有客户用得满意，程序员才会有成就感。比如像下面这几个客户在使用一个新款软件时显露出来的表情，足够让一个处在北京重度雾霾的下午的程序员也能露出笑容：
程序员虽然脾气不好，但他们都是为工作着想，不带任何个人恩怨。当开发软件有紧急任务时，他们都是任劳任怨的加班加点，当在已经发布的软件中出现了 重大bug时，他们都会深深在自责，会连夜赶制出紧急修复bug，如果不能在第一时间让用户满意，他们会茶不思、饭不想、觉不睡。即使在实在没有短期内完 整的补救措施的情况下，他们也会想出一些歪招，但也是行之有效的方案，让用户暂时度过难关。比如，下面就是一个紧急修复补丁：
用户应该体谅程序员。程序员的生活实际处在一种十分矛盾的状态中。编程不像其它行业，比如泥瓦匠砌砖，砌一层砖，墙就会高一次。但编程不一样，有时 候一个程序员写了一天的代码，急得满头大汗，但开发进度未必就有所进展，有时候甚至还会倒退。软件编程是一个亦虚亦实的世界，有时候你搞不清一段代码为什 么好用，有时候也会诧异由那样的代码构成的软件也能跑起来，正如下面这张图片中所示：
最后，说一下跟程序员打交道的一些注意事项。程序员因为整天和编程逻辑打交道，所以对因果关系特别敏感。如果你的话语的因果关系不是很明确，这会让他们感到疑惑，如果你的话语的因果关系不完整，这会让他们办错事。如果你的话中有if，最好后面用then做结束，或者用else给出选择，主语要明晰。如果不明晰，就会出现下图中出现的事故：
如果你是一个程序员，你会理解我说的话。
来源:外刊评论
IT 评论
这是我最常说的一句话，说给那些打算放弃朝九晚五的上班生活、去创造自己的软件挣钱的程序员。
通常这句话跟在这样的问句后面“你怎么知道这地球上会有人愿意花钱买你的软件？”
当然，这是因为有一个非常幸运的事实：你不是一般的人。
你也知道，大部分的人都不会编程。大部分的人都做不出一个todo应用。大部分的人都不知道API能干嘛。更要命的是，大部分的程序员都解决不掉一个Fizz Buzz这样的简单题目。
你不是一般的人
这是个好消息。你拥有的是一种含金量很高的技能，可以为你和他人创造巨大的价值。
所以，回答最初的问题：“你怎么知道这地球上会有人愿意花钱买你的软件？”
我想这答案不会让你吃惊：因为你非同寻常。大部分的程序员在放弃朝九晚五的工作、去开发自己挣钱的软件时，他们往往注意的是那些自己会花钱买的软件，但这样的软件通常很少，于是他们得出结论：没有人会在自己这样的软件上花钱。
但是，如果你在网上搜索一下，你会找到不少软件，它们并不复杂，但却为这些软件的开发者挣取了一摞一摞的印着富兰克林头像的票子。举几个例子：
BufferApp: 约耳，Buffer公司的创始人，谈论Buffer应用是如何挣钱的.
BidSketch: 鲁宾，Bidsketch软件的创始人，谈论BidSketch软件是如何挣钱的.
Freckle: 埃米，Freckle软件的创始人，谈论为什么你应该收取更高的费用.
如果你归纳一下Zapier网站的核心业务，你会发现，它本质上就是一些很小的脚本，把两个应用连接到一起。当我向程序员们说Zapier所做的事情就像是把GitHub上的评论发送到HipChat并自动进行提醒，得到的回复无一例外的是“我可不会花钱买这样的东西！我一个小时就能做出这样的东西。”但是，当我们看看GitHub to HipChat的统计数据后，你会知道，它是GitHub上最受欢迎的集成工具。
你明白了吧，你不是一般的人。
做一个有信仰的人
我们当然知道，让人们为一个产品付钱很难。但是，一旦当人们认识到它的价值后，他们会义无反顾的去买它。
在和一些程序员和软件老板接触后，我变成了一个有信仰的人——当他们知道了一种简单的软件能帮他们节省时间或挣钱后，他们会像饥饿的猎豹看到瞪羚一样立即支付每月50美元、100美元，甚至1000美元的费用。
做一个偏执狂
一旦你决定出售一个软件或软件服务，你很可能会招来非议。非议经常说来自那些你很尊敬的程序员。请忍住不要接受他们的忠告。固执的把你的软件放到市场上测试一下。把你开发的东西展示给你的核心听众。你会发现惊奇。
毕竟，你和你的程序员朋友们都不是一般的人。
来源:外刊评论
只听说过黑道上有黑话，但其实每个行业都有自己独特的语言，只有这个行业里的人才能够心领神会。软件开发行业里有大量的只有程序员才能听懂的话，只有程序员才能做出的事，只有程序员才能理解的心情。下面这11个，相信你会明白——如果你是个程序员。
1、编程太久，你开始忘了如何使用人类的语言10100111001010101010101001001001…
2、使用谷歌搜索时最常用的语句是“为什么xxx出错”
3、为了能写好程序，再大的地方也不够你摆放各种工具设备
4、代码运行不正确，最终发现是忘了写第二个“=”号
5、开发出了令人自豪的程序，但没法展示给别人看，因为程序只在封闭的网络里运行。
6、你用数月时间开发了一个移动应用，但却被应用商店拒绝上架。
7、对调试程序最通俗的描述
8、当这种事情发生时，你的整个世界都崩溃了
9、当遇到一个不爽的对话时，你希望现实生活中能有一个fork bomb(fork炸弹)工具来使对方的说话系统瘫痪。
10、当有程序出错时，程序员都这样说话
11、为什么程序员都喜欢使用Linux？
马克·吐温曾经说过，所谓经典小说，就是指很多人希望读过，但很少人真正花时间去读的小说。这种说法同样适用于“经典”的计算机书籍。
在Stack Overflow(以及其它很多软件论坛)上，诸如”程序员最应该读的计算机书籍有哪些?“这样的问题会周期性的出现。这样的问题不断的被提出、被回答，只是形式不同罢了。相同的几本书总是会出现在清单的前几名内，所以，如果想知道人们谈论的都是些什么，你有必要去读一读这些书的。
大多数程序员真正读过的计算机书籍
1. 代码大全(Code Complete)——两届Software Jolt Award震撼大奖得主！
2. 程序员修炼之道（The Pragmatic Programmer）
3. C程序设计语言( C Programming Language)(第2版)
4. 重构:改善既有代码的设计（Refactoring: Improving the Design of Existing Code）
5. 人月神话（The Mythical Man-Month）
6. 编码——隐匿在计算机软硬件背后的语言（Code: The Hidden Language of Computer Hardware and Software）
7. Head First 设计模式（Head First Design Patterns）
8. 编程珠玑（Programming Pearls）
9. Effective Java中文版（Effective Java (2nd Edition)）or Effective C++（第三版）中文版
10. 测试驱动开发(Test Driven Development: By Example)
上面的这些书我自己都读过，所以我不难相信很多不是很优秀的程序员也都读过它们。如果你对编程有足够的兴趣，能够来到这里读这篇博客，你很可能读过 其中的大部分，甚至还有很多不在这个清单中的，所以我就不浪费时间每本书都评论一番了。我想说的是，这个清单上的每本书都是它各自领域里的奇书。所以，很 多有愿望不断提高自己的编程技术的程序员都读过这些书，这就不足为怪了。
在人们备受推崇的计算机书籍中，还有一类书受到了独特的待遇。我称下面这个清单为“最常被程序员们谎称读过的计算机书籍”。这并不是说推荐这些书的 人都没有真正读过它们。我只是有相当的信心怀疑更多的人只是在口头上宣称读过下列书籍，而实际上很少人真正读过它们。下面就是这个清单。
最常被程序员们谎称读过的计算机书籍
1. 算法导论（Introduction to Algorithms）(CLRS)这本书的名称是所有出版过的计算机书籍中最让人误解一个。它被广泛的使用在很多大学里，通常被当作毕业生必需的算法课程。于是，只要在大学里上过计算机课程的学生几乎都有一本这样的书。然而，除非你拥有计算机硕士学位(而且是算法研究领域的)，我怀疑你顶多只读过算法导论（Introduction to Algorithms）里节选的几章内容。这个书名让人误解，是因为”Introduction”这个词让人以为它很适合初级程序员。实际上不是。这本书对算法做尽可能详尽综合的介绍，就像其它一些随处可见的类似的书一样。请不要再把这本书推荐给初学者。
2. 编译原理(Compilers: Principles, Techniques, and Tools)(the Dragon Book). 这本恐龙封面的书涵盖了开发一个编译器你所需要的全部的知识。它的内容包括词汇分析，语法分析，类型检查，代码优化，以及其它很多高深的题目。请不要把这 本书推荐给初级程序员，他们需要的只是分析简单的包含数学公式或HTML的字符串。除非你真的需要实现一个能够实用的编译器(或解释器)，你根本不需要掌 握这本“恐龙”书的全部强大威力。把它推荐给一个遇到简单文本分析问题的人，这证明你根本没有读过它。
3. 计算机程序设计艺术(The Art of Computer Programming)(TAOCP)我 经常听到人们把这本书描述为“每个程序员必读”的系列计算机书籍。我认为这明显不是实情。在我说出这样大不敬的话、被你们用板砖拍死之前，请让我做解释一 下。这不是一本让你一页一页翻着读的书。这是一本参考大全书。把它放在你的书架上看起来会很不错(实际上也它确实很好)，但如果想把它通读一遍，你需要几 年时间，而且最后什么都没记住。这并不是说手边放这样一本书没有什么价值。它是一本参考书，当我遇到难题，走投无路时，很多次我都在这本书里找到办法。但 这本书终究是被我当作参考书。它复杂难懂，很理论，里面的例子都是汇编语言的。好的一面是，如果你想在这本书里寻找针对某一问题的解决方案，如果你找不 到，那就说明这个问题无解。它是一本对它所涉及到的领域做了最最详尽介绍的一本书。
4. 设计模式：可复用面向对象软件的基础(Gang of Four)这本书是唯一一本在这个清单里我从头到尾读过的书，读的结果是，我不知道该把这本书归到哪个类别。它出现在这个清单里，并不是因为我认为只有很少人真正读过它。很多人都读过。只是因为有更多推荐过这本书的人自己却没有读过。Design Patterns这边书的问题在于，很多书里给出的信息，你在其它很多地方都能看到。这样就使得一个初学者在维基百科上读了几篇关于设计模式的内容后，就敢在面试中宣称自己看过这本书。这就是为什么Singleton成 了一种新的全局变量的原因。如果有更多的人花时间读过这本也叫做Gang of Four的书的原著，那世界上就不会有这么多人会把17种设计模式硬塞到一个日志(logging)框架里了。这本书最精彩的部分是每章里描述如何正确的 使用一种模式的段落。遗憾的是，这些精华却在很多其它设计模式资料里被漏掉了。
5. C++程序设计语言(The C++ Programming Language)这本书不像一本编程教材，更像一本编程语言参考。有很多的迹象表明有人确实读过这本书，否则我们不可能有这么多的C++ 编译器可选择。编程初学者(或者甚至其它语言的专家)，如果想学C++，不应该直接去啃C++程序设计语言(The C++ Programming Language)这本书。告诉他们去读《C++ Primer中文版》。
正如我之前说的，我知道你们当中会有一些人真正的读过这些书。那这篇文章不是针对你的，针对的是那些企图通过假装读过这些书来表现自己的民众。 如果你自己没有读过这些计算机书籍，请不要推荐给别人。这样做会耽误别人的时间，误人子弟，因为一些阅历更丰富的人可能会有更好的书(更针对某一领域，更容易理解，跟某种编程语言或某种编程水平更契合的书)来推荐。除此之外，你也能避免被那些真正读过计算机程序设计艺术(The Art of Computer Programming)的人用MMIX知识给拷问住造成的尴尬(如果你不知道我在说什么，那我指的就是你)。
来源:外刊评论
一种很流行的说法是，程序员是把咖啡因转化成程序代码的机器。
说的是实情，随便问一个程序员，问他什么时候工作最有状态，估计他很有可能说是深夜。有人稍微早一点，有人更晚。有一种流行的趋势是凌晨4点起床，在破晓之前这段时间里做一些事情。而另一些人喜欢凌晨4点才睡觉。
所有这些的主要目的是躲避打搅。但是你把自己反锁在屋里不就行了？为什么对夜晚情有独钟？
我想，这事归纳下来有3点：工人的时间表，疲倦的大脑和明亮的电脑屏幕。
工人的时间表
Paul Graham 在2009年写了一篇关于 工人的时间表的文章——主要是说这个世界(主要)存在两种时间表。传统的管理者的时间表——一天的时间别分成了很多小时，一次十分钟的分心至多会浪费你1个小时的时间。
而另一种情况是程序员们所说的工人的时间表——生产东西的人的时间表。研究一个大型的抽象的系统，需要把整件事情装进大脑——这样的一些人类似于用珍贵的水晶玻璃搭建一间房子，一旦有人打搅你，整个结构都会滑落，摔成无数的碎片。
这就是为什么被打扰的程序员会如此的生气。
因为这是一种巨大的精力上的投资，在没有几个小时不被打搅的环境中的酝酿，你不可能开始工作。如果你好不容易在大脑中构建了整个要思考的事情的模型，而在半个小时后被人摧毁，这是很大的浪费。
事实上，在跟很多的企业创办人交谈后，你会发现，他们都感觉在白天根本无法做任何事情。持续不断的打扰、重要的事情需要注意、大量的邮件需要处理，环境不允许他们坐下来做事。于是他们大部分人都在夜晚，人们都入睡的时候去完成他们要做的事做完。
疲倦的大脑
但是程序员仍然在晚上会困倦。程序员不是超人。程序员甚至在白天都会感到疲劳。
为什么我们要把智力上最复杂的事情放到我们的大脑想去睡觉的时间段里去完成，而在我们的大脑最敏锐最清醒的时候去做相对简单的事？
因为疲倦让我们编写出最好的代码。
跟ballmer峰值相似，疲倦能使我们的精力更容易集中，因为你的大脑疲倦了，不得不集中精力！没有多余的脑能量来提供你去三心二意。
对我来说，如果喝了太多的茶或在错误的时间喝了提神饮料，我反而干不了什么事。我会过度兴奋，一会查看微博，一会看看新闻，不知道自己该做什么。
你会认为我应该更有效率的工作——精力充沛，大脑超频。但正好相反，我东一榔头西一耙子，根本无法在一件事情上定神2分钟。
而反过来，当我稍微有点疲倦时，我却能把屁股安稳的放到椅子上开始编程。在大脑稍微有点疲倦的情况下，我能连续编程数小时，毫不考虑微博或Facebook。好像这互联网根本不存在。
我感觉大部分程序员都是跟我的感觉是一样的。对于日常工作中80%的任务，我们的脑能力都是过剩的——除非你需要写的是在当前程序运行的环境中让它增速10的算法。即使你开发的是最高级的机器学习想象功能，其中大部分的工作也只是简单的整理数据和以一种合适的方式表现输出结果。
当你的大脑不是满负荷运转时，它总是想找点事情做。疲乏会让你迟钝，手头的工作就已经够你消化了。
明亮的电脑屏幕
这一点非常的简单。在晚上老是盯着明亮的光源，你的睡眠周期会推迟。你忘了该是睡觉的时候了，直到凌晨3点。然后你早上11点才能起来，当晚上再次到来时你不再感到困倦，因为你11点才起床！
反复这样的作息规律，你的身体会进入另外一个时区。更有趣的是，这种周期不会一直推迟下去，一旦你进入了这种3点或4点才去睡觉的生理平衡状态，你会一直留在这种状态里。
也许这是一种警讯在起作用，社会在告诉我们，如果我们在下午2点吃早餐，会被认为是很邋遢的人。
最后
总结一下，程序员喜欢在晚上工作，是因为这时没有何时应该停止工作的限制，这让人感到更放松，你的大脑不再思考让你分心的事情，明亮的屏幕使人清醒。
来源:外刊评论
