个人性格与软件开发.doc

在软件开发中人们很少注意个人性格问题。自从 1965 年Edsger Dijkstra 的有里程碑意义的文章“程序开发是一种人类活动”发表以来，程序员性格被认为是合理的和有成效的研究领域，虽然有些题目如“大桥建筑者的心理”和“对律师行为的研究实验”看起来可能是荒唐的，而在计算机领域，“计算机编程中的心理”和“对程序员行为的研究实验”等题目则是常见的。 每个领域的工程人员都知道工具和他们所用材料的局限性。如果你是一位电机工程师，你就应明白各种材料的导电性和使用电压表的各种方法。如果你是一位建筑师，你就应明白木材、混凝土、钢材的性能。而如果你是一位软件工程师，你的基本建筑材料是人的聪明才智，并且你的主要工具是你自己。建筑师是将建筑物结构进行详细的设计，然后将设计蓝图交给其它人去建造，而你则是一旦当你从细节上对软件作出设计后，软件生成过程也就结束了。 编程的整个工作就如建造空中楼阁一样它并不是纯粹的人工活动。于是，当软件工程师研究工具和材料的必需性时，他们发现自己正在研究人的智力、性格，不像木材、混凝土和钢材等可见的东西。 编程工作极强的内部特点使得个人特点异常重要，你想想一天全神贯注地工作八小时有多么困难，你可能有过由于精力过份集中而今天无精打彩的体验。或由于上个月过份投入而本月没有一点精神，你也可能在某一天从上午8 点工作到下午2 点，以致于精神快要坍塌了。有时你从下午2 点拼命于到5 点，然后花费一周的时间修改你在其间所写的东西。 人们难以对编程工作进行检查，因为没有人知道你真正干些什么，我们经常有过这样的体验，我们花费8O的时间进行我们所感兴趣的20的工作，同时花费2O的时间生成其余80的程序。 你的老板并不能强迫你成为一个好的程序员，甚至过了很长一段时间你的老板也无法判断你是否是一个称职的程序员，如果你想成为一个高手，你得全靠你自己下功夫。它和你个人性格有关。 一旦你自己决定成为一个高级程序员，你发展的潜力是很大的，各种研究发现，创建一个程序所需的时间比可达到10：1，同时也发现调试一个程序时间，程序实现长度、速度、错误率和所发现错误数对不同的程序员其差别可达10：1。 你无法改变自己的聪明程度，但是你可在一定程度上改变自己的性格，已发现在程序员成为高级程序员的过程，性格是更有决定意义的因素。 聪明和谦虚 聪明看起来似乎不是个人性格的一个贡献。它也的确不是。恰巧的是，好的智力是和成为一个好的程序员有着并不严密关系的因素。 为什么？难道这并不要求你有一个好的智力吗？ 不，你不需这样，没有人真正同计算机一样迅速敏捷。完全理解一个一般的程序需要你有吸收细节的很强的能力，并能同时理解所有细节，你很好地利用你的聪明要比你有多聪明更为重要。 在 1972 年，Edsger Dijkstra 发表一篇论文，名字叫作“谦虚的程序员”。他在此文中主张所有的程序员都应尽力弥补他们很有限制的智力。那些最精通编程序的人往往是那些认为自己的头脑是多么有限的人，他们是谦虚的。而那些最为糟糕的程序员往往是那些拒绝承认自己的能力不适应工作任务的程序员。他们的自我妨碍自己成为优秀程序员，你学到越多的东西来弥补你的大脑，你就越能成为一个好的程序员，你越谦虚，你取得的进步也就越快。 许多良好的编程风格的目的是减少你大脑的负担，以下是一些例子： “分解”一个系统的目的是为了使其更为简单易懂。人们往往易于理解几条简单的信息而不是一条复杂的信息。所有软件设计方法的目的是将复杂的问题分解为简单的几部分，不论你是否使用结构化、自顶向下或是面向对象的设计，以上目标都相同。 进行评审、检查和测试是弥补人的错误的一种方法，评审方法部份源于“无错编程”，如果你没有任何错误，你就用不看评审你的软件，但是当你知道自己的能力是有限时，你就应和别人讨论以提高你的软件质量。 将子程序编短一些有助于减少你的工作量。你根据问题而不是计算机科学术语编写程序并使用尽可能高级的抽象思维，有助于减少你的工作量。 使用各种交谈方式可将你从编程的死胡同中解放出来。 你也许认为靠聪明能更好地开发人的智力活动，所以你无需这些帮助。你也可能认为使用智力帮助的程序员是走弯路。实际上，研究表明那些使用各种方式弥补其错误的谦虚的程序员们所编写的程序既易为自己也易为别人所理解，并且其程序中所含错误也少。实际的弯路是出现错误和影响进度的路。 好奇心 一旦你认为自己理解程序的能力是有限的，而且你意识到，进行有效的编程是补偿自己能力的方法时，你就开始了你生涯中漫长的探索过程。 在变成高级程序员的过程中，对技术的好奇心是很重要的。有关的技术信息变化迅速。许多PC程序员没有在什么机器上编过程，而许多程序员还没有用过电脑的穿孔卡片。技术环境的特定特征每隔5 到10 年就发生变化。如果你跟不上这种变化，你将面临落伍的威胁。 程序员往往很忙碌，以致于他们没有时间对更好地工作或对工作发生兴趣。如果你真是这样，你也不必在意大多，因为许多人都同你一样，以下是一些培养你的好奇心的方法，你真应该好好学一学它。 在开发过程中建立自我意识。你对开发过程越了解，不管你是通过对开发过程的阅读或自己的观察得来的，你就越能了解各种修改，并使你所在开发组向一个更好的方向前进。如果分配你的工作任务很少而不能提高你的技能，你也应对此满足。如果正在开发有良好市场前景的软件，你所学的一半知识将会在今后三年内过时，如果你不再学习新知识，你将会落伍。 在1988 到200O 年中，美国平均工作人数可增加11到 19，计算机系统分析员可增长53。程序员可增长48，计算机操作员可增长29在现有的1，237，000 份工作的基础上再增加 556，000 份新工作。如果你在工作中学不到什么，你可试着找一份新工作。 实验。了解编程的一个有效途径是对编程和开发过程进行实验，如果你对所用语言的工作过程不甚了解，你可编写一个短程序以检查此特征并看其是如何工作的，你可在调试器中观看程序的执行，你用一个短程序而不是一个不甚了解的大程序来测试一个概念是很好的。 如果短程序的运算表明程序运行结果并不是你所期望的，这时你应怎么办？这正是你所需要的，最好用一个短程序在有效编程的一个关键方法上迅速制造错误，每次你可从中有所收益，制造错误并不是罪过，没有从中学到什么才是罪过。 阅读解决问题的有关方法。解决问题是软件开发中的一个重要活动，Herbert Simon 曾报道过人工解决问题的一系列例子。他们发现人们自己通常不能发现解决问题的方法，即使这种方法很容易学到。这意味着即使你想自己创造车轮，你也不能指望成功，你可能设计出方车轮。 在你行动之前进行分析和计划。你将会发现在分析和行动之前存在着矛盾，有时你不得不放弃的数据和行动，对大多数程序员来说，问题并不在于过分分析和过分使用。 学习成功项目的开发经验。学习编程的一种非常好的方法是向一些优秀程序员学习。Jon Bentley 认为你应静心坐下来，准备一杯白兰地，一枝好雪茄烟，然后如同读小说一样阅读程序。实际上可能并不是这样，许多人往往不愿牺牲其休息时间来阅读500 页的源程序，但是许多人往往乐意研究一个高级程序的设计，并有选择地研究一些具体细节。 软件工程领域很少利用过去成功或失败的例子。如果你对建筑学有所兴趣，你可能会研究Louis Sullivan，Frank Lloyd Wright 和 I.M.Pei的设计图，你也可能会参观他们的建筑物，如果你对结构工程有兴趣，你可以研究 Broolyn大桥，Tacoma Narrows 大桥以及其它混凝土、钢铁和木材建筑，你应研究你所在领域中成功或失败的例子。 Thomas Kuhn 指出，任何成熟的科学，实际上是通过解决问题而发展起来的，而这些问题通常被看作本领域良好工作的例子，并且可用作将来进行工作的例子。软件工程是刚入成熟阶 段的一门科学，在1990年，计算机科学和技术委员会曾指出，在软件工程领域很少有对成功和失败的例子进行研究的文件，在1992年3月的“ACM 通信”中有一篇文章主张对别人编程中出现的问题进行研究，总之，学习别人的编程是有重要意义的。 其中一个最受欢迎的栏目是“编程拾萃”，它专门研究编程过程中出现的问题，这对于我们是有启发的。 你可能有或没有一本研究编程的书，但是你可阅读高级程序员所编写的代码，阅读你所尊敬的程序员的代码，或阅读你并不喜欢的程序员的代码，再将他们的代码和你自己的代码比较。它们之间有何异同？为什么会有差异？哪一个更好？为什么？ 除了阅读他人的代码之外，你也应让其它高水平程序员评价你的代码质量，找一些较高水平的程序员评论你的代码，从他们评论中，你可剔除那些带个人色彩的东西而着重于那些重要的东西。这样可提高你的编程质量。 阅读手册。手册恐惧症在程序员中很流行。一般来说，手册的编写和组织都不好，但是程序员对手册的恐惧很大关系。手册含有一些重要的东西。所以花费时间阅读手册是值得的，忽视手册中的信息正如忽视一些常见的首字母简略词。 现代语言产品一般都带有大量程序库，这时，你花费时间查阅参考手册是值得的，通常提供语言产品的公司，已经编写了许多你可以调用的子程序。如果是这样，你应弄懂有关手册，每隔一段时间阅读一下手册。 阅读有关书籍和期刊。你已经学到了软件工程的许多知识，因为一本书每年都要被许多程序员所阅读，读一些东西可能使你的专业知识向前迈进一步，如果你每二个月阅读一本好的计算机书籍，你的知识将会大大提高并能在同行中脱颖而出。 诚 实 编程生涯成熟的部分标志是不折不挠地坚持诚实，诚实通常表现在以下几个方面： 不假装你是一个编程能手 乐于承认自己的错误 力图理解编译器警告信息而不是对其置之不理 对你的程序有一个清晰的了解，而不是进行编译看其是否有错 提供实际状态报告 提供实际方案评估，在你的上司面前坚持自己的意见 前二个方面承认你不知道一些事情或承认你犯了一个错误是你谦虚的反映。如果你不懂装懂你又怎么能指望学到新东西呢？你最好是假装自己知之甚少，听别人的解释，向他们学习新的东西，并评估他们是否真正了解其正在谈论的东西。 你应对自己的能力作某种程度的估计，如果你对自己的评价很完美，这可是一个不妙的信号。 拒绝承认错误是一个令人讨厌的习惯，如果sally 拒绝承认错误，她看起来相信自己没有错，可能会使其它人相信她确实是无辜的，但是事实证明sally 出错误了，这样，每个人都知道她犯了错误。错误正如潮流一样是一种复杂的活动，如果她在过去没有发生过错误，谁也不 会将错误归咎于她。 如果她拒绝承认错误，到头来她只能自食其果。其它人都知道他们在同一个不诚实的人工作。这比仅犯一个错误更令人反感。如果你犯了一个错误，你应迅速主动地承认错误。 对编译器错误信息不懂装懂是另外一个常见错误。如果你不理解某一编译警告信息或你认为时间太紧迫来不及检查，你想想这是不是真正浪费时间？编译器将问题明白无误地向你展示出来，而你却不试图解决问题，我碰到过不少人在调试过程中请求帮助的事，我问他们是否有一个完好的编译器，他们回答是。于是开始解释问题的症状，我说：“这看起来像是未对指针进行初始比。但是编译器应对此给出了警告信息。”他们就说：“哦，编译器确实给出了警告信息，我们以为它是指其它事情。”你自己所出的错误难以蒙蔽别人，也更难以愚弄计算机，所以你用不着浪费时间这样作。 另外一种疏忽是当你并不完全了解程序时，你“编译它看是否能运行”。在这种条件下，其实并不意味着程序能运行，因为连你自己都不清楚程序的有关情况。请记住，测试仅能发现错误的存在，而不能保证一定不存在某种错误。如果你不理解程序，你就不能进行深入的测试，你如果觉得应编译一下程序以便了解程序的运算情况的话，这可是一个不妙的信号，这可能意味着你不清楚在干些什么。在将你的程序编译之前你应对其有一个深刻的理解。 状态报告也同样是一个令人反感的领域。如果程序员在最后50的项目时说，程序中 90是完整可靠的，他们将声名狼藉。问题在于你对自己的进度缺乏了解，你应对你的工作加强了解。但是，你为了迎奉上司而不愿说出真实情况的话，可就不同了。一般来说上司都愿意听到对项目状态的真实报告，即使不是他们所希望听到的，如果你的观察和见解是中肯的，你应客观地将其说出来，上司需要有准确的信息以便协调各种开发活动，而充分的合作是必需的。 和不准确的状态报告有关的一个问题是不正确的估计。典型的情况是这样：上司问Bert要花多少时间才能开发出一个新的数据库产品。Bert 和一些程序员交谈了一下，讨论了一些问题，最后认为需8 个程序员和6个月的时间，但是他的上司说：“这并不是我们所需要的，你能不能使用较少的程序员在短时间内完成工作？”Bert 考虑了一段时间，并认为可以通过削减培训时间和假期以及让每个人的工作时间稍微延长一点来达到上司的要求。他于是作出了需6 个程序员和4个月时间的估计，他的上司说：“这就行了。这是一个相对较为低优先级的项目。你应及时完成它，因为预算不允许你超时。”Bert 所犯错误在于，他没有认识到评估是不可商量的，他可以将估计作得更为准确，但是他和老板的商量结果并不能改变开发一个项目所需的时间。 IBM 公司的 Bill Weimer 说；“我们发现技术人员一般都能准确地估计项目。问题在于他们能否坚持自己的决定；他们需要学会坚持自己的意见。”Bert 许诺在4 个月里交付产品而实际上6 个月才交付产品，肯定会使他的老板不高兴的。时间一长，他可能会因妥协而失去信任的。否则，他会因坚持自己的估计而得到尊敬的。 如果上司施加压力要改变你的估计，你应认识到决定要怎样作是上司职权范围内的事。你可以说：“看，这是项目的开销，我无法说此开支对本公司是否值得这是你的工作。我不能和你商量”项目所花的时间，这正如我们不能协商确定一里究竟有多少英尺一样这是不可变更的。你不能商定自然界的规律，我们只能商定本项目中影响进度的各方面，然后重新评估。我们能减少一些特征，降低性能，分阶段开发项目。或者是使用更少的人但时间延长一点，或者是使用稍多的人，而相应地减少一些时间。” 我曾在一次软件开发管理讨论会上听到一个奇怪的说法。主讲者是一本销售很好的软件工程管理书籍的作者。一听众问：“你的上司让你评估某一项目，你知道当你得出准确的评估时你的上司可能认为代价太高而放弃项目开发。这时你认为应怎么办？”主讲者回答说，你说服你的上司作出开发项目的决定时，他们就对整个情况了如指掌了。 这是一个错误的回答。你的上司是负责整个公司的运转的。如果开发某一软件需10O000美元而你的估计是200000美元，你的公司就不会开发软件。这是要由上司作出决定的。上面这位主讲者对项目的开支说假话，告诉上司将比实际的要少，他这是在损害上司的权威，如果你认为项目是有前途的，它能为公司带来新的重大突破，或能提供有价值的培训，你应将其说出来。你的上司也会考虑这些因素的。你哄骗上司作出错误的决定将会使公司蒙受损失。如果你失去了你的工作，你将会明白你最终得到了什么。 交流和合作 真正优秀的程序员应学会怎样和别人工作和娱乐，编写可读代码是对程序员作为组中一员的要求之一。 计算机也就同其它人一样能读懂你的代码，但是它要比其它人更能阅读质量差的代码。作为可读性原则，你应将修改你的代码的人时刻记在心上。开发程序首先应同程序员交流，其次则是和计算机交流。 绝大多数高水平程序员喜欢使自己程序的可读性强，并抽出充足的时间这样作。虽然只有一些人能坚持到底，而且其中一些人还是高水平的代码编写者，对开发中程序员级别的了解，有助于解释什么地方适合于此原则： 级别1：初学者： 初学者是能使用一种语言基本能力的程序员，这样的人能够使用子程序、循环、条件语句和其它许多语言特征。 级别2：中间者 中间级程序员有使用多种语言的能力，并且至少非常熟悉某一种语言。 级别3：专家 编程专家对其语言或环境或对这二者有着很深的造诣，这种级别的程序员对公司有价值的，而且有些程序员往往就停留在这个水平上。 级别4：大师 大师有着专家那样的专业知识，并能意识到编程只是15和计算机交流，其余85是和人打交道。一般程序员只有30的时间甚至更少。大师所编写的代码与其说是给计算机看倒不如说是给人看的。真正的大师级程序员所编写的代码是十分清晰易懂的，而且他们注意建立有关文档。他们也不想浪费其精力去重建本来用一句注释就能说清楚的代码段的逻辑结构。 一位不强调可读性的高水平代码者可能停留在级别3 的水平上，但是问题还不止此。依作者本人的经验，人们编写不可读代码的主要原因在于他们所编代码质量较差。他们并不是自言自语地说：“我所编代码不好，所以我要使其难以读懂”，而是他们并不能完整地理解自己的代码以致于不能使其是可读的，这就使他们只能停留在1 或2 级的水平上。我所见的最差的代码是由一个任何人看了她的程序后都会望而生畏的人所编写的。最终，她的上司威胁说如她再不 改正就要解雇她。她的代码是不作注释的，并且其程序中充满了如x，xx，xxx，xx1 和xx2 这样的全局变量。她的代码给了她大量的机会显示她的改错能力。 你不必为自己是初学者或中间者而内疚，你同样不必为自己是专家而不是大师自愧，在你知道怎样提高自己的水平后，你倒是应为自己停留在初学者或专家的水平上有多长时间而内疚。 创造力和纪律 当我走出校门时，我自认为是世界上最好的程序员。我会编辑令人容忍的井字游戏程序，也能用5种不同的计算机语言编写一个1000行的WORKED程序。然后我进了Real World 公司。我在Real World 公司的第一个任务是阅读和理解一个200000行的Fortran程序，然后我使其运行速度提高了2 倍。任何真正的程序员将会告诉你所有结构化编码将无助于你解决问题。“Real Programmers Dont write Pascal” 向一位刚走出校门的计算机科学毕业生解释为何需要约定和工程纪律是困难的。当我还是一个大学生的时候，我所编写的最大的代码是5O0 行的可执行代码，作为一个专业程序员，我也已编写了许多小于500行的实用工具，但是一般项目的长度为5000到25000 行，并且我参加过超过50万行的项目的开发工作，这种类型的工作不是需要较高的技巧，也不需要使用新的技巧。虽然一些有创造性的程序员将各种标准和约定视为对其创造力的阻碍，但是，对大项目来说，如果没有标准和约定，项目的实现是不可能的，而此时要发挥创造性也是不可能的。不要在一些无关紧要的领域建立约定，这样你就可在你认为值得的地方集中发挥你的创造力。 McGarry 和 Pajerski 在对美国宇航局的软件工程实验室过去15 年的工作回顾中说，强调纪律的方法和工具是非常有效的。许多有很高创造力的人都能很好地遵守纪律，高水平的建筑师在材料的物理性能、时间和代价的限定范围内进行工作，艺术家同样如此，许多看过Lenoard的设计的人，都为他在细节上对约定的遵守产生由衷的敬重。当Michelangelo 设计天花板时，使用了各种均衡的几何形式如三角形、圆周和正方形，他按一定层次将以上三种图形安排在三个区域，如果没有自我约束和结构，这300 个人物的排列将是混乱的而不是有机地结合在一起的艺术杰作。 一个杰出的程序员需要遵守许多规则。如果你在开始编码之前不分析需求就进行设计，你将在编码过程中学不到关于项目的许多东西，你工作的结果看起来更像一个三岁小孩的手指画，而不是一件艺术作品。 懒惰 懒惰表面形式有以下几种：拖延自己讨厌的工作 迅速地将自己讨厌的任务作完以摆脱任务 编写一工具来完成自己讨厌的工作以解脱自己 当然，有一些懒惰形式要比其它方式好一些。第一种方式是没有任何益处的。你可能有这样的体会：你常常花费几小时来作一些没必要作的工作，而不愿面对自己所无法避免的次要的 工作，我讨厌数据输入，但是许多程序需要少量的数据输入。别人都知道我已拖延了数天的工作仅因为为了拖延无法摆脱的用手工输入几个数据的任务，这种习惯是“真正的懒惰”，你编译某一子程序以检查有关情况，这样你可以避免人工检查程序同样也是一种懒惰行为。 这些小任务并不像看起来那样令人反感，如果你养成马上完成这些任务的习惯你就能克服拖延这种懒惰。这种习惯叫“明懒惰”懒惰的第二种方式，你仍然是懒惰，但是你是通过在自己所讨厌问题上花费尽量少的时间来避开问题的。 第三种选择是编写工具来作这令人讨厌的工作。这是“长期懒惰”。它无疑是懒惰中最有积极性的一种形式，只要你通过编写工具最终节省了时间，通过讨论可知，一定程度的懒惰是有益的。 当你不是透过玻璃看问题的时候，你就看到了懒惰的另一方面。“赶着做”或“努力”并不能发出炫目的光芒。赶着做是一种多余和没有必要的努力。它只是说明你的焦急而不是你进行工作的努力程度，在有效编程中最为重要的思考是人们在思考中往往显得并不忙。如果我和一位看起来一直很忙的程序员一起工作，我将认为他并不是一位好的程序员，因为他并不是在使用对他来说是最有价值的工具和自己的头脑。 不是你想象中那样起作用的性格 “赶着做”并不是唯一的一种看起来可能受敬重而实际上并不起多大作用的性格。 坚持 依赖于环境，“坚持”可能是一笔财富也可能是一种不利条件，和其它许多多义概念一样，对它有不同的解释，这取决于你认为它是一种好的特性或坏的。如果你想将坚持定义为坏的性质，你可能说它是“顽固”，如果你认为是一种好的品格，你可称其为“坚强”或“坚持”。 在大多数情况下，软件开发中的坚持是顽固的意思，在你碰到某段新代码时，你再固执己见并不是什么好事。你应试着用另一个子程序，用另一种编码方法，或返回原来的地方，当某种方法并不起作用时，你应换用另一种方法。 在调试中，当你终于发现一个烦扰你达4 小时之久的错误时，你一定感到非常满意。但是如果你在一段时间通常为15 分钟没有取得任何进展时，你应放弃找错。用你的潜意识去思考问题，尝试用别的方法解决问题，重写全部令人厌烦的代码段。当你的精神有所恢复时重新回到原来的问题上。和计算机错误作斗争是不明智的，你应尽量避免它们。 知道在什么时候放弃是困难的，但是这是你必须面对的一个问题。当你觉得自己受挫折时，你可向自己提出这个问题，你问问自己并不意味着放弃，但可能意味着是对自己的行动设置规范的时候了：“如果我不能用这种方法在30 分钟时间内解决问题，我将用几分钟时间考虑不同的方法，并在下一小时内尝试不同的方法。 经验 软件开发中经验的价值要比其它领域小，这有几种原因。在许多其它领域中，基本知识变化缓慢，以致于10年前毕业的某人所学到的知识在现在仍没有什么变化。而在软件开发中，即使基本的知识也发展迅速，在你以后10 年毕业的某个人可能学到了二倍 于你的有效编程方法，一些老的程序员往往被另眼相看，不是由于他们对某些特定方法缺乏接触，而由于他们在走出校门后对一些闻名的基本编程概念缺乏了解。 在其它领域中，你今天在工作中学到的东西可能对你明天的工作有所帮助，在软件开发中，如果你不改变你在使用从前的编程语言中的思维方式或你在你的旧机器上得出的代码调试方式的习惯，你的经验将不值一文。许多进行软件开发的人往往花费时间准备上一次的战斗而不是下一次，如果你不因时间而作出应变，你的经验与其说是帮助倒不如说是一个阻碍。 除了软件开发中的迅速变化外，人们常从其经验中得出错误的结论，客观地对自己进行检查是困难的，你也可能忽视经验中使你能得出不同结论的重要之处，阅读其它程序员的研究材料是有益的，因为研究材料揭示了其它人的经验它们都经过充分的精炼，你可客观地对其进行检查。 人们也往往荒唐地强调程序员的经验。“我们需要有五年以上C语言编程经验的程序员”就是其中一例，如果一程序员在头一、二年没有学C 语言，第三年学也不会产生很大区别。这种类型的经验和其工作能力没有多大区别。 在程序开发中，知识更新迅速使此领域中“经验”处在一种奇怪的地位上，在其它许多领域，过去有着成功历史的专业人员，往往令人放心，并且因其一串成功的事情而得到尊敬。退步很快的人将很快和潮流格格不入。为了使自己有所价值，你必须紧跟潮流。对年青的、求知欲旺盛的程序员，他们往往在这点上有优势，而有些老的程序员认为自己有所资格了而讨厌一年接一年都要证实自己的能力。 最后一个问题是：如果你已工作了10 年，你得到了10 年的经验应当是真正的经验，你如能坚持不断地学习，你就能得到经验，如果你并不想学到什么，不管多少年你也学不到什么。 计算机迷 如果你还没有至少在一相同的项目上花费一个月的时间一天工作 16 个小时；为了发现你的程序中最后一个错误睡眠中你也念念不忘它，你接连几天没日没夜地工作即使你所编的程序并不复杂，那么你可能不会意识到编程中有某种令人兴奋的东西。 Edward Yourdon这种对编程的痴迷纯粹是胡闹，并且几乎注定要失败。但是那些通宵程序员使你觉得他们是世界上最好的程序员，但是随后你不得不花费几周的时间来修正你在这短时间的辉煌中所带来的错误，你可能对编程非常热爱，但是你应能冷静地处理这个问题。 习惯 好的习惯起作用是由于你为一个程序员所作的大部分事情是你在无意识中所完成的，例