作者 | Justin Etheredge
务必警惕那些已经很久没写过代码、也没设计过系统的所谓“大牛”。
站在巨人的肩膀上当然更容易成功，所以我们才会希望行业前辈能给出一些有意义的建议。今天这些建议来自一位有二十年行业经验的软件工程师，他的总结在 Hacker News 上引发了大量的讨论，帖子多天来一直占据“热榜”第一。
Justin Etheredge 最初在各类小型和初创企业中担任软件工程师，之后进入了咨询行业并开始为大型企业服务。Justin Etheredge 表示过去二十年以来的经历塑造了他对于软件的理解，并产生出一些坚定的信念。他把这些信念整理成一份明确的清单，希望能为大家带来一点帮助与启发。
引起网友激烈讨论的二十条建议：
1. 我懂的并不多
“你怎么会不知道什么是 BGP？”“你难道没听说过 Rust？”
类似的问题可能每天都会出现在我们面前。没错，投身于软件行业的很多人之所以热爱这份工作，就是因为它敦促着我们终身学习。
在软件领域，无论我们朝哪个方向前进，都有着广阔的知识空间不断延伸而且每一天都有所变化。换句话说，这是一份能够承载我们度过几十年的职业生涯，而两位在类似岗位上分别工作了几十年的人之间也 很可能存在巨大的知识差距 。我们越早意识到这一点，就能越快摆脱“冒充者综合症”，成为一个乐于向他人学习、也乐于教导他人的积极分子。
2. 软件里最难的部分，是构建正确的东西
我知道这种话大家肯定听过无数遍了，但大多数软件工程师仍拒不承认，理由是这种说法似乎在贬低他们的工作成果。我个人觉得这样的心态大可不必，这类表达其实是在突出软件开发环境中的复杂性与非理性因素，而这些都会加剧我们面临的挑战。我们当然可以设计出在技术上最令人印象深刻的东西，但却没人愿意用——这类困境随时都会出现。
软件设计主要是一种聆听活动，开发者往往身兼软件工程师、通灵师乃至人类学家等多重角色。而我们对这种设计能力的每一点投资，无论是引入专业的用户体验师还是接受更进一步的自我教育，都能给开发成果带来巨大提升。毕竟与打磨设计能力相比，开发一款“没人用”的软件成本还是太高了、太高太高。
3. 顶尖软件工程师会像设计师那样思考
伟大的软件工程师会深入思考代码成果的用户体验。虽然使用的术语或者切入点不同，但无论是对于外部 API、编程 API、用户界面、协议还是其他接口，优秀的工程师都会考虑由谁来使用、为什么要使用、如何使用以及对用户来说哪些因素真正重要等。总之，牢记用户需求才是实现良好体验的核心所在。
4. 最好的代码就是没有代码，或者说不需要维护的代码
“程序员就是管编程的”，而且跟其他专业人士一样，我们也会在自己最擅长的方面犯错。这是人的本性，没办法。大多数软件工程师编写出的代码总是有点错误，而且往往无法用非技术方案来解决。
另外有一种很神奇的现象，越是有大量相当成熟的解决方案存在，工程团队就越是想“重新发明轮子” 。想表达自我、加快专业成长当然是好事，但还请大家分清场合与需求，过度泛滥的发明欲望恐怕不利于编写出无需维护的代码。
5. 软件是达成目的的手段
任何一位软件工程师的主要工作都是交付价值。但我发现大部分软件开发者并不理解这一点，能够将这个理念内化进日常工作的开发者就更少了。但只要能够完成内化，我们解决问题的方式、看待工具的角度都会有所变化。如果您真心相信软件要服从于结果，那就一定能找到“真正适合工作的工具”，而这种工具也许压根就不是软件。
6. 有时候，你压根没时间磨刀
都说“磨刀不误砍柴工”，但刀磨久了反而让人心浮气躁、难以投入真正的工作。代码编写也是一样，研究多了容易让人陷入“分析瘫痪”。
一旦出现这种状况，请马上给自己设定一个截止日期，之后再探索解决方案。在着手解决问题时，我们很快就能找到思路与线索、引导自己一步步迭代向更好的产出。
7. 如果没法理解所有可能性，就设计不出优秀的系统
这也是我个人一直在努力解决的问题。我的职责变化导致自己距离常规软件工程任务越来越远，我发现跟上开发者生态的发展速度越来越难，有时候自己甚至不理解哪些趋势真正重要。总之，如果不能理解特定生态当中的那些可行性与可用选项，那么我们根本没办法为所有问题找到合理的解决方案。
总而言之，务必警惕那些已经很久没写过代码、也没设计过系统的所谓“大牛” 。
8. 每套系统最终都很差劲，要勇于接受这一点
Bjarne Stroustrup 有句名言，“世界上只有两种语言，人们抱怨的语言和没人用的语言。”大型系统也是同理。并不存在“正确”的架构，我们永远无法偿还所有技术债务、设计不出完美的界面、也不可能永远拥有迅如闪电的测试速度。但做不到不代表什么都不做，这只是一种参考视角。优雅和完美本身就是种终极目标，我们当下的任务就是不断改进并创造一个更友好的系统环境，保证团队至少还用得下去、并以可持续的方式交付价值。
9. 通于探索，不断追问
相信大家都听过“我们向来这么处理”之类的鬼话。这时候请关注那些新加入的成员，看看他们在哪里遇到了问题、又提出了哪些质疑。这些质疑中，是否存在某种有意义的功能诉求？请保证您明确理解他们提出的目标，以及驱动这种功能诉求的原因。如果得不到明确答案，就不断追问下去、直到弄明白为止。
10. 相比于寻找 10 倍程序员，最好是消除 0.1 倍程序员
10 倍程序员就是个愚蠢的笑话。
没有任何一个人能在一天之内搞定另一位同样有能力、工作态度端正而且经验丰富的程序员需要两个礼拜才能做完的工作。我只见过 10 倍代码量程序员，他们写出来的 bug 也是 10 倍。或者说，10 倍程序员唯一的存在可能性，就是身边有个 0.1 倍程序员——就是那种浪费时间、不关注反馈、不测试代码也不考虑极端情况的家伙……所以相较于寻找神话中的 10 倍程序员，及时清除团队中的 0.1 倍程序员才是正道。
11. 高级工程师与初级工程师间的最大区别之一，在于二者形成意见的具体方式
如果某位高级工程师对现有工具或者软件构建流程没有任何意见，那我实在是感觉不太正常。我宁愿有人能反馈出强烈的批评意见，也不愿他们压根没有任何意见。只要正在实际使用工具，那大家或多或少会有正面或者负面的批价；对其他语言、库和范式的应用也是类似的情况。而这种对于工具及技术的评判与探索，往往可以快速提升我们的技能水平。
12. 人们并不真正想要创新
人们经常讨论创新，但实际想要的只是更廉价的胜利与新鲜感。如果真正进行创新、改变人们处理工作的方式，那么对方大概率会给出负面反馈。但如果您真的相信自己的决定代表未来、相信这一切能改善产出，那请做好打一场持久战、拉锯战的准备。
13. 数据是系统当中最重要的组成部分
我见过很多以数据完整性作为主要保障目标的系统。但在这类系统中，任何预期范围之外的操作都会产生某些“脏”数据，它们会在后续处理中演变为一场噩梦。
请记住，数据的存在周期往往比代码库更长 ，所以请花点精力保持数据的清洁和有序。从长远来看，这种好习惯必然带来高回报。
14. 寻找技术“鲨鱼”
所谓技术“鲨鱼”，就是那些长久存在、能够有效解决问题，所以可以在技术领域的快速变化中幸存下来的技术方案。注意，它们是鲨鱼、不是恐龙，所以除非有充分的理由，否则千万不要轻易更换。这些工具没什么特别、也不激动人心，但它们总是稳定有效，能让人睡个好觉。
15. 不要把谦虚当成无知
很多软件工程师不爱主动说话，除非问题被推到面前。所以，千万别以为别人没发言就是大家没意见。有时候，最吵闹的家伙反而是我们最不想倾听的对象。总之，积极与其他人交谈，寻求他们的反馈与建议。这招回报很高，一试就灵。
16. 软件工程师应该保持写作的习惯
软件工程师应该定期写点博客、日记和说明文档，或者其他能够保持自己书面沟通技巧的东西。写作能帮助我们思考问题，也能培养起我们与团队甚至是未来的自己良好沟通的能力。良好的书面沟通可以说是每一位软件工程师都必须掌握的重要技能之一。
17. 让流程尽可能精简
时至今日，每个人都在说“敏捷”，但敏捷的本质并不复杂——构建小小的单元块、从中学习、再迭代。如果有人把它弄得更晦涩，那恐怕就是想夹带私货。
换句话说，那些最成功的科技企业或者大型开源项目不会过度吹嘘自己的 Scrum 流程有多棒。大道至简，精益才是成功的关键。相信你的团队，他们也会用产出回应你的信任。
18. 软件工程师也是人，也需要找到当家作主的感觉
如果硬要把某人跟他的工作成果分开，那他们也就不关心自己在干什么了。也正因为如此，跨职能团队以及 DevOps 理念才在当下获得广泛认同。这不只是要消除无谓的交接与低效率环节，更重要的是让每个人从头到尾拥有整个流程，并负责直接交付价值。只要让一群充满激情的工作者完全掌握软件设计、构建与交付的所有权，他们一定会拿出令人兴奋的成果。
19. 面试在反映开发者水平方面几乎毫无价值
面试的最大作用就是了解对方，主要是对方对于特定专业领域抱有多大的兴趣。另一方面，面试在反映开发者技术水平方面几乎毫无价值 。相信我，无论一个人多聪明、多博学，都不代表对方就真的适合我们的团队。没人会在面试中坦言自己不太可靠、暴躁易怒、自负自大或者从来不准时出席会议。为了拿到工作，每个人都或多或少要粉饰一下自己，而那些能在原则问题上坚持立场的人反而值得尊敬。“永远不要雇用那些在面试中询问休息时间的人”，这种鬼话就是纯纯的放屁！
20. 始终坚持从小处着眼
在系统开发当中，种种因素似乎都在推动我们构建起更大的体系。预算分配、难以取舍的功能方案、一举打造“最佳版本”的愿望等等，都会让刚刚起步的项目快速变得臃肿不堪。请千万克服自己的冲动，努力通过迭代让系统从最初的简单粗糙变得精致优雅。而且跟很多朋友想象中不同，这也是打造精致优雅系统的唯一方法。
参考链接：
