6. 不断学习 一名社团足球队成员曾经问我，我们每天束紧防滑钉练习，你们“C语言编程的秘密是什么？”如果存在这样的秘密的话，我肯定会在晚间电视节目上宣传如 何靠房地产发财。对不起，没有捷径——你必须学习、练习和犯错。你不一定得依靠团体训练或学校教育——有许多国立的和当地的专业团体、书籍，当然还有网 络。 编程是科学 编程被称作“计算机科学”是有原因的。无需正规的计算机科学教育，任何人都可以轻易地开始编程（可能太容易了）。特别是，那些学过其他工程和理科的 人，可以非常快地上手编程，然后以此谋生。但对于高效地处理重大任务，你必须知道软件的固有功能和限制、识别前提，这样你才不会白费力气地做重复的工作。 你不必知道所有事，但你应该至少粗略地了解许多领域，必要时能做一些额外的研究。 例如，创建了新文件格式的人应该知道一些关于编辑器的事。我不是指所有代码生成的优化如循环展开，而是基本的问题和各种编辑的短语和大部分指定标记和语法的重要性。今天，大多数人会默认地使用XML，那是件好事， 但在那之前，一般是粗略地写一些文本格式，指向一些生成的样本文档作为文件，之后其他写了另一个解析器的人会补上一些在文档中阅读的东西，但不是全部。在出了差错的情况下，你有两种方式推卸责任——要么读者不行，要么作者太差。无论怎么样，更受欢迎的产品会赢。 我对3D图象行业最不能容忍的事情之一是，过多的文件格式不明。当我执行一个3D作品的OBJ文件解析器时，我测试的每份导出作品都生成明显不同的 文件，比如空白和换行不同。与之形成对比的是，我的一个初出茅庐的同事用语法和词法分析器设计了一个新游戏交换格式（现在，这不再是什么大不了的事了—- 大多数新图象文件格式好像都是基于XML的）。 只会将简单的脚本和用户界面放在一起的程序员和可以处理实际问题的程序员，如果说这二者有什么区别的话，那就是对复杂计算的理解能力，如算法怎么影响问题的大小。每一位程序员都应该知道基本的复杂性术语和对常见问题的复杂程度有常识性认识。 我的第一份工作是计算机辅助半导体设计，涉及许多可扩展性的问题，包括一些NP-complete问题（非常难处理）。但是，每次看到在线性时间中 不能解决的问题，和我们自夸可能意味着大部分是线性时间的“线性”算法，有些工程师会兴奋地说：“这是旅行商问题！”（旅行商问题，即TSP是一个有着重 要工程背景、在图论中的典型组合优化问题，已被证实是一个NP完全问题。也就是，如果一个旅行商不得不到几个城市做生意，怎样走最短的路线使他一次到达这 几个城市。） 免费啤酒、自由讨论、免费软件 好吧，其实没有免费啤酒；但现在程序员过得还不错（尽管经济衰退和外包业惹争议）——毕竟你需要的东西网上教程、讨论组上都有，还有免费软件可以用。你要解决的只有硬件和宽带问题。 7. 尊重 高效软件工程师的要求之一是，被认真对待。你必须得到你的同事和老板的尊重，至少出于你的技术能力、对自己的工作有主导权、对他人有一定影响力。 愚蠢问题 真的，这个世界上存在许多愚蠢的问题。提出一个聪明的问题会增加别人对你的尊重，但这是一项技术活。一个揭露未解决的事的好问题会让别人看到你深刻的内涵，你敏锐的思维。要求说明关于技术参数的问题，显示了你阅读和发现问题的能力。 如果你的问题没有得到答案，可能是问题本身有误，所以不要再重复发问了。换一种方式提问，带上更多细节或背景。如果被提问的是你，或花时间回复新手问题的是你，你会感谢上述考虑的。 能与技术支持人员保持良好关系，这是让我对自己都感到骄傲的事。但我确实记得一件往事，那时我抛出一个问题：“几周前提出来的那个问题是怎么回事？”你可以想象别人是多么恼火地回答——“你说的怎么回事是指什么，并且，你说的是什么问题？” 粗鲁无礼是没有回报的，特别是如果你是要求免费指导或咨询讨论组。即使你是在支持协议的保护之下发问，激怒了你的技术顾问对长期合作也会很不利。 我曾经向臭脾气的新人们解释为什么他们的问题有问题或者什么是他们从一开始就做错了的，真是太累人了。现在，我给你快速生效的傻瓜过滤器——“我想知道的只是……”或果断无视。 让所有人知道你读了文件和谷歌搜索了该问题。除了避免回复必然的“RTFM”（RTFM意为：去读该死的指导手册。当你需要信息或者解决问题时，在 请求对方帮助之前，应该花一些时间尝试自己去寻找需要的东西。）和“Google is your friend”，都显示了你做足了功课，那些帮助的人不必搜索相同的资源。如果你确实指望他们为你搜索那些资源，那你的意思就是，你的时间比他们的金贵， 你在谋杀他们的时间。 白痴答案 如果你要表现得你知道自己在说什么，那么你确实应该知道你到底在说什么。工程师的交流有时候更多地是炫耀自己的知识而不是提供信息（如果你也能这么 做，那我向你致敬）。这往往无益于求职面试，面试官其实是假借“发现你是怎么想的”的幌子，向求职者抛出空洞的问题。当然，如果求职者有一点自知之明的 话，也可能产生出乎意料的结果。 有一位技术总监打电话面试我，要我概述C++编辑的结果堆栈框架，并且口头答复他。我一步一步地打草稿，每次我给他正确的答案，他都反过来要我说一个错误的答案，以便我们可以仔细检查为什么那个选择不管用。我不知道我这么写是不是在彰显我有多聪明或他有多聪明。 作为一名工程师，你不能太倚重钱财和长相——信誉才是你的资本。所以如果你犯错了，就坦率承认吧。 我有幸与一名资深工程师共事，他从来不犯错。当他的Java代码在多重处理器系统中崩溃时，原来是出现了大漏洞。当我拿代码指出UI代码不支持多线 程运行时，他坚持说只有一个线程。当我列出代码中的7条线程（我能找出的）时，他同意不应该保留这么多线程，并且最好修改一下。但他还是按老样子编写代码 ——他没有修复任何漏洞，他只是用更多代码掩盖了漏洞。 最后，一个节省时间的建议：不要纠结于愚蠢的争论。愚蠢是会传染的。 |
