本文是来自一位国外资深程序员托马斯·阿科米工作数年的几点感悟。一篇很有趣也很真实的文章，颇有感触，也希望能够帮到你。（外文链接）

1、与人交谈比与机器交谈更重要

编程是一项团队运动!

现在早已不是那个一把刀闯天下的年代了，更多是需要多元化技术团队的整合，才能够创造出一个出色的产品。

沟通技巧可以成就一个项目，也可能会毁了它。相比存粹的技术，软技能对一个项目的成功起到更重要的作用。我们需要学习如何与不同的人有效地交流我们的想法和思想，以解决我们（作为一个团队）面临的问题。

试想一下，你把世界上最好的 5 个数据库专家都请来了，但如果他们各自为政，互不沟通，最后他们只会给你搞出 5 个不同的 MySQL、Aurora 或 MongoDB 实例。

2、了解你在做什么以及为什么这么做

人一旦有了明确目标，效率和主动性会明显提高，就像我每每深夜读完鸡汤文，我就睡不着。其实，在工作中也是一样的。

作为软件开发人员，你的目标不应该只是把 JIRA 转换成 JavaScript，或者把 Github 中的项目变成 Java。

你的目标应该是用代码来解决问题。

如果你对要构建/维护的系统有深刻的了解，则可以在纯技术之外做出决策。这个功能是必需的吗？它解决了什么问题？可以用其他方式来解决这个问题吗？真的有必要解决这个问题吗？说真的，有时解决该问题甚至不需要任何代码。

这种思路有时被称之为业务环境，如果你想把工作做好，不仅应该了解环境，还应该能够塑造和影响环境。即使你在公司里不是Leader，也不影响你这么做，至少，你要明白自己在做什么。

好家伙，代码审查。

虽然没有必要那么想，但把自己写的代码放出来让其他人围观评论，这种体验跟写代码还真是有点不一样，也难怪人们会感到焦虑。

我亲自看到有人在X不在办公室或Y出差时提交代码审查，X是位出色的程序员，但对他的审查过程很多人都受够了。试想，如果你在一个新手的 PR 底下轰炸式地给出数十条不那么友好的评论，你其实不只是在证明自己作为一名高级程序员的优越感，也是在证明你不是一个“好人”。

那么，当我看到功能有很大漏洞时，该怎么办？

你可以私底下找那个人，跟他好好聊聊，问他为什么把代码写成那样。

其实大多数人也不想把代码写臭，如果你看到臭代码，他们也可能正在处理你不知道的问题。当然，也有可能是因为他们的编程技能还不够好，这个时候你要承担起导师的角色，给他们提供一些指导。

墨菲定律：会出错的事情就一定会出错。

这是太真实的事情之一。设计系统时，请始终假定某些东西可能会损坏。

比如登录表单，请假设人们会将整本书复制并粘贴到“密码”字段中。

如果要构建所见即所得的窗口，请假设有人会尝试搞破坏，并且他们很可能会成功。

如果系统中使用了数据库，它一定会在某个时刻挂掉。如果你没有尝试使用备份来恢复数据库，那它们就算不上是备份。

如果你在给客户做演示，请确保这个演示在任何情况下都能正常进行，哪怕把它翻个底朝天，甚至是把它丢到水底下。

我们曾如此渴望命运的波澜，到最后才发现：人生最曼妙的风景，竟是内心的淡定与从容……我们曾如此期盼外界的认可，到最后才知道：世界是自己的，与他人毫无关系。 – 《一百岁感言》杨绛

这里用杨绛先生的话来当引子，作为一位工作多年的资深程序员，当别人问一些我不懂的问题时，我可以很淡然地告诉他们：这个东西我也不懂，因为以前没有遇到过，不过我可以看一下，然后再告诉你。

当我还是一个初级程序员的时候，我总是很害怕别人会看到我的无知。经过几年的磨练，我才明白，如果碰到了自己不懂的东西，说明学习的机会来了。终身学习绝对不只是一个“口头禅”，而是现实。

等你把不懂的东西搞懂了，记得把它们分享出来。写一篇博客，录个教学视频，或者在公司里搞个分享演讲……你不要认为你刚学会的东西别人也都懂，即使是一个非常资深的人，他们也能从初级人员身上学到东西，反过来也是。

分享的过程其实是一个检验你是否真正理解所学的东西的过程。有句话说得好：当你在教一个人的时候，其实有两个人在学。

记得早先在一个问答中问到：

你的编程能力从什么时候开始突飞猛进的?

有个回答我印象很深，说：突飞猛进往往是自然发生的。你在某个夜晚苦熬一个知识点时，不会觉得自己突飞猛进；只有在多年后某日熟练地给别人讲解这个知识点后，内心才会小小地波动一下，猛然忆起当年深夜中的青灯一盏。

共勉。