原文：20 things ive learned in my 20 years as a software engineer
2021 年的文章，不乏闪光点 —— 敢这么说话，我是有点飘了。
老外喜欢总结 5 条、10 条、20 条啥的，和咱八股文里的 1、2、3、4、5 倒是有异曲同工之妙。
接下来是我压缩后的意译。
前人的经验很重要，但几乎所有的建议都有其背景，而背景经常被忽略。Context is really life-and-death.
“多收费就对了！” 说这话的公司在商场沉浮了 20 年，而且花了很多年推行薄利多销政策，获得了客户增长，并成长为一家成功的企业。
“把所有东西都构建为微服务就对了！”说这话的公司靠着一个快速反应的单体起家，在获得成千上万的客户增长后，出现伸缩性问题，而开始转向微服务。
不理解背景，建议就毫无意义，甚至有害无益。如果这些家伙一开始就遵循了自己提出的建议，可能已经自食其果。很难避开这个陷阱。我们也许正处于自己经历的顶峰，但却只能用当下的视角来看待它们。
所以给你一些我的建议产生的背景，我职业生涯的前半段是在各种小商业公司和创业公司，然后进入咨询行业，为大量巨型企业工作。接着创立了 Simple Thread 公司，从 2 个人的小团队发展到 25 个人。10 年前我们主要与中小企业合作，现在我们的合作对象包括了小型和大型企业。
我的建议来自这样一个人，他…
- 几乎总是在小而精益的团队工作，必须用少量的资源来做大量的事。
- 重视工作软件而非特定工具。
- 总是开启新项目，但也必须维护一些现有系统。
- 重视工程师的生产力而非其他。
过去 20 年的经历塑造了我看待软件的视角，并且带给我一些信念，我尽量压缩这些内容为一个可管理的列表，希望你能从中获益。
1、仍然有很多东西不知道
软件的各个方向都有广泛的知识，并且还在与日俱增，两个同样投入了几十年学习软件知识的人，知识结构也可能存在很大鸿沟，早点明白这点，互相学习。
2、软件开发最难的地方在于做出正确的东西
技术和商业价值是两码事。软件可能非常具有技术挑战，但没人用，商业价值为 0。
3、最棒的软件工程师像设计师一样思考
不能仅仅考虑技术层面，还要考虑用户层面——谁会用、为什么会用、会如何用、对用户来说真正在意的是什么。
4、最好的代码是没有代码，或者不需要维护的代码
手里有把锤子，看什么都是钉子。软件工作师的习惯就是写代码，容易去发明不需要的轮子或者重复发明轮子。
5、软件是达到目的其中一种手段
软件工程师的首要工作是产出价值，从这个角度出发重新审视工具，以此为导向可以发现存在多种多样解决问题的方式。
☕在博主看来，现代的制式工作，正使得技术失去了它的神秘、趣味和创造性，实现的过程正退化为一种机械行为，仅存的一点乐趣在于把实现和自我价值观结合起来，这样枯燥的技术实现过程就成为了一种自我实现过程，让人在编码的过程中实现自我，得到一种自我满足。所以，作为技术工程师，也不能一味贬低技术，迁就甚至迎合业务，毕竟卖艺不卖身。
6、有些时候必须停止磨刀，马上开始砍柴
人类只有有限理性，所以在一定时间后就要停止搜集信息，开始着手做，在做的过程中获取反馈，并增进对问题的理解。
7、如果对可能性空间没有很好的理解，就不可能设计出良好的系统
理解在一个给定的系统范围里，什么是可以实现的，很重要。谨防长时间不写任何代码的人来设计系统。
8、所有的系统最终都会腐烂，克服这种恐惧
世界上只有两种语言：一种老是被人吐槽，一种无人问津——架构也一样。还完技术债、设计完美的接口、快速的测试，这些美好的愿望可能永远无法实现。这不是不追求把事情做得更好的借口，只是提供一种态度——放弃对优雅和性能的焦虑，而去追求持续性的优化，打造一个团队乐于参与的活的系统，持续性地输出价值。
9、没有人问了足够多的 “为什么”
抓住任何机会质疑“一直就是这么干”的假设和方法。有新员工进来时，关注他们对什么感到困惑，有什么问题。如果觉得一个功能需求没有任何意义，确认自己理解了目标，以及这个目标是如何转化为这个功能。如果不能给出一个简洁的回答，继续追问自己直到理解。
10、我们应该更关注避开 0.1x 程序员，而非寻找 10x 程序员
10x 程序员是一个愚蠢的神话，基本上是和 0.1x 程序员对比出来的——浪费时间、不反馈、不测试、不考虑边界情况等等。与其寻找 10x 程序员，更应该操心让 0.1x 程序员远离我们的团队。
11、高级程序员区别于初级程序员的地方在于他们对事情应该是怎么样的有自己的一套看法
没有什么比高级程序员对使用的工具或如何构建软件没有观点更让我担忧了。即使给出的观点让我强烈反对，也好过没有任何观点。提升技能的捷径就是找出其他人是如何用不同的工具和技术完成同样的工作。
12、人们并不真的想要创新
人们喜欢高谈阔论创新，但他们通常想要的是廉价的胜利和新奇感。如果你真的有了创新，并且改变了他们习以为常的行为模式，必然遭致负面批评。如果坚信自己的所作所为，知道肯定能真正地改善事情，那就做好打持久战的准备。
13、数据是系统里最重要的部分
很多系统保障数据完整性的主要机制是靠老天保佑。任何在关键路径上的突发情形都会制造出不完整的或者脏的数据，从而成为以后的噩梦。数据比代码活得更长，从长远考虑，值得花费精力保持有序和干净。
14、寻找技术鲨鱼
盘旋在四周的老技术是鲨鱼，而非恐龙。因为能很好地解决问题，所以在快速变迁的技术世界中存活了下来。这些技术没那么酷炫，但能搞定任务，而不用搭上若干不眠之夜。
15、不要把谦虚误认为无知
很多软件工程师的作风是，你不问他，他就不会反馈。不要认为没有把反馈意见摔到你面前，就代表他没有对你有益的东西。有时候，嚷嚷得最厉害的人恰恰是我们最少听取意见的人。和周围人聊聊，听取他们的反馈和建议，你会为此感到庆幸的。
16、软件工程师应该定期写作
软件工程师应该定期做任何能磨练写作能力的事，如写博客、杂志、文档等。写下来有助于厘清问题、和团队保持有效沟通、和未来的自己沟通。写作能力是任何软件工程师都应该掌握的核心技能。
17、保持流程尽可能的精简
最近大家都一窝蜂地搞敏捷，但敏捷应该是小块构建、学习、迭代。如果敏捷不是指向这个，那只是在兜售东西。保持流程精简，直到感觉需要改进。
18、软件工程师和所有人一样，需要感到自己是事情的主人翁
如果把人们的工作和其产出分离，人们对工作就不会那么上心。这是跨职能团队运作良好和 DevOps 流行的主要原因。这无关于部门墙和低效率，而是关于掌握整个流程，从发起到结束，并直接对产出负责。让具有热忱的团队拥有完整的控制权去设计、构建、发布，然后惊人的事情就自然发生了。
19、面试基本上不能告诉你某人能成为团队里多好的成员
面试更适合用来了解某人是谁，对给定的专业领域有多感兴趣。而如果想要用来弄清楚他会成为一个多好的团队成员则注定徒劳。一个人有多聪明或者知识渊博，不能作为能否成为很棒的团队成员的指示器。没人会在面试时说自己的坏话，而总是会给出一些积极正面的信号。
20、总是努力去构建一个更小的系统
有很多力量会推动你去构建一个很大的系统。预算分配、无法砍掉需求、发布最佳版本的愿望。这些力量如此强大，你需要和它们抗争。在构建系统的过程中，你会学到非常多的东西，从而结束迭代，得到一个比最开始的设计更好的系统。令人惊讶的是，这对很多人来说，很难。
0 条评论