观点调查
在全书的访谈中，有些问题基本上每个人都会谈到，所以首先把好几个人都人认同的观点先列出来。
编程最重要的是数据结构
加里·基尔代尔
比尔·盖茨
丹·布兰克林
只有小团队才能写出优秀的程序
约翰·沃诺克
比尔·盖茨
C.韦恩·莱特莱夫
雷·奥奇
彼得·罗伊森
鲍勃·卡尔
安迪·赫兹菲尔德
好的程序具有美感
C.韦恩·莱特莱夫
鲍勃·弗兰克斯顿
乔纳森·萨奇
彼得·罗伊森
编程这个活动特殊的一点在于只要计算机和网线，就能完成所有
巴特勒·兰普森
雷·奥奇
彼得·罗伊森
安迪·赫兹菲尔德
本科应该先学习科学、数学，研究生再学计算机
巴特勒·兰普森
约翰·沃诺克
喜欢开飞机
查尔斯·西蒙尼
加里·基尔代尔
查尔斯·西蒙尼
编程同时蕴含科学、艺术和手艺。艺术是因为编程中存在审美，代码即使不是数学上严格的结构化，只要有可取之处，也可以是优美的。手艺是因为编程是一项复杂技能，跟工具制造很像，需要雕琢。
编程第一步是想象，要在脑海中对来龙去脉非常清晰。想象待维护的数据结构，在整个编码过程中将它牢记于心。
管理的最佳方式是言传身教，坚持代码复审。
代码的开发效率随着人手的增加而会有所降低。
预估程序编写的时间很难，但仍要尽力而为预估，因为它可能会很有用。
成为优秀程序员没有套路，天分和环境很重要。正如《如何解题》上说的，首先理解问题，然后拟定计划，接着执行计划，最后回顾整个过程。这样的培训对刚入职的程序员很有帮助。
未来的计算机会更高效但差别不大。对鼓吹多好多妙的新方法格外警惕。事情会剧变为更好，但是需要时间，因为新想法必须不断演变，坏想法也要时间消亡。
抽象的编程和业务的编程的主要区别在于后者目的的非常明确。
巴特勒·兰普森
计算机是最棒的玩具，相比其它领域它能更简单地实现奇思妙想。
通过数学学会逻辑推理，学会如何证明以及如何处理抽象要素。通过物理等实验科学或人文学科，学会如何应用这些抽象在现实中建立联系，从长远看更能在计算机领域发挥聪明才智。
必须掌握复杂性，一切都应该尽可能简单。从根本上把事情分而治之分解开，并准确描述各部分应实现什么功能，这就形成了接下来如何行事的纲要。如果没想清楚写不出规格书，那要么要回到真正理解的另外某个问题，要么更努力地思考以求理解透。
系统地描述不应该太庞大，也许必须从多个较小的角度来考虑一个大系统。
先尽量用精确而抽象的语言写出构思的关键部分，通常这个阶段会有大量迭代。拟定程序和规格说明再去实际实现。
编写优异的程序或系统最重要的目标是尽可能准确地定义系统和外界之间的接口，以及系统自身各主要部件之间的接口。
发明算法和设计程序截然不同。发明算法关键在于脑中形成整个计划，然后不断调整各个部分，最后找到达成计划的最佳方法。
怎么确定设计的系统能实现？一种可能是把设计细化到编程的层面，另一种是非常仔细和正式地写下程序应该具备哪些属性，然后说服自己它的确拥有那些属性。
程序员最重要的素质是能把问题的解决方案组织成容易操控的结构，其中每个组件都可以用简单的方式说明。
程序相比画更像音乐，既是工件也是艺术。优美的程序简单明了，像优美的定理。
学习数学，学会思考，阅读，写作，这些东西更有持久的价值。学习如何证明定理，这项技能可以用在其它许多事情上。
约翰·沃诺克
程序员看待一段代码应当像看待一本书的烂章节那样，弃之如敝履。千万不要迷恋一个想法，绝不要固守某样东西以致不能在必要时把它丢掉，这才是程序员应有的态度。另外绝不要假设你知道的东西别人不知道。对好的方法或工具，要迅速采纳并善用之，而不必心存「非我创造不可」的烦恼，非要用自己的方式不可。
对好程序执行性能检查时，它的性能应该呈现扁平状。这表明代码里不存在瓶颈。好程序在于它能保持平衡，而不是靠什么奇技淫巧。把程序各个部分妥善组合在一起，才是优秀计算机程序员之道。
我相信在数学、英语和基础科学方面拥有坚实的基础极为重要。然后，等到读研时，可以尽管放手去学习计算机知识。如果你真想成功，先适应社会其他领域，然后再进入计算机行业，这才是更为可取的成功之道。
信息时代就是一个巨大的反馈环路，你用的每个新工具都可以帮你构建更强大的的工具。
在这一行要取得成功，你需要找一拨才华横溢的人，而且他们的技能可以很好地融合互补。
编程有什么诀窍？不要早作绑定，尽可能推迟决定时间。眼界放宽一些，设计要比你自认为需要的程度更加灵活，因为从长远看你最终会需要这样。快速让某样东西工作起来，然后还能弃之不用。从小的开始实验而不是大的入手学习。最好每两个月就要出点成果，这样你才能进行评估、重组和重新开始。
编写软件在哪些方面吸引你？我觉得编写软件好比著书立说，就像常规写作一样。你努力把想法和观念融合在一起，力争让其他人觉得那是全新而激动人心的。
我不会偏爱某一种语言，而是选择最合适的环境和编译器工具集，这才是需要考虑的因素。
我坚信好软件出自 2 到 4 人的小团队，成员之间互动频繁密集。把公司当作 20 家不同的小公司。不断拆分，绝不让它发展成庞大的组织，知道没有人嫌它大为止。在工作关系上，员工数量尽可能少，工作内容尽可能专，并以项目为导向，这样他们才能达到最佳的工作状态。这也是我的目标。
计算机科学，比起科学，它更像工程学科。在我看来，科学就是提出假说，做各种实验，在现实世界中创建模型。计算器却不是这样，它们是关于现实世界模型的自我实现的预言，是极好的信息工具，是当代社会的重大成果，用来操纵和控制信息。但是，说到计算机科学，我不知道它试图追求什么样的真理。
加里·基尔代尔
我教的两件事对学生们的学习来说是很重要：解决问题以及如何学习。
编程风格：我会先画数据结构，然后花很长时间思考数据结构。在开始编程前，我会一直思考整个程序的流程。在确定数据结构之后，我就开始写一些小段的代码，并不断地改善和监测。如果不能确认数据结构是正确的，我是绝不会开始编码的。我很少写 注释，除了在程序开头的地方外，唯一的注释就是数据结构了。我不会对代码本身加注释，因为我觉得正确编写出来的代码本身就是很好的文档了。
作为编程基础的数据结构，从本质上看是机械的。最大的不同是，木制或铁制的东西需要花好几个小时来建造，如果做得不正确，必须回去重新做。而程序可以在瞬间完成修改。
我很讲求实效。我喜欢编写快速而小巧的程序，喜欢采用清晰而简洁的算法。
当一个程序干净整洁、结构良好、前后一致时，它就是美丽的。我特别喜欢 LISP 语言。
编程有艺术的成分在里面。但很多编程是发明和实现。编程也有科学的成分在里面，不过不是很多。实验科学意味着你要假设、尝试并比较结果，从这种意义上讲，编程也是科学。你可能有一个概念，知道检索系统应该如何工作，但只有在使用足够的数据运行时，才能看到机制是可行的，并得到一些统计数据。
如果你和一群使用相同程序语言的程序员谈论编程的话，他们几乎可以成为那种编程语言的传教士。他们组成来一个紧密结合的社群，坚持一定的信念，在编程时遵循一定的规则。就像是一个把编程语言当作圣经的教会。
计算机会如此成功的原因，就是因为我们的技术会简化机械的过程。
编程依赖的是信念而不是理性。
程序的灵活性显示来一名好的程序设计师与一个只是写写代码的程序员之间会有多么大的差异。
比尔·盖茨
在微软的软件开发过程中，我做两件关键的事情。一是选择在程序中放入哪些功能。为了做到这一点，必须合理把握什么事情容易做、什么事情不容易做。还必须明白你追求的产品系列的策略是什么样的，并要关注硬件领域的进展。此外，我还致力于实现新功能的最佳方案，也就是如何把新功能做得既小又快。
编程中最困难的部分是确定采用什么算法，然后还要尽可能地简化算法。做到最简单的形式是很难的。必须在心中模拟程序是如何工作的，必选完全了解程序各部分是如何一起工作的。最好的软件是其中有一个程序员完全了解程序的工作方式。要做到这一点，必须要热别热爱编程，集中精力让程序变得极为简洁。
程序要做到顶尖，最重要的是，那些关键的内部代码都要是由少数几个知道自己在做些什么的人编写出来的。
很多程序都太大了，已经没有一个人可以真正了解整个程序的所有部分了。
最糟糕的程序是由原来的程序员在开始时没有打好基础，而他们也没有再参与到程序的后续开发中。在这类程序上继续工作就会遇到一种我所说的「实验性程序」的情况。程序员对那些程序了解太少，他们不知道改动之后会影响什么。
如何创造一个环境以确保能开发出成功的软件？一种方法是建立小型的项目团队，通常是四五个人一组，其中一人经证实有能力掌控整个程序。如果这个项目带头人遇到不确定的事情，他会与经验更丰富的程序员一起讨论。部分策略是让所有程序员在进入编码阶段之前先想清楚每一件事情。编写程序设计文档是至关重要的，因为在把问题当作算法看得时候，问题会得到很大的简化。可以说算法是最简单的形式。另一个重要的因素是代码复查，要确保代码是看过的，看看资深人士是否能提出如何做得更好的建议。而且你必须参考类似的、做得特别特别好的项目。
如何确保各种不同的人融洽地一起工作？首先项目组必须由能够相互尊重的成员组成，因为这个工作需要密切配合。优秀程序员的一个要素来源于学习如何与其他人一起工作，并教导他人。保持项目团队精简；确保小组中每个程序员都非常聪明；为他们提供强大的工具；有一套公用术语，一边大家很有效地沟通，而在这些小组外，找一些丰富的资深人士，在遇到问题时能够出谋划策。
我喜欢在坐下来编写代码之前先把整个设计方案构想清楚。编写程序最重要的部分是设计数据结构。接下来重要的部分是分解各种代码块。
我们会允许程序比该有的稍臃肿。但在速度方面，不允许因懒惰而不设法使程序尽可能地快。
我认为在过了最初的三四年后，就会非常明显地显现出你是否是一个优秀的程序员。检验编程能力的最好方法之一就是给程序员一本 30 来页代码，看看他阅读和理解的速度有多块。
成为程序员的最佳途径是编写程序并研究其他人编写的优秀程序。你要愿意去看别人写的代码，然后写自己的代码，再让其他人复查你的代码。你需要身处这个不可思议的反馈循环当中。
如果和一个优秀的程序员聊一聊，你会发现他对他使用的工具非常熟悉。
约翰·佩奇
从程序员设计非常复杂的软件到为普通人设计出可用的软件是一个非常有趣的转变。
我在生活中通常的做法是先规划目标，而一旦设定了目标，就不再重新审视，也不会再考虑这些目标有多么困难、是否值得做、是否会成功。我不再考虑别的了，只想着完成任务。
公司员工需要觉得他们是在负责自己的工作，并且在心里上觉得他们是正在实施项目的主人，否则就没有积极性了。
公司需要真正的系统设计师————就是那些能够透过基本的工具看到需要构建什么、需要使用哪些技术以及该如何使用的人。一个公司必须要有这样的人。公司还需要那些可以为宏伟的设计架构编写代码的人，就是那些好的技术人员。把需要做什么很精确地定义好，就可以交给那些刚从学校毕业的、获得计算机科学学位的人来做。
我坚信只能由一个人来做产品和高层结构的设计，最多不能超过两个人。所有的设计处于一个头脑，才能够实现和谐与一致。
实施设计方案所需要的队伍越大，就越必须严格地把整个系统划分成可管理的模块，并定义好相互间的接口。
一个小系统的架构可能会过于大，一个大系统的架构可能会过于小————使用的技术必须与问题的规模相匹配。
我不会告诉新手应该如何做设计，而是教他们我做设计的流程，也就是试着去教育他们。我试图传授一些他们可以终生受益的技能。
程序员必须遵循的技巧或规则？你必须了解客户，了解计算机，为客户和计算机设计出最优秀的产品，除此之外，就没有什么基本原则了。
我不会容忍一个软件工程师只想做复杂的程序设计。首先，我认为这样的态度不够成熟。一个好的建筑师不管是设计一个小凉亭合适设计一个大博物馆，都能从中得到快乐，它们各有各的挑战。第二，我认为真正的挑战是如何设计出一个外表简单而内部复杂的软件。
为了适应变化的市场，可以从两个方向调整产品。一种发展是由计算机及其技术驱动的。另外一种发展是由客户体验的变化驱动的。
当你在复杂的程序上艰苦工作时，锻炼身体是很重要的。
为什么程序员沉迷于工作？你在脑海中不断地考虑正在做的整个系统的状态。如果失去了脑海中所思考的形象，就需要花很长时间才能回到原来的状态。
你编程的过程是什么样的？我会坐下来想想程序要做成什么样子，然后的脑海中描绘出程序的部件。然后在开始实现前，我会定下来整个程序的结构。在画好结构草图后，我就一个部分接一个部分地去做了，并确定各个部分之间的接口。
我认为计算机科学不是一门真正的科学，因为你没有实际发现有关物质世界的任何东西。
C.韦恩·莱特莱夫
和其他程序员比较时，我发现自己很大程度上喜欢通用化地解决问题，而其他人更喜欢编写程序解决某一特殊需求。他们的程序通常比我的交付得更快，但我的程序则生命期更长。
非常多的程序员只考虑该怎么写出程序，他们从来没有做过销售。他们可能是好的程序员，但他们没有想过真正的市场需求。
当团队超过 6 个人时，那就完全失控了。
遇到多个项目，我一般只做一个，完全排斥其他事情。如果我切换的话，那就完全切换。我可能把一些事情搁一边，这些事情就会靠边站，可能我几个月都不会再去碰，然后我会回过来重新处理。
我是那种喜欢做点计划的程序员，但我不会把计划做到事无巨细。找出能达到目标的下一步才是真正的工作，我总能做到达到下一步的最少的工作。在一个步骤里，我取最小的子集。我不是先做最难的部分，也不是先做最容易的部分。
如果你程序写得好，它可以是优雅、平衡、和谐。代码应当干脆简练。你应当可以用一句话解释任何一个模块。如果可能，内容应当按字母顺序排序，这让事情变得简单，使程序变得干净，是走向优雅的第一步。仅从视觉角度讲，代码不应该在任何地方掉出打印纸的边缘。不应当有一个很大的「if」，而「else」却很小。一切东西在任何地方都应当平衡。理想的模块应当有一页长。如果它超过一页，我就必须思考：我现在做的是什么？我现在做的不同事情有哪几件？优雅和平衡的部分要素就是，在一个程序的蛋糕一样的层次结构里，要在某种程度上让所有的模块都具有相同重要、相同大小、相同责任和相同的功能。平衡使得程序变得可维护。
总有少数人可以做到普通人能做的工作量的 6 倍之多。
我喜欢从一无所有开始做出某种东西。有些人喜欢一开始有个小东西，然后在成长期把它扩大；有些人喜欢拿很大的东西开始，把它培育得更大。
我的目标是写出优雅的软件和有挑战性的程序。解决社会需求不是我的使命，但确实是软件的一个美妙的结果。
我认为编程有科学的成分，也有艺术的成分。
如果有人想要编程，编程就不是难事。如果他们不想编程，那无论他们怎么努力尝试，最好的结果也是很难，更大的可能是他们会感到幻灭。所以我的建议是，做你想做的事。
在编程里，所需的一切只是辛勤工作。只要足够努力，你总可以找到问题的答案。
丹·布兰克林
我也察觉到，当程序员没有前途，他们要跟我这样的毛头小子竞争；新人受过良好的训练，肯接受低薪，愿意工作更长时间。我看到要保持巅峰状态异常困难。
写程序最重要的部分是设计数据结构。
我们正在让用户自己做越来越多的编程工作，只不过他们不知道罢了。
本质上，编程包含家庭手工业的成分。我们持续不断地改进可利用的工具、操作系统、环境和语言等。因此，个体在是能比他过去做更多的事情。
人们总是想让事情进展得快上加快。但其实它们是经历若干个 5 年、10 年才做成的。
编程部分是科学，部分是技能。但编程也有手艺的成分，见习训练是编程的必经之路。通过见习训练，你可以掌握技能。有些事情，说到底还是熟能生巧。因此，它更像一门手艺或艺术。编程和当精算师不同，它更多的是标准化手艺。在开发上面，受过正规训练的人往往比没受过训练的人更具优势。
鲍勃·弗兰克斯顿
程序在哪方面最具有美感？我想不光是一个方面，而是多个元素的组合。程序是否易于理解？是否优雅？是否体现出对目标的基本理解和精巧的设计，还是只是一些元素杂乱无章地堆砌在一起？是否容易修改、开发或变更？
一旦我们要让大家使用这个产品，需要考虑的就不只是编程了，还要考虑美感和可用性。
优秀的人一般需要满足两个因素：正好具备这个知识领域所需要的心智，并且在能力上又不是太愚钝。很多编程技巧都是可以传授的。一个优秀的程序员必须喜欢编程，对它感兴趣，这样才会努力多学一点。优秀的程序员还要对美学有感觉，并且有相应的负罪感，能够敏锐地意识到什么时候违反了程序的美感。负罪感迫使他更努力地去改进程序，使程序更加符合美感。
如果连你自己都无法把程序解释清楚，那么计算机能够正确运行的可能性就很小。
做大型项目时，你需要和其他很多人一起合作，你不能总是临时决定设计和各种问题。你必须思考最终结果，给人们提供目标、设定规则，而不是一上来就说「这个主意不好，不能那样做，要这样做」。
对年轻程序员的忠告？总的来说，不要以为你知道所有东西，要努力尝试学习并质疑那些假定知道的东西。要信心十足，但要保持谦虚，要猜想你可能做错了什么。要有刚好足够多的负罪感————不要太多，不然就会害怕去做任何事情————但要足以建立美感。尝试去做更深刻的理解。不要因为你曾经使它运行成功了，就以为再也没有什么需要去了解的了。
在编程中，我发现很多理解来自心理学，来自人们是如何与这个世界打交道的。
乔纳森·萨奇
在整个开发过程中，保持软件一直都是可以使用的。这意味着，到了软件开发的某个时刻，如果需要的话，产品就可以交付使用了。虽然这一版本的程序可能不会拥有所有功能，但我们知道程序是可以运行的。
如果只是我自己一个人开发，我总是样做，一层一层地去构建。刚开始先让程序能够运行起来，然后再添加新功能。
是什么让人成为好的程序员？是天赋、气质、动机和努力工作的结合。成功来自一遍又一遍地做同样的事情，每次学习一点点，下一次都做得更好一点。现在的人很难获得广泛全面的工作经验了，因为工作已经被细分了。人们往往在很早就开始专攻某一方面。
我会把大部分程序分解成相当小的模块，我会写很多注释，对模块、输入和输出都进行描述。这就是我做的所有的注释。再为模块内部的工作机制编写文档就没有意义了。
好的程序是简单而对称的。
雷·奥奇
编写好程序有什么技巧？我推崇严谨、一致而清晰的结构。另外，我认为软件应该高度模块化和分层，非常灵活地运用大量文件和目录。如果你必须分别构建不同的组件，那么接口自然就会更加凸显出来，要求你规范这些接口。当许多人共同开发一个程序时，在项目早期确定全局的错误处理、参数传递和子程序命名规范（虽然不见得所有人都会同意），显得非常重要。对于代码该怎么注释、大括号怎么用或者代码该怎么缩进，我觉得你绝不应该对别人指手画脚。在修改别人的模块时，你最好还是按照他的惯例编写代码。交流想法的环境应该是开放的。设计会议上允许非常激烈和紧张的讨论。优秀的设计师不会有「Not Invented Here」综合征。
管理人员试图颁发条例或过度管制时，往往很容易滋生问题。程序员很有创造力，善于自我指导和自我激励。整个环境必须有利于编程，程序员不必担心自己做的是否跟他们的同侪（或管理同行）一样多，因为这些不安全感可能会对积极性造成负面影响。他们应该感觉得到自己是团队的一部分。这就是为什么团队规模应该尽量小，并且尽量不要分等级的原因。
为什么偏爱阅历丰富的程序员？要有丰富的阅历，你必须做过各种不同的任务。大学毕业后，最理想的选择是在某个领域认真做上一年左右，然后转到计算机学科另一个截然不同的领域。从长远来看，做一个全面的程序员，你会更吃香，身价更高。
产品的设计和实现不应该超过 5 个人。人一多，产品一致性方面就可能出现问题。缺陷往往是子系统之间接口糟糕的表征，这通常要归咎于设计人员在设计各子系统时沟通不良。发现缺陷时，人们倾向于在子系统内部加一解决，而不是从整体上处理这个程序。
在开发过程中，产品必须具有非常清晰、一致的架构模型。你可以在开发过程中改变架构，但不可以到结束时才用修正缺陷的方式来修补糟糕的架构。在整个产品开发周期中，极为重要的一点就是要始终牢记最终目标。
如何向最终用户提供他想要的东西？我们会尽量想出哪些用户会使用该产品。然后，我们设法粗略估计使用每个功能的用户占比，这样才能有根据地猜测哪些功能的使用频率最高。尽量把大部分时间用于完善使用比例最高的特性。如果某个不起眼的功能只有小部分用户使用，我们就不会为这个功能的设计大费周章。
编程是热衷修补者的最终归宿。电气工程师可以把各种组件放在一起搭建东西，但他们受制于物理设备是否容易获取。而有了计算机，只有你想不到，没有做不到的。你可以设计自己的工具，或边做边打造部件。不喜欢某样东西的话，你可以修改或直接重写它。惟一的限制因素是计算机执行任务所用的时间和你编写程序所需的时间。
怎么防范职业倦怠？时间不要排得太紧，开发过程中要合理安排休息次数。
对年轻程序员的建议？保持乐观的心态，尽量多编程，同时尽可能参加各种不同的项目。尽可能多把时间花在计算机上，还要学会准确判断自己的职业倦怠状况。要是别人觉得你很古怪，不用放在心上。
彼得·罗伊森
切合实际对编程很重要。你必须能够猜出完成一个项目的准确时间，具有推断可以做哪些、不可以做哪些的能力，然后据此去做，抵制中途停下来干其他事情的诱惑。
我相信使用自己编写出来的东西非常重要。这并不是说我是自己的程序的最好用户，而是因为经常使用的话我就可以意识到程序中的缺点，可以在发现什么地方做得很笨拙的时候就把它改掉。
在以前，很多公司会把分析师和程序员分开。如果你想解决问题，却碰到一拨人只管画方框、另一拨人只管填补方框的内容，你最终不可避免只能拿到一堆不能解决问题的垃圾。没有人聪明到看一下整体图景就知道程序需要操作的具体细节。所以我赞成一个人把程序从头写到尾。
在想做的事情和当天可以完成的事情之间有着很大的区别。
设计好程序的唯一必要条件是兴趣。如果你不上心，纵然你有盖世之才也只会得到糟糕的结果；如果你真上了心，只需三分之一的才能就能弄出一些不错的东西来。
为什么你认为好主意没人实行？大机构并没有创造环境来鼓励员工进行创造性的思考。员工做到了要求做的事情，就可以得到报偿，多做也没用。没有动力的话，给程序员提要求的人拿不出引人入胜的项目，而程序员也不会花时间去思考解决问题的有趣方式。
解决简单问题的方案必须简单。
当我让我选择实现一个特殊的有用功能还是一般化的功能时，我通常会选择一般化的功能，前提条件是简单用途的使用体验不会变糟。
我常常禁不住想：为什么会有人给我这么好的薪水，而我并没有做什么对世界有益的事情————我只是无所事事地和别人一起喝咖啡，写永远不会被实现的可行性报告和没人会去用的程序。
我生活中的一个重大组成部分就是做自己喜欢的工作，这不需要开一辆保时捷。如果现在给我两个选择，一个是拿一半的钱做我喜欢做的事情，一个是拿两倍的钱做别人让我做的事情，我会选择低收入和自由。
我认为编程是艺术。任何做得好的事情都可以成为艺术，因为任何工作都可以加上一定的品味或艺术天赋来完成。我经常重新整理代码，就为了让它看起来漂亮。
任何问题的最大也是最困难的部分就是决定采取什么方向。
编程的一个伟大之处就是你可以拥有设备自己来干活。要完成某件工作，你不一定需要别人跟你合作。你可以非常独立。
好的程序员是一个对他所从事的工作有相当兴趣的人。他的目标是做出一个尽可能好的产品。
鲍勃·卡尔
优秀的软件开发是由一个良好的初始设计加上其后一系列非常扎实的工程而组成的。
尽可能推迟编码。一旦写了一堆代码后，就很难改变方向了。但程序设计却一直在我的脑海中，从来没有停止过。
最好的设计工作是开始时有一个精良优秀的设计，让它运转起来，然后对只有在使用过程中才能想到的其它想法做出响应。
公司发展得越好，我觉越担心它什么时候就要结束了。
团队必须要小，也就是说，不能超过七八个人。
我倾向于把事情简化到一个相当简单的框架，然后再把它扩展开来应用到现实世界中。我不苛求完美，并不指望框架对应用它的每个功能来说都非常适合，但我希望不论是什么主题，这个框架都能为使用者提供深刻的见解和指导。
程序设计中的具体规则？首先，做事情的粒度是非常重要的，粒度应该灵活。对于软件而言，用户必须能够把他们的工作和程序拆分成独立的块，而不是作为单个巨大实体处理。第二，软件的体系结构应该是同质的，不应当有很多例外或特殊情况。第三，最强大的软件通常在内部采用递归，并常常为用户提供递归功能。
设计用户界面的规则？实现透明度，用户应当忘记他们和信息之间还有一个程序存在。命令及行为的一致性和可预见性是增加透明度的两个最重要的因素。所有指令都应当作用于用户已经选择或标记的数据，这就是所谓的面向对象的动作设计，而非面向动作的对象设计，不是选择命令后，再指定范围。
任何产品的外部用户接口都有一个架构或者结构。它有它的路线和途径。程序的内部结构也可以被描述为一个架构。通过观测它们是如何相互联系的，它们是否能够互相映射，你就大致可预测这一程序最终能否成功了。最佳的程序的外部架构会映射到内部架构中。
用户界面中的两个层面是句法和语义。每个用户界面都有自己的句法，那是那些支配如何与命令本身进行互动的规则或方面————如何呈现命令，如何发出指令，命令的响应或操作是什么样的。但语义层对易用性同样重要，它涉及指令的含义，或者说应当如何处理信息。
杰夫·拉斯金
我一贯认为要干好活得选对工具。
你赚的钱越多，愿意聆听你的人就越多。
当我使用一个系统时，如果可以全神贯注于自己要做的事情而不是这个系统本身，那我就是最快乐的。系统不应该侵扰用户。
安迪·赫兹菲尔德
电脑能让人体会到控制和力量的奇妙感觉。随便想点什么，然后让电脑做到你想做的，这种感觉太妙了。并且一直都是如此。这正是吸引我进入这个领域的原因所在。学习编程就像学骑自行车，光看手册指南行不通，你必须亲身实践。
在我看来，只有设计者和实现者是同一拨人，才能把工作做好。写代码的人就是设计代码的人。
编程最吸引你的是什么？这是我能想到的唯一工作，可以让我身兼工程师和艺术家两种角色。它包含难以置信的、严密的技术元素，这是我所喜欢的，为此你必须一丝不苟，思维缜密。另一方面，它有极具创造性的一面，唯一真正的限制就是你的想象力。这两者元素的联姻使得编程独一无二。你必须既当艺术家又当科学家。
ps. 他是 Google Circle 用户界面主要设计人，纪念一下我最喜欢的 G+。
岩谷彻
斯科特·金
第三方软件是有软件公司使用常规编程语言开发的，而第四方软件是由用户自己创建的，无需编程，至少在通常意义上可以这样理解。它建立在第三方软件之上。这就需要有非常丰富的第三方软件作为基础。
编程应该是很简单的，所有用户都可以创建自己个性化的软件。
除非计算机在周围环境中被忽略不见，否则就算不上成功。
如果你要去做什么事情，那前提就是从一个非常简洁的设计开始，不论是打算写一本书，准备编写一个软件，还是即将开始一个需要规划的项目，开始的时候都要有一个非常简洁的设计。
加隆·兰尼尔
我们可以说「太阳系」，可以说「行星作圆周运动」，我们可以描述这样的概念。但如果使用计算机，你可以创造出一个这样的系统，一个对你所描述的概念的仿真。我认为这种建模的能力，相对于仅仅使用名称来指代概念，是计算机对人类做出的最有价值的贡献。最终，这会让人们可以沟通现在还很难沟通的思想。
很多懂计算机和数学的人也懂音乐。音乐和编程语言相似。
迈克尔·霍利
我喜欢编程的地方，则是它可以真正帮助你思考我们该如何沟通、如何思考、逻辑如何运行，创造性艺术如何产生。计算机是沟通和信息的工具，而沟通是美好的事情。计算机可能是看待沟通问题的终极工具。
流行风潮经常是盲目奔向新技术，而你一定要意识到在这个过程中放弃了什么。
所有新技术都会有烦恼的问题，就是人们认为他们可以不用付出任何代价就得到新东西。
如果人们勇于学习的话，他们除了探索新科技外，也会研究老科技，这样他们才能同时重视两者、理解大图景里各个食物的关系。