《编程人生》的读后感10篇

　　《编程人生》是一本由Peter Seibel著作，人民邮电出版社出版的平装图书，本书定价：79.00元，页数：473，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。

　　《编程人生》读后感(一)：编程人生

　　如果那个软件我知道如何使用，但不了解内部的工作机制，我通常会选择一个特定的命令或者交互行为然后追踪下去。

　　1 当我要开始阅读EMACS源代码的话，我会说放我们看看向前移动一个字符的那部分代码吧。即使我不能完全理解，至少知道它使用的一些数据结构和缓冲区的怎么表示的，如果我足够幸运，我能找到缓冲区增加一个地方。一旦我理解了之后，我接下来尝试后退一个字符，删除一行字符。通过这种观念方式就了解越来越多的使用方法后者交互，直到我觉得我能够按照这种方法追踪代码的其他更重要的部分。

　　我会用单步调试器对付那些70年代的那种小一点的程序，今天的问题是从启动程序到它真正可以做点什么，这中间可以说是一段很长的初始化过程，所以更好的办法是找到主命令循环或者中央控制子程序，从那里开始追踪。

　　通常我只是在了解事情是怎么运行的时候，才会去阅读源码.有时候我是带着特定目的，因为我想解决某个问题。我从中学到一个一件事，大师级的程序员是如何组织数据结构的，如何组织代码使它易于阅读，甚者可以把它当作一部小说去阅读。你可以从头到尾顺序阅读它，也可以在遇到问题的跳跃的阅读。

　　对我而言，学习一门新的语言，或是针对某个难题寻找新的解法，最简单的方法就是直接阅读源代码。而且这些源码最好就出自自己身边杰出程序员之手。

　　lisp 侦听器就成了检查器。只要它打印出对象，就会出现一个上下文菜单，可以点击菜单，返回指定的值，这么一来，很容易跟踪一组相关的对象和类似的东西。深入代码，来回修改，不断实验。我渐渐不再使用，而是直接插入打印语句，再重新运行程序。如此反复，直到搞定为止。特别是在你接触越来越多的比较原始的环境，这是你唯一的选择。因为那些环境根本就没有调试器。

　　我会先审读代码，通读代码，直到我认为一切正常，不可能出错。然后我会插入一些代码，尝试解决存在的问题，如果审读代码没有纰漏，我就会停在中间或其他什么位置，看看问题出在哪里。

　　我会一头扎进，开始阅读代码。更常见的是学习如何使用某个新的库或者工具包。幸福的话，你能 找到一些文档，还有API.最后弄清楚自己可能会用到的那部分，或者弄懂它是怎么实现的，对于EMACS的程序，有可能从底层着手，CONS cell 怎么组成？怎么用？然后以此为基础扩展开来，有时，从构建系统下手，让自己专注于代码有个好方法，那就是挑选一项你感兴趣的任务，然后尽力搞定他。

　　对于EMACS这类软件，你或许可以找个现有模块，剖析实现机制，好，现在我已经掌握这段代码，然后抽取真正实现功能的那部分，就能得到样板。至此，我弄明白了这个系统的组件是什么样的，接着就可以开始把我的东西放回到系统里，基本上就是不断抽取，直到出现骨架。

　　4 如果你理解不了某件东西的工作原理，那就找做这块的人问，许多人都害怕这么做，但那样毫无比翼，不知道某件东西并不代表你笨，知识暂时还不知道罢了。

　　5 只是到处看看，我想知道他们是怎么工作的，把东西拆开看看的冲动是将人们带入这一行当的一大原因。

　　6 好奇心，把这东西大卸八块的好奇心。渴望弄明白底层是怎么回事。我以为那是技能之本。缺了好奇心，就如同在浮沙之上筑高塔，好奇心是你获取知识的主要途径，把东西拆开，用心研习，你才能做好自己的东西。至少我是这么做的。我的经验主要来自不断挖掘源代码和参考手册。首先确定目标，没问题，实现这个目标我需要弄清楚这东西做什么，然后，我会随意折腾一番，直到确定方向未止。

　　要是回头查阅，比如浏览一本书，你能否快速找出自己隐约记得要点位于全书什么位置。大概在书里的中间部分，作者在那儿讲到这一点，你要找的东西散布在全书各个地方。

　　7 快速掌握别人的代码并且弄清楚其用法，这项技能变得更加重要。

　　要试着组电更难的东西，超出能力范围的东西，要多读代码。我以前常常听人这么说，不过那时一直没有静心去做，那么多年我写了很多代码，可从来没读过别人德，后来我上了因特网，有那么多我可以贡献力量的开源代码，但我却被吓倒。慢慢的，我变得很喜欢读代码。因为当我遇到不理解的模式的时候，我就会问：等下，他们为什么要这么做。随后再多看看就明白过来了：哇。这真是个好办法，很有效果。我应该早些开始，但是我害怕，因为我觉得如果不是自己的代码，我就没办法理解它。

　　8通常我事想要修改一些东西，如果你崇拜某个程序员，也可以去读读它的代码。

　　9 第一步，找个原始的TAR文件，试着把那该死的东西构建起来。你一定要跨过那道坎，那对多数人来说是最大的障碍====构建系统的时候假定你已经安装了这个库。我希望这些大项目都能自带一个虚拟机。

　　10 一般来说，我只是大致的看一下，试着去了解目录结构，然后如果有东西吸引我的注意，或者我对什么东西不太了解，我就随便挑个文件，感受一下，随后漫无目的的区看看周围的文件，直到我厌倦，再挑个新文件去看。

　　11 很多时候，我会边构建边读代码，因为通常这是可以并行的任务，尤其是当构建困难时，完成构建后，如果我愿意，就可以开始调整它。

　　如果环境允许，我会选打印语句，要是所处的环境有好的调试器，那用调试器，

　　我的学习曲线是这样，学东西很快，直到我学好它而且相当高产力为止。这时候我效率很高，不用去查阅资料，只有到我觉得过度安稳了之后，我才会想我要去仔细阅读这门语言的文档，了解所有细枝末节的内容。

　　12 像科学家那样思考，一次改变一样东西。有耐心，试着去了解问题的本质，尤其是在调试或者设计那些不太正常的东西时候更应该这样。我看到过年轻程序员抱怨，然后彻底重写，其实应该停下看看究竟发生了什么，要学会增量的开发，这样每一步你都能进行验证。

　　我认为一个小时的代码阅读抵得上两周的QA.这种剔除错误的手段是很高效的。如果你让能力很强的同时阅读代码，那么他们周围的新手就会学到很多东西，而这一切是无法通过其他手段获得的，如果新手来阅读代码，那么她会得到很多极具价值的建议。

　　13我通常会从上往下读，但是如果程序太大，函数或者控制流会变得不清晰，我就会用调试工具来辅助阅读。我也会根据我了解的框架结构从底层向顶层分析，如果是一个语言处理程序，或者是一个我能弄明白的关于系统调用的东西，我会从它对原始类型的操作入手，我会问自己，这个东西是怎么被更高层的系统调用的---这样问一下对我了解整个程序帮助很大。但更重要的是程序背后的一整套结构，这需要你从多角度去读这个代码，去用调试工具运行，一步一步分析。当然，这个过程很乏味。

　　《编程人生》读后感(二)：80后的软件先驱Fitzpatrick访谈录

　　以访谈录的形式来将15位软件先驱的方方面面融合到一本书，起码对于采访者有非常高的要求，这点来说，Peter Seibel做的非常成功，他对技术及程序员到软件先驱的成长路上的经验与挑战有很好的把握，也就是说，通过Peter的访谈，读者基本能找到自己想要的，也正是本书的一大特色，不需要软件先驱们自己立传出书，而是通过一些轻松的访谈甚至是类似脱口秀的方式来布道解惑。

　　我一般喜欢在下班之余，一个人在空荡荡的办公室看上一段，看的比较慢，但是收获还是挺多的。同为80后，我很好奇Fitzpatrick（偶一直怀疑Fitzpatrick是不是Fitz与Patrick的合体*_*）的成长历程，该君生于1980年属于前期的80后，5岁的时候就在父亲的有意引导下在appleII上进行编程（这是个很好的开端，5岁的时候偶还在和泥巴、玩鼻涕……），6、7岁的时候阅读appleII程序员手册……不过此君还真的算天赋异禀，最好的表现就是在6岁的时候能抽象出打印变量然后用一行代码代替40行代码（估计就是36个字母加上一些标点）的事例，对比我大学时候一位师弟不会for循环直接写N次代码的往事，此君简直就是天使。

　　我最喜欢的一个小故事就是Fitzpatrick向同学兜售自己写的游戏，当时显示器支持2种模式，EGA和VGA，需要不同的贴图处理，估计此君程序检测显示接口不是很健壮，所以经常导致很多同学买了游戏，回去运行就是黑屏，然后家长就电话过来向Fitzpatrick的母亲说Fitzpatrick拿了个没用的东西在他孩子那骗钱，于是的母亲就开车带着Fitzpatrick去该同学家上门服务，解决软件问题。这情形看起来挺搞笑的，也很温馨，不说误工费，或许Fitzpatrick妈妈开车来回一趟的汽油费都不止Fitzpatrick卖游戏的钱，可是他妈妈还是如此的支持。

　　Fitzpatrick君在中学的时候因为痴迷CGI而说服当地ISP运行他自己写的一个投票脚本，也就是后来流行的FreeVote；之后，进大学的前一年，Fitzpatrick开始了LiveJournal，运营LiveJournal期间，Fitzpatrick在解决LiveJournal运营问题的时候，发布了memcached和perlbal等优秀的开源软件，具体的原因及解决问题的步骤，这里不再复述：），通过大学期间运营LiveJournal，Fitzpatrick发现并解决问题，成为他成长的一个黄金时期。在回顾自己大学生活的时候，Fitzpatrick觉得在大学期间经营事业是最好的方式----对比起那些在大学仅仅完成学业的同学，或者是提前退学经营事业，Fitzpatrick在学业与事业中找到了一个很好的平衡点。

　　Fitzpatrick因为熟悉Perl等高级语言，但是他还是强调底层的重要性，认为高级语言程序员还是很有必要知道一些底层知识。

　　Fitzpatrick眼中优秀程序员的最大特点就是自我驱动，能做很多没有人安排他做的事，积极主动，对工作充满激情----这个也就是目前Fitzpatrick在Google招人的必要条件。

　　一些来自Fitzpatrick的建议：

　　1.像科学家般的思考，一次改变一样东西；

　　2.有耐心，试着去了解问题的本质，学会增量的开发；

　　3.学习提高沟通技巧，包括在邮件列表里的书面沟通；

　　《编程人生》读后感(三)：《编程人生》——与编程大师们的对话

　　读完图灵俱乐部译的《编程人生》的前两章，给我第一感觉就是：听君一席话，胜读十年书。 Peter Seibel先生对编程先驱Zawinski、Fitzpatrick的访谈非常精彩。从这两章访谈中，我收获到了以下几点：

　　1. 保持好奇心，充满激情，编程人生才精彩，编程人生才快乐。著名黑客Zawinski好拆卸电子玩具一样对软件的内在充满了好奇，Fitzpatrick从小就对软件的神奇如痴如醉。同时，Fitzpatrick告诉我们，绝不能把编程仅仅当工作来看待，而应该是一件充满乐趣的事情。换言之，作为一个软件开发者，如果你仅仅以薪资衡量你的代码的话，那么还是赶快找个后路吧。

　　2. 语言没有优劣之分，在语言之间的优劣性方面打口水战是毫无意义的。在Perl语言方面，Zawinski和Fitzpatrick就存在巨大的分歧。 Zawinski认为Perl的语法太过古怪，数据结构一团糟；而Fitzpatrick就非常喜欢Perl的灵活性。而在C++语言方面，两位大师表现出一直性厌恶型。不过，对C++的厌恶只是厌恶，Fitzpatrick还是得用C++来构建高性能的程序。

　　3. 大师们与我们同在。Zawinski为Emacs贡献了很多。在我们用Emacs编辑代码时，Zawinsk与我们同在。当我们使用memcache这个Web前端利器时，Fitzpatrick就与我们同在。

　　4. 教育要从娃娃抓起。Zawinski和Fitzpatrick很小就接触了编程，发现并且发展了这方面的能力，终成一代大师。

　　5. 做软件产品，情况不同，侧重点也不同。做新产品抢地盘，及时推出质量合格的产品才有生存的机会。而有条件的话，早期更充分的考虑软件产品后面运营可能遭遇到的问题，后面改动的成本就会大大降低。

　　后面还有十三位大师的访谈录，真想知道会带给我些什么更精彩的内容。

　　《编程人生》读后感(四)：让你学会狂妄懂得谦卑的书

　　这是一本让人激奋又让人颓唐的书；这是一本让人学会狂妄，或者懂得谦卑的书；这是一本让人藐视编码，或者尊重编码的书；最终，它是一本教会我们从程序中收获乐趣的书，教师是这样一批让人高山仰止的牛人们。

　　正是因为这些牛人们不同寻常的经历，使得我们在阅读本书时，既充满了孜孜以求的决心，又觉得那样的高度太难攀登，以至于自惭形秽。这些牛人们或者是狂狷的geek，或者是低调谦虚的学者，如此不同的混合体在一本书中展现，仿佛万花筒一般展现程序员的不同魅力，就让我们觉得目不暇接，他们中的谁才称得上是我们心中的偶像呢？这些牛人们都是一群天资聪颖的编程高手，面对编程中的难题，他们有着绝世高手的风范，十步杀一人，千里不留行，编码对于他们而言不值一提，却又乐此不疲。他们都是程序世界中的掌控者，先驱者，阅读本书，就是阅读他们的人生征途，和他们对话，了解他们的精彩人生。

　　本书的作者即书中十五位软件先驱的采访者，本身就是Common Lisp的专家，这就使得访问者与被访者的对话是平等的，能够在深层次挖掘问题，直达问题的本质。因为是访谈，所能能够容忍不同意见，看着不同专家就同一话题表达相反的看法，就给了我们一种很新鲜的感觉。这本书不再是同一张面孔，因此可以一直读下去，而不至于厌倦或疲惫。然而，通读此书，我又发现虽然千人千面，却又都是两只眼睛，两只耳朵，一个鼻子一张嘴。书中的这些牛人们其实又都有着诸多相似的一面。他们：

　　1. 都是技术的狂热爱好者，并深深为自己从事的行业感到自豪；

　　2. 都是编程的执著爱人，至今仍不放弃编码；

　　3. 从小就表现出对计算机的狂热，他们精通的语言几乎都是自学；

　　4. 不太在意软件工程的方法学，在他们心中有着属于自己的标准；

　　5. 对程序之美的观感几乎一致，那就是简洁、清晰和优雅；

　　6. 大多数不在意设计模式，甚至轻视设计模式，对于设计，自有他们的一套主张；

　　7. 都认为编程并不需要了解底层，但如果能了解底层，会更好；

　　8. 拥有好的数学天赋，或许可以说在数学家中，他们编程编得最好，在程序员里，他们数学学得最好；

　　9. 更倾向于自己是工匠或艺人，然后才是科学家；

　　10. 他们都是一群理想主义者，又是一群实证主义者，他们讨厌政治。

　　这些共同要素，是否就是成为编程高手的必备呢？如果是，那么检查检查自己，看看自己能否在未来跻身他们的行列？即使不能成为像书中主角那样的牛人，比照他们，也可以审视自己选择的路，你走得快乐吗？你感到自豪吗？对于编程，你还在意吗？

　　《编程人生》读后感(五)：【访谈系列】

　　rogrammers at Work

　　中文版：编程大师访谈录

　　Founders at Work

　　中文版：创业者

　　Coders at Work

　　中文版：编程人生

　　Masterminds of Programming

　　中文版：编程之魂

　　《编程人生》读后感(六)：一千个读者，一千个不同的编程人生

　　读这本书，你不能指望从大师那学到什么可以立马上手的技能，也不能奢望读完了你就站在了大师的肩膀从此可以一览无遗。相反，这是一本介绍15位世界级编程大师的“发迹”史的。开放的国度和文化造就了先进的IT业，还有他们，这些中国读者熟悉不熟悉的名字。

　　所以，换个角度看，阅读这样的书是一种奢侈。每位大师都被迫回答相似甚至相同的问题，迎接每位IT粉丝的八卦心理。

　　“你最早什么时候开始编程的？”，“你还记得你写的第一个有趣的程序是什么吗？”OK，他们对于这样问题的答案，无疑会让粉丝们在被头衔唬住之后，又让粉丝顶礼膜拜一番：那些事情发生得太早了，现代人几乎不知道那些答案是什么。所以访谈的开头部分，基本上对于读者来说价值不大。

　　这样的问题还有：“你用过Knuth的文学编程吗？”，或者类似“你使用怎样的工具写代码？”你会发现，但凡大师级的人物，都是自信的，甚至是偏执的，比如对于工具的选择，他们的答案多半是“我打开Emacs就开始写了”，或者是“我使用记事本写就好了”。看，这是大师的选择，你是不是也要这么干呢？

　　不一定每位大师生来就是天才，但不必怀疑他们对于程序代码一生的追求和兴趣。我们可以看到他们之于这份事业的执着，学习他们的态度。

　　值得推荐的是，他们对于编程语言的看法（比如Joshua Bloch对于Java发展的自信以及不满），还有对于开发过程的看法，怎么调试代码，对于优秀书籍的推荐，他们还会谈到怎样跟团队合作。

　　甚至你还能看到他们彼此间的争执，是的，就这本书里面。比如Douglas Crockford和Brendan Eich关于ES4的争论和调侃。这个世界本来就没有什么绝对的对与错，不是么？大师亦如此。

　　一千个读者，就会读出一千个不同的编程人生。这是一本枕边书，需要反复读、细细体味。

　　《编程人生》读后感(七)：编程人生

　　---

　　date: 2017-01-11 10:07

　　title: coders-at-work

　　---

　　## 《编程人生》

　　tart：2016-1-3 18:34:34

　　end：2017-4-3 22:38:31

　　2016年的做了一件文艺的事：订阅了一个月的 *新世相* 图书馆，其中第三期是《巴黎评论·作家访谈》。当时非常纳闷为什么会收到这样书，等到看《编程人生》时才明白其中的份量：《Writers at Work》 vs 《Coders at Work》。顺便用这本书来解释一下曾经的疑问：

　　gt; 为什么身边没有超过 40 岁的程序员？他们都去哪了？

　　## Jamie Zawinski

　　编写自己回头还能看懂的代码，这点至关重要。

　　不过我们成功发布了产品，这才是关键。（Netscape）

　　我们绝对是百分百力求高质量。我们要在3月31日前发布我们力所能及的最高质量。

　　我认为有一点非常重要，不要害怕自己的无知。

　　不过，在我看来，这本书一派胡言，给人的感觉好像编程只需剪切粘贴就能搞定。（《设计模式》）

　　说好今晚发布产品，到时候就必须给我发布！（过度设计）

　　更差就是更好。

　　《人月神话》《计算机程序结构与解释》《计算机程序设计艺术》

　　## Brad Fitzpatrick

　　你能看到他们在那里做乘法。—— 价格是你们在不破产的情况下的所有可支配收入。

　　有，读研可能很有意思，不过我太忙了。

　　HR的经验中有这么一条 —— 一些人只会做让他们做的事，没有那种追求极致的热情。

　　有这么一个笑话：如果人们用造软件的方法来盖摩天大楼，那第一只啄木鸟就能毁掉文明世界。

　　没有。最坏的情况就是我停下来，自己找点乐子。

　　## Douglas Crockford

　　代码的可读性是我的第一要义。它比速度还重要，可以与正确性一争高下，可读性是正确性的重要前提。

　　软件这么复杂，错误之路千万条啊。

　　《出埃及记》

　　## Brendan Eich

　　文学化编程

　　但是话说回来，我也喜欢研究理论，理论对于改善我们的生活还是很有帮助的。

　　编程很有意思，能让我不听地熬夜。

　　不是所有程序员都是会提意见的，很多程序员都有点孤僻，喜欢单干。—— 如果我只考虑自己，我又能走多远？

　　《魔戒》《摩托车维修的禅与艺术》

　　## Joshua Bloch

　　不要重复自己。

　　学习一种新语言的时候，要利用以前所学的语言功底，但是也要保持开放的心态。（你本来只有一个榔头）

　　选择一种语言 vs 希望去一个酒吧

　　梅特卡夫定律：网络的价值与用户数量的平方成正比。

　　另外，年轻的时候，你有无尽的精力，你可以不停地钻研。

　　“你瞧，以前的一切你都做得挺好的，这次也错不了。”

　　所以你要睁大双眼，积极地吸收重组各种思想，这样做绝对错不了。（生活中看到的很多东西）

　　先写使用，再写实现。—— 设计软件的方法

　　API设计有一条基本原则：疑则不用。

　　“简单没那么容易做到。”

　　“结对编程”

　　我们做的东西是一种美学追求。需要一些数学技巧，一些人际关系技巧，一些写作技巧，这些都不属于工程领域，但是缺了这些你不可能成为一个真正优秀的工程师。所以我觉得这些东西是我们必须牢记的。尽管如此，我仍然认为编程是这个星球上最有趣的工作。我觉得我们很幸运长大在这个时代，可以利用这些技巧做出这样的工作。我不知道在过去的时代我们这样的人应该去做什么工作。

　　《Java 解惑》《Java 并发编程实践》《effective Java》《设计模式》《计算机程序设计心理学》

　　## Joe Armstrong

　　没有。我没钱了。所以没有读完。

　　不需要考虑该做些什么，只管做就行了。（我们那时没有这些难以选择的地方。）

　　程序员被哄骗着使用所有这些不同的编程语言，他们被哄骗着不要使用简单的方法把程序连接在一起。

　　先不要动手写代码，把这些东西都想好，这样做不是更好吗？

　　男子汉气概的编程 vs 现在，如果觉得不行，我就不再编程了。

　　科学是关于逻辑和数学的 vs 科学也有很多直觉，根据直觉能够知道什么是正确的

　　解决问题 vs 进行表达

　　自底向上

　　我喜欢编程。为什么会不喜欢呢？

　　应当在程序中你认为可能出错的地方放上一些 printf 语句，重新编译并运行。—— 编程之神

　　你改过一些东西，所以你必须记住改的是什么地方。—— Joe 调试定律

　　Unix哲学：程序应只做它应当做的，不应该做其他事情 vs 它应当是通用的程序，而程序本身应当是这种通用程序的特定案例（增加通用性，然后具体化）

　　问题越复杂，我就越可能先写文档

　　如果你不擅长英语，就永远都不可能成为一个优秀的程序员。—— Dijkstra

　　如果在不好的领域做好的东西，那你做什么都没有意义。—— You and Your Research

　　花上 20% 的时间学习新东西，因为只是有复利的。

　　letcheley Park

　　## Simon Peyton Jones

　　不惜一切代价避免成功：不要过度成功，不要过早成功

　　对整个编程体系的一次彻底而优雅的攻击。建造了一面新墙而不仅仅在墙上添一块砖。—— 谈函数式编程

　　那可能是我第一次认识到，编写一个真正大型的程序时，最后可能遇到规模的问题。那可能是我第一次认真地尝试着编写长期使用的文档。

　　动手去做，不管这件事有多么不起眼。—— John Washbrook

　　我作为程序员，生活中最糟糕的事情是，面对别人的一堆代码不敢动手去改，或者更糟糕的是，面对自己编写的代码也不敢动手去改。真是太让人泄气了。

　　《编程珠玑》《代码之美》

　　## Peter Norving

　　从此我觉得“或许我天生就擅长编程”，也明白了“或许老师也不是无所不知的”。

　　但我的确领悟到一点：在团队中，你不能什么事都亲力亲为。

　　做学徒最棒的一点，就是能观察大师的所作所为。

　　你必须有所进展，还能加以改进。

　　“停电的时候，我的程序是否还能正常工作呢？”

　　我想应该从静态和动态两方面去做。（程序 = 数据结构 + 算法）

　　没，我找准了自己的位置。我们有数以亿计的用户，我们会让他们感觉到日新月异的变化，也会为他们不断地更新服务。我觉得这种感觉很棒，因为我无法想象自己做别的事情也能为人们带来如此巨大的影响。

　　industrial programming、Modeling Checking、constraint propagation、over-generalization

　　《代码大全》《文学编程》

　　## Guy Steele

　　管理复杂性的唯一方法是保持事情简单，包括编程语言。—— Sheme 学派

　　重要的是意识到你所做的是一种权衡。

　　是的，我们都不知道将来。如果我可以改变一件事 —— 听上去有点蠢 —— 如果时光倒流到从前，如果我可以改变一件事，我想劝远古的人们不要使用手指头来数数。及早确立一个新标准，可以让现代生活变得更容易些。

　　《黑客词典》《算法分析与设计》《C专家编程》

　　## Dan Ingalls

　　实际上，我对主流世界不抱什么希望，我有自己id想做的或想让它变得容易的事情。

　　计算机的强大之处在于它们给予数学以生命。

　　你必须具备逻辑头脑。

　　就我而言，工程师（有一套可重复的施工过程）的成分最少，其次是工匠（木材每次都不一样，有些经验法则，但没办法保证特定的结果），最像是艺术家和科学家之间的有趣组合。

　　如有更大的挑战在召唤你，你一定会深入进去，因为你不得不这么做而如果你的兴趣被激发，你也会深入进去，因为你愿意这么做。

　　尽可能将从进展中获得的满足感反馈给那段时间与你相处的所有人，至少让他们意识到你在做的事情还不错。

　　## L Peter Deutsch

　　在我鼎盛时期，我有特别可靠的直觉。

　　之所以要保证和客户的紧密接触，是因为想要避免过早的泛化或过度设计。

　　所以我对计算机技术的未来不是很乐观。实话说，这也是我能轻松地全身而退的原因之一。我看到的是一个不被不道德的垄断者通知的世界，在那里我找不到自己的位置。（微软）

　　XP

　　## Ken Thompson

　　激情洋溢的编程，我从来不会感到压力。

　　这很容易上瘾，但你绝不会想去让自己的孩子也深陷其中。

　　MIT 风格 vs 新泽西（贝尔实验室）风格 —— 《更差既是更好》

　　entaminos

　　## Fran Allen

　　我们正处在一个十字路口，极有可能迷失方向。我们可能会走错路，这样就不得不再多花些时间折返回来。—— 图灵奖获奖感言

　　计算机是创造性的触发器。

　　想想自己的职业生涯和做事的方式，真要用一个词来总结的话，我认为“探索”最为合适。我喜欢探索一切事物的前言，创意、项目以至万事万物，包括人类本身，我觉得这一切如此令人兴奋。但也有一点，我总是启动着，而非终结者。我总是被新事物所吸引。

　　## Bernie Cosell

　　我坚信系统不宕机至关重要。

　　最终我做到了他们没有办到的：让系统跑起来。

　　“我不能很好的理解这段代码都能做些什么，所以我重写了一遍。”

　　要编写大量程序。—— 对众多自学的程序员的建议

　　要知道，我一直秉持着系统永不崩溃、用不停顿的理念。

　　实时系统很重要的一点，是一切都必须设置超时。

　　不过，我常常会跟他们交谈，亲自观察，看看他们是否具备我想要的素质，我总是希望身边的人能够刨根问底、勤学好问、一丝不苟。

　　哦，又是一门通过限制程序员所为来帮助他们步入正轨的语言。—— 评论 Java

　　设计评审、重构

　　## Donald Knuth

　　它改变了我从精神层面看待事物的角度，也由此改变了我的写作风格。我会更自由洒脱，会更全面地看问题，也会对写出来的东西更有把握。

　　我觉得编程和宗教很像，每个人都有自己的信仰。

　　过早优化是万恶之源。

　　在我看来，C语言对指针的运用是编程语言中最重要的变革之一。

　　不过我希望对每一个程序员个体来说，因为求知欲而编程的想法不会慢慢消逝。

　　我必须认清我的原罪（sins）。人们不断回想过去发生过的事情，目的是解罪（absolution）。这是个宗教术语。

　　我会出错是因为我总是游走于极限边缘。如果仅仅一直安于现状而不思进去，那也未免太无聊了。

　　你不仅要知道某项成就归功于谁，还要回头看看他是怎么用他自己的话表述出来的。我认为，这是提高能力的极好方法。

　　能够深入到别人的思维方式之中，并对他们使用的词汇和符号进行解码，这是非常重要的。

　　对，你说的没错。不过，多种不同形式的编程记法还是有用的 —— 不要只阅读那些编程习惯跟自己一样的家伙的代码。

　　《The Lions Book》

　　literate programming、syntactic sugar

　　《编程人生》读后感(八)：人生就是不一样啊

　　前些天和同事开玩笑的说，你愿意花10元钱去听对一位世界顶级大师的采访么？几乎所有的都表示愿意付更多的钱也去。

　　对呀，很便宜不是么？我读到了这本《编程人生》（英文版名称为Coders at Work）有十五位编程大师的访谈，我在读书的时候大赚了一笔。

　　当然我读这本书不是赚了“心里账户”里那一百多元，更让我认识到的他们思想和我的差异是那么的大啊。我近两年才认识到那一切花哨的东西都是浮云，我更注重思想方面的东西，在这之前我特爱追求这样那样的特性，研究各个版本的API差异。

　　这些顶级大师们的想法都各异，我对他们的想法有很多还是不能理解，不过我想先了解了在以后试着去理解。他们毕竟都是从打孔写代码的那个年代过来的人，他们对C++以及OO都有别样的看法，或许他们足够聪明到能在各个思维的层面上自由穿越吧。

　　书中采访方式的确特别像《鲁豫有约》、《艺术人生》，读起来也特别的轻松，因为轻松所以也就使人愉悦。粗略的来说基本上就两步：

　　第一步：忆童年，回忆牛人的计算机发展历程，谈计算机的变化。

　　第二步：谈经验，谈牛人对语言的喜爱、谈工具的使用、谈算法的素养、谈技能、谈面试等等。

　　虽然套路都是这套路，但是每个问题每位大师都给出了不同的答案，人物自传都是描述的人物的发展历程的，人物不一样历程自然不一样。

　　我记得在大学里就开始意识一个问题，我平时动手的时候比动脑的时候还多，先瞎撞一通不灵的时候才真正发挥大脑的作用。我现在想一些比较难的问题的时候我都离开电脑，思路在离开电脑后就边的好多了。我发现即便是大师们也有类似的习惯！他们的也许是因为有了这样那样的好习惯才能成为大师，我打算把他们的（我认为的）好习惯去实施一下。

　　《编程人生》读后感(九)：编程人生——牛人们的故事

　　很高兴收到图灵出版社<<编程人生>>这本书，这本书汇集了众多杰出的程序员先驱者们的故事，比如Unix，C语言作者之一Ken Thompson、算法巨著<<计算机程序设计艺术>>的作者Donald Knuth。作为热爱编程的一员，能在这里了解到他们对职业生涯的想法以及对编程的看法实在是太棒了，于是收到这本书时，我很激动且毫不保留的将这书推荐给我的同事和朋友（本文的另一作者灾难）。

　　这本书通过采访的方式并辑录而成，也许在这种谈话方式下其回答可能会不全面，但这是他们最真实最直接的编程感受和体验。从访谈交流的过程中字里行间体会到他们对所从事的工作的热情，并享受以此带来的乐趣。工作而非工作，是生活中的巧克力。因提快程序速度而兴奋；因新出语言特性不合理而愤怒。他们在程序的世界里面享受产品与技术带来的欢乐、抽丝剥茧得到真相的成就，为了计算机领域更加美好的拼搏。

　　rad Fitzpatrick在他的程序世界搭建自己的世界，在他的程序世界里面有他的生活，程序中有他的生活乐趣，因为父母看到了孩子喝酒的帖子，想起了 “啊，要做个权限了。”；想取笑朋友一篇傻乎乎的文章，“啊，要做个评论的了。”因为觉得有趣而编程，因为编程生活变得有趣。

　　Jamie Zawinski觉得要从产品的角度去生产，而不是为了抽象而抽象，不能因程序员的过度追求完美而过度设计，有些为了完成功能也许采用了不是很完美的解决方法，可是这样能让产品推出去，而不是成为没人使用过的代码。Douglas Crockford极力反对ECMAｓｃｒｉｐｔ4纳入ECMAｓｃｒｉｐｔ语言标准里，努力推进WEB向前发展。作为Javaｓｃｒｉｐｔ的布道者，从更高的角度去修正ECMAｓｃｒｉｐｔ规范，以WEB的发展为己责，优雅的编程，用程序写作，从语言的特性出发去了解语言，利用该语言编写优美的程序，就像写散文一般，从艺术的角度解读程序；计算机领域有着产品生产以及计算机科学领域，从他们的谈话中，有些如何在产品生产和计算机科学领域中平衡的观点值得借鉴。

　　Ken Thompson对于代码的编写认为不是一成不变，当发现了新的程序结构划分或更好的实现方式会修改它，当发现旧的代码实现混乱难于修改便扔掉这些腐烂的代码，对于现有的代码，他的态度是从不迷恋，这也许正应对了我比较认同的一句话“天天重构，每天重构那么点点。”

　　记录这些谈话并不是漫无目的的，从几个方面和这些软件先驱者进行问答，对于编程语言的想法、对于团队管理的想法、对于编程方式的想法、对于程序产品的想法、对于设计架构的想法、关于编程调试、怎样培养新人的想法。从这本书中得到这些软件先驱者多少年积累下来的经验以及思考，可以从他们的视角去看待这些问题。虽然有些问题解决场景在今天来说并不适合，可是有了他们在这些问题上的探索，我们在解决同类问题时多了些参考与思路。

　　从他们的经验中得知他们走过怎样的路，什么样的路是失败的路，怎样才是比较好的解决办法，如何去思索现有的问题，如何去解决，当然他们的经验并不对每个人都适用，对于我们这些后来者而言，吸取精华为己所用，体会编程带来的快乐，让我们享受编码的过程吧。

　　《编程人生》读后感(十)：大段大段的文字都刺激不了神经

　　这些大师基本上都是大学之前开始编程，并通过各种兼职、实习的方式参与大量的编程实践，又佐证了一万小时理论。

　　而对于编程语言、编程方式，每个人的看法都不同，甚至截然相反，所以口味的问题并不重要，重要的是深刻的理解。

　　另外，这些程序员几乎都是五六十年代成长起来的那拨人，关注的问题离计算机的本质更近，离我们现在的编程环境更远。

　　所以15篇采访中，只有Peter Norvig， Brendan Eich等少数几个的对话感觉比较鲜活一些，因为谈论的字眼比较能刺激神经。

　　关于现在程序员和老一辈程序员的区别与优劣的问题，各位大师倒没有武断地做定论，而是承认现在所面对的环境比之前要复杂得多，人们不太可能有精力去拆开所有的盒子一探究竟，也难有精力同时对最底层和最顶层的细节了如指掌。

　　然后觉得有必要学习下编译器。

　　作为非科班出身的同学，感觉真是路漫漫。