七年开发者经验教训

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

深刻理解你正在构建什么以及为什么构建

如果你的团队进行代码审查是一件让人感到压力很大的事，那你的做法就太糟糕了。

肯定会出问题，做好准备

不要害怕说“我不知道”

在公共场合学习

开始之前，我正在开发https://cloudash.dev，这是一种监控无服务器应用的全新方式🚀。如果你在调试生产事件时厌倦了在 50 个 CloudWatch 选项卡之间切换，可以看看这个。

时间过得真快，不是吗？

我的编程之旅始于2012年，那是我第一次从事C++实习。坦白说，我当时完全不知道自己在做什么（这一点至今依然没有改变）。不过，一路走来，我还是学到了一些经验。

免责声明：本篇文章中不会包含任何代码。

问题：编程中最重要的语言是什么？

这是英语。

或者西班牙语。

或者中文。

或者波兰语。

或者您在工作中用来与其他人交流的任何东西。

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

编程是一项团队运动。偶尔你可能会看到一个人从零开始开发出一款出色的产品，但绝大多数情况下，你需要一个团队。

沟通能力可以成就一个项目，也可以毁掉一个项目。别担心，不仅仅是你和你的团队，NASA 也面临着同样的困境。

柔软的专业技能对项目成功的影响可能比纯粹的技术技能更重要。如果你雇佣了 5 位世界上最优秀的数据库专家，但他们之间却互不沟通，最终你得到的只是 MySQL、Aurora 和 MongoDB 的 5 个不同实例，那谁会在乎呢？

深刻理解你正在构建什么以及为什么构建

大多数人有目标的时候会更快乐。这同样适用于工作。

作为软件开发人员，您的目标不是将 JIRA 转换为 JavaScript、将 Trello 转换为 C# 等。

您的目标是用代码解决问题。

如果你对正在构建/维护的系统有深入的理解，那么你就可以做出超越纯技术层面的决策。这个功能真的有必要吗？它解决了什么问题？我们能用其他方法解决这个问题吗？我们一开始就想解决这个问题吗？

这种思维方式有时被称为“业务背景”，但如果你想做好你的工作，你不仅应该了解业务背景，还应该能够塑造和影响它。你不必在组织中担任高管才能影响你的产品。或者至少——理解它。

如果你的团队进行代码审查是一件让人感到压力很大的事，那你的做法就太糟糕了。

哦天哪！代码审查。

我们真的没想过这个问题，但把作品公之于众，并接受众多人的评论，这种行为在我们这个行业里还是挺独特的。难怪大家会对整个过程感到焦虑。

我亲眼见过有人在 X 不在办公室或 Y 出差时提交代码审查。X 是一位出色的程序员，但忍受他的代码审查过程却是一件苦差事。如果你在一个初级程序员的 PR 下留下 50 条吹毛求疵（这个词有用吗？）且不友善的评论，那你根本无法证明自己作为开发人员的优秀，反而会证明你不是一个好人。

好的，但是当我发现这个功能完全损坏时我该怎么办？

站起来。私下联系那个人。和他们谈谈，了解他们为什么以这种方式实现该代码。

大多数人都不想写出糟糕的代码。如果他们真的这么做了，那很可能是因为他们遇到了你不知道的限制。他们可能（目前）还不擅长编程，而这正是你作为导师展现才华的机会。

肯定会出问题，做好准备

根据维基百科：

墨菲定律是一句格言或警句，通常表述为：“凡是可能出错的事情，就一定会出错”。

这是千真万确的事情之一。在设计系统时，一定要假设某些东西可能会出问题。

如果您正在构建登录表单，请假设人们会将整本书复制并粘贴到密码字段中。

如果您正在构建一个所见即所得的窗口，假设有人会试图破坏它，而且他们很可能会成功。

如果你有一个数据库，它迟早会宕机。如果你还没有测试过如何从备份中恢复数据库，那么它就不能算作备份。

如果您在观众面前进行现场演示 - 请确保演示可以在线、离线、倒置和水下进行。

不要害怕说“我不知道”

我的职位旁边有一位资深人士，最好的一点是，我终于可以回答这样的问题了：

我不知道，从来没试过。我去看看，然后再回复你。

当我还是一名初级开发人员时，我非常害怕有人发现我是个骗子。做了几年开发人员之后，如果我没见过什么东西，那可能是因为到现在为止它还不适用。或者我只是又有一项很酷的技术需要学习。终身学习在软件开发领域并非一个流行词，而是现实。

或者我只是个骗子，骗得大家以为我能做好我的工作。谁知道呢。

在公共场合学习

一旦你从“我不知道”变成“好吧，这很有趣”——就和别人分享一下。写一篇博文，录制一段视频，在公司知识分享活动上发表演讲，或者只是……告诉别人。如果你认为某件事对每个人来说都是显而易见的，那就错了。即使是最资深的人也能从初学者身上学到一些东西，反之亦然。

教学是确保你真正理解相关主题的一种不可思议的方法。

俗话说：

一人教，两人学——有人非常聪明

作为一名开发人员，您学到了什么经验教训？