软件工程师把大量时间花在练习 LeetCode 问题获得面试技巧和完善简历上。一旦他们最终在一家初创公司、谷歌、亚马逊或其他公司找到工作，他们可能就会发现，他们获得这份工作所需的技能与他们日常工作所需的技能并不匹配。
受 TechLead 高效程序员的七项技能启发，我们团队想就这个话题发表自己的看法。
下面是我们总结的高效程序员的七项技能。
1. 学会如何阅读他人的代码
除了你，所有人写的代码都很糟糕。
这就是为什么能够追踪他人的代码是一项具有多重好处的伟大技能。
不管之前工程师的代码有多么混乱或欠考虑，你仍然需要仔细阅读它。毕竟，这是你的工作。甚至一年前的那个工程师也是你。
这项技能对你有两个好处。第一，能阅读别人的代码让你有一个很好的机会去了解什么是糟糕的设计。当你在浏览别人的代码时，你会了解到什么有用什么没用。更重要的是，你还会了解到，对其他工程师来说，哪种类型的代码比较容易理解哪种代码比较难理解。
在阅读其他人的代码时，你可以尽情地地抱怨。这样，其他工程师就会明白你有多么优秀。
务必要提一下可维护代码和良好注释的重要性。这可以进一步显示出你在编程领域的优势。
你的代码应该设计得非常好，以至于不需要任何文档。事实上，如果你是一名优秀的程序员，就不应该编写任何代码的文档。这只是浪费时间，你需要把时间花在编程和会议上。
能阅读他人编写的混乱代码也使得在需要时更新变得更容易。这有时意味着更新你不了解的代码。例如，我们曾经追踪一个脚本，从 Powershell 到 Python 再到 Perl 。虽然我们在 Perl 方面的经验有限，但我们仍然有足够的上下文来了解发生了什么，并做出所需的更改。
这源于我们很好地理解了所有代码并且能够阅读 Perl 脚本。
阅读别人的代码会提升你的价值，因为你可以追踪那些因为过于复杂而让他人感到困惑的系统。
2. 能够感知糟糕的项目
有很多技能需要花时间去学习。我们相信有一项技能是有必要了解的，那就是知道哪些项目不值得做，哪些项目必然失败。
大公司总是有很多正在进行中的项目，而有些项目可能永远无法完成或产生影响。有一些项目可能没有任何商业意义（至少对你来说没有），还有一些项目管理不善。这并不是说，当你不赞成某个项目的时候，你就应该打断别人的想法。不过，如果涉众不能适当地解释他们将利用最终结果做什么，那么这个项目可能不值得做。
此外，有些项目可能过于关注技术而不是解决方案，因此从一开始就很清楚它不会带来太大的影响。对于这项技能，你需要在做过很多糟糕的项目之后，才能懂得什么样的项目是糟糕项目。所以，不要过早地花太多时间去辨别每个项目。
在你职业生涯的某个时候，你就会有一个很好的直觉了。
3. 少开会
无论你是软件工程师还是数据科学家，会议都是必要的，因为你需要能够与项目经理、最终用户和客户保持一致。然而，会议有时会突然占满你的日程表。这就是为什么懂得如何避免不必要的会议很重要。也许用“管理”这个词比“避免”更好。这里的目标是确保你花在会议上的时间是为了推动决策并帮助你的团队前进。
最常见的方法就是在经常开会的日子里留出两个小时的时间。通常，大多数人会在他们认为有益的时候安排定期会议。他们将利用这段时间来赶上他们的开发工作。
另一种少开会的方法是比其他人早到，这样你就能完成工作。就我个人而言，我喜欢早到，因为总的来说，办公室比较安静。大多数早到的人都和你一样，只是想把工作做完，这样就不会有人打扰你了。
这对个人贡献者来说很重要，因为我们的工作需要我们有时间可以保持专注，不和其他人交谈。是的，有时候你可能想和别人一起解决问题。但是一旦你解决了阻碍你前进的问题，你就只需要编码了。就是说，你需要进入一种状态，你的头脑中不断地保持着许多关于你正在做的工作的复杂想法。如果你不断地停下来，你就很难从停止的地方继续。
4. Github
一些计算机专业的学生从出生那天起就开始使用 GitHub。他们能够理解每一个命令和参数，并且远远超过了专业人士。
有些人则是在第一份工作中首次接触到 GitHub 。对他们来说，Github 令人困惑的命令和流程犹如梦魇。他们从来都无法 100% 确定自己在做什么（这就是速查表受欢迎的原因）。
无论你的公司使用哪种存储库系统，如果使用得当，那么该系统就有帮助；如果使用不当，那么它就会成为障碍。一个不费多少时间的简单推送或提交就可以让你花费几个小时去理清多个分支和复刻（fork）。此外，如果你经常忘记拉取存储库的最新版本，那么你还将处理并不好玩的合并冲突。
如果你需要保存一份 Github 命令速查表，那么这样做就好。只要能让你的生活变得更简单。
5. 编写简洁可维护的代码
年轻工程师可能会倾向于将他们知道的所有东西都在一个解决方案中实现。这种愿望让你把自己对面向对象编程、数据结构、设计模式和新技术的理解全部都用在了每一段代码的编写中。这增加了不必要的复杂性，因为很容易过度依赖于你过去使用过的解决方案或设计模式。
复杂的设计概念和简单的代码之间存在一种平衡。设计模式和面向对象的设计应该从整体上简化代码。不过，一个过程如果抽象、封装和黑盒化程度越高，调试就越困难。
6. 学会说“不”，分清轻重缓急
这适用于任何角色，无论是金融分析师还是软件工程师。但尤其值得一提的是，似乎每个人都需要技术角色提供一些东西。如果你是一名数据工程师，那么你需要做的可能不仅仅是开发管道。一些团队需要数据提取，一些团队则需要仪表板，还有一些团队需要你为他们的数据科学家提供新的管道。
分清轻重缓急和说“不”可能真的是两种不同的技能，但它们紧密地交织在一起。分清轻重缓急意味着你只把时间花在对公司有重大影响的事情上。而说“不”有时候只是意味着避开应该由另一个团队来处理的工作。不管对于什么角色，它们都常常是同时发生的。
这是一项很难掌握的技能，因为你很容易接受别人提出的每一个要求，尤其是如果你刚大学毕业。你想要避免让任何人失望，你总是会获得大量的工作。
在大公司里，总是有无穷无尽的工作要做。关键在于只承担能完成的工作。
有很多技巧没有经过面试检验，甚至在大学里也没有教授过。通常，这更多的是环境限制，而不是不想让学生接触真实开发环境中存在的问题。
7. 面向操作的设计思维
有一项技能在面试中很难检验，在大学里上课时也很难学到，那就是思考最终用户在使用你的软件时可能会犯什么错。我们通常把这个叫做通过操作场景进行思考。
不过，这只是一种礼貌的说法，意思是“你正在设法实现蠢人也不会搞砸的代码”。
例如，由于大多数编程都是维护，所以这通常意味着修改与其他代码混在一起的代码。即使是简单的修改也需要跟踪对象、方法和 / 或 API 的所有可能引用。否则，很容易意外破坏相关的模块。即使只是修改数据库中的数据类型。
这还包括在开发之前考虑边缘情况和整个高层设计。
对于开发新模块或微服务这种更复杂的情况，花时间考虑正在构建的软件的操作场景很重要。考虑未来的用户可能需要如何使用你的新模块，他们在使用它时可能会犯什么错，可能需要哪些参数，以及未来的程序员可能要以不同的方式使用你的代码。
简单的编码和编程只是问题的一部分。创建可以在你的电脑上正常运行的软件很容易。但部署代码出错的方式很多。一旦投入生产，就很难说代码将被如何使用，以及其他哪些代码将附加到原来的代码中。五年后，未来的程序员可能会对代码的限制感到沮丧。
