工程师的职业建议：从键盘旁走开

在我的职业生涯中，我对工作方式经历了两次到三次重大的思维转变。起初，我只专注于工程——试图尽可能多地了解我正在使用的语言或库，非常注重“琐事”，并且最终忽略他人的担忧，只是为了编写好的代码。这并不是说我没有努力与同事相处或帮助他们，但我为提升自己所做的努力都是为了我自己；毕竟，当我变得更好时，团队和公司也会变得更好。公平地说，这种方法并非完全没有道理。作为工程师，我们必须不断发展、学习更多、改进，因为这个行业正变得越来越艰难，每天都需要更多技术解决方案来解决更大的问题。这种方法在我的职业生涯的前半段对我来说效果很好，那时我还很资历尚浅，有这种自私（尽管是善意的）动机。

后来，我换了一份工作，在一个办公室里与比我整个职业生涯中遇到的工程师还要多的工程师一起工作。这份工作差点让我崩溃。我从担任的角色中比较优秀的人之一，变成了几乎勉强糊口……将近两年。我努力取得成功，我总是感到自己不如周围的人，很多时候我无法理解他们为什么要雇用我（事实证明，我的一些同事也有这种感觉）。但并没有什么重大的顿悟，也没有什么决定性的时刻扭转局面。只是一系列艰难的、彻底的失败，我从中只有两个选择——放弃或学习和成长。我尽力做到后者。当我回到一家规模较小的初创公司时，我亲眼目睹了从基层开始，围绕这些教训建立一种文化是多么重要。

我的最终思维转变发生在初创公司被一家更大的公司收购后，我转型为管理层。我并没有选择成为一名经理；管理层选择了我，因为我被提供了这个职位。他们还告诉我，虽然大家都非常信任我，但他们选择我的最终原因是，他们认为从内部提拔某人比从外部聘请某人动荡更小。收购后，我们的时间表非常紧迫，我的新公司不想因为引入一位不被团队信任的外部领导者而冒险。我发现这个阶段加强了我之前学到的一切关于在工程角色中如何有效工作的知识——并且提高了我在每一天每一分钟都需要应用这些教训的强度。

在 Twitter 上讨论

在 2018 年 5 月，在与我们扩展团队的一位初级成员进行了一次特别有意义且有价值的对话后，我发推文讨论了职业发展。这条 Twitter 帖子比我预期的更受关注，并且 Matt Broberg 邀请我为 Opensource.com 撰写关于它的文章。（Matt 告诉我我不允许在这篇文章中说脏话，所以请理解他的管辖权不延伸到我的推文。）

如果您只是想看简短版本，这里是：

• 专注于改进您与他人的沟通方式，特别是沟通的内容、语气和及时性。

• 努力成为更强的合作者——“角落里的工程师”不是你想要的名号

• 理解负责某事意味着什么，并努力实现你的承诺。在你的职业生涯中晋升意味着更广泛的责任和更少的关于如何处理它的指导。

• 学会失败，并从失败中学习。你会经历很多失败，大部分是小失败……但也包括一些大失败。不要让它让你脱轨；把它作为你下一个成功的垫脚石。

• “解决问题”是你可能拥有的最重要的工程技能。

• 永不停歇地学习。如果你停止学习，你就停止成长。如果你停止成长，你就无法迈向更大更好的事物。

• 学习 SQL；以后你会感谢我的

如何成为一名成功的工程师

最近，我们团队的一位年轻成员问我：“你希望软件工程师具备什么素质？”。他告诉我，我的回答让他感到惊讶，并且与他得到的其他答案不同，但在过去的几天里，我最终与不同级别的许多人进行了同样的对话...

— Sean Kelly (@StabbyCutyou) 2018 年 5 月 31 日

在一位支持工程师向我咨询关于如何成长为软件工程师的建议后，我发布了这条推文（以及随后的帖子）。我认为他期望我列出一系列技术、工具和编程语言，这些可以帮助他在工程团队中找到一份工作。相反，我给了他一份需要关注的行为清单。我的想法是，无论你从事什么工作（尤其是在初级职位上），都可能会对你进行成功所需的技术方面的培训。（至少在任何与如何以及雇用谁建立健康关系的地方，情况都是如此。）但我提到的事情是任何工程师都不太可能明确地与他合作的事情，因为它们传统上与我们不幸地称之为“软技能”的东西相关联。

我在这里暂停一下，声明“软技能”这个词低估了它们在成为一个全面发展的人，更不用说成为团队中成功成员方面的影响。尽量避免称它们为“软技能”（我在这里使用它是因为可悲的是，这是我们都知道的术语）。“整体技能”可能是一个更好的术语，但它不太吸引人，而且老实说，我不是来向你推销华而不实的新术语的。

我还想说，我接下来要阐述的这些东西并不是我认为我总是能正确做到的事情，甚至不是在从事这项工作 15 年后，我仍然不需要努力的事情。

但在我的职业生涯中，这些通常是我希望与之共事的优秀工程师的标志

— Sean Kelly (@StabbyCutyou) 2018 年 5 月 31 日

重要的是要强调，这些不是你可以“达成”或停止增长的技能（我认为大多数技能都是如此，但在这个背景下尤其如此）。团队动态非常复杂。作为人，我们是反复无常的。我们有好的日子和坏的日子，我们会挣扎，我们会崩溃。更糟糕的是，我们这样做的方式无法在常见问题解答中涵盖，也无法在脚本中自动化，这与我们运行的许多系统不同。我们的失败案例多得数不胜数，因此我们学习、适应和恢复的能力需要与之匹配。我失败过无数次，并且接受我还会再次失败无数次。但只要我一直在学习，我就一直在成长。我可以自信地说，在我的职业生涯中，我最喜欢与之共事的人都非常重视以下技能，主要是因为他们一直在努力提升这些技能。

现在也是提醒大家，没有人应该期望你总是或在任何时候都完美地掌握所有这些技能。每个人都有糟糕的日子。关键是要让糟糕的日子成为例外，这样当事情变得有点太困难，而你的反应方式（反思之后）你知道是不合格的时，人们不会认为那是你的常态。这些技能将帮助你在你的团队中建立信誉，你可以在那些时候兑现这些信誉，在那些时候，由于各种原因，你没有在工作中发挥出最佳水平。

善于沟通

他们知道如何有效地与他人分享他们的知识。他们知道何时应该更技术性/不太技术性，以及使用更多/更少的细节。他们理解肢体语言的重要性。当事情进展不顺利时，他们不会躲藏起来，而是经常向上/向外沟通。

— Sean Kelly (@StabbyCutyou) 2018 年 5 月 31 日

沟通是你作为一名高效工程师的生活中最重要的部分之一。你可以成为角落里的独狼，编写出精湛的代码，而没有人干扰你的技艺，这种想法对于我们行业中 99% 的人来说是不现实的——可能甚至更多。虽然独自一人高效工作的浪漫想法非常诱人，但隐藏在其中的陷阱是，这些人通常被视为一种负担。

在我的职业生涯早期，我以为我是一个好的沟通者，但我后来了解到，在不重要的时候我是一个过度沟通者，而在重要的时候我是一个沟通不足者。我努力找到正确的平衡点——何时应该过于技术性（我几乎总是倾向于这样做），以及何时应该仅仅给出 50,000 英尺的概览——这取决于我正在与之交谈的人的类型。当事情进展不顺利或“不准备好被看到”时，我也会躲藏起来——我会等到太晚才寻求帮助，我会独自迭代设计，直到我感觉它们准备好了，并且我将对方法的批评误解为对自己的批评。我花了数年时间才内化需要尽早向我的同事公开我的想法、我的工作状态以及我的设计的原始性质。

我记得当我注意到我在这方面有所进步时。我当时正在工作上做一个小型但重要的项目，我没有等到问题积累到爆发的地步，而是每天都告诉我的经理项目的进展情况、我担心即将到来的障碍以及这对底线意味着什么。你可能会想“这不是站立会议的目的吗？”，但我们大多数人只是用站立会议来列出一系列我们做过的事情以及我们可能要做的事情。它不是用来进行对话的。但这正是我发现对我更有帮助的东西：对话。我们每天早上在安顿下来准备开始一天的工作时，都会进行随意但详细的关于事情状态的对话，时间不超过 10 分钟。关于项目的进展情况、风险以及我是否需要任何外部帮助，从来没有任何困惑。它教会了我尽早且经常沟通，并且（在健康的环境中）我不会因为不完美而受到惩罚。相反，我因展示了我知道如何有效沟通而获得了进一步的自主权。

尝试与你的经理就你正在做的工作进行对话。他们会为此感谢你的（在奔赴他们的下一个会议的间隙）。

善于合作

他们知道何时是与他人合作的正确时机，以及何时是独自埋头苦干的正确时机。他们不害怕向其他团队成员——包括资历较浅的和资历较深的——征求想法。他们可以在不变得 Defensive 的情况下捍卫自己的立场。

— Sean Kelly (@StabbyCutyou) 2018 年 5 月 31 日

沟通是合作的基石，但建筑物不仅仅是用基石建造的。有效的合作是在作为一个团队完成工作的框架内应用的沟通——有时是一个两人团队，有时是一个 20 人团队。有时合作是知道何时不应让太多人参与，这样你就可以专注于将某事做到足够具体，以便获得反馈，有时是在你获得足够的反馈以确切知道你应该构建什么之前，什么都不开始。换句话说，这是一种平衡行为。但专注于成为一名高效的工程师意味着与他人合作——分享工作、分享想法、给予良好的反馈、良好地接受反馈，最重要的是，指导（并最终赞助）你周围的人。没有良好的沟通，你就无法很好地合作，反之亦然。它们是密不可分的。

但这需要你学会妥协，这样你才能在不变得 Defensive 的情况下进行捍卫。支持你的工作或你的提议以及你的理由是可以的，但要接受其他人可能对你正在做的事情有不同的看法或需求，并且这些意见也很重要。合作意味着就你的工作状态进行良好、健康，有时甚至是困难的讨论。学会参与其中而不会成为攻击者，并且在离开时不会感到受到攻击，这是有效合作的一个重要方面。这需要整个团队共同努力，以确定一套使合作成为可能的规范。请记住，每个人都在这里尽力做到最好，但并非每个人对什么是最好的工作都有相同的看法。从这个起点建立信任。

关于导师的话题：许多人可能会错误地认为指导总是两个人之间某种正式的伙伴关系，但情况并非总是如此。每当你与他人合作时，你都在被动地（或者，更好的是，主动地）向他们传授关于你自己和你所能做的事情，就像他们也在教你一样。有效的合作可以用一句著名的格言来概括：“涨潮会抬高所有船只。”它承认你在这里是为了支持他人，就像你期望他们支持你一样。最终，你会发现自己处于一个可以为你指导的人辩护和提供掩护的位置（称为赞助）——但你永远无法通过仅仅试图成为一个不善于与他人相处的独狼来实现这一点。

另一个需要学习的重要教训是，合作不仅仅发生在工程层面；工程师经常（尤其是对于重要项目）需要跨业务领域进行合作才能完成工作。例如，你所做的事情可能会影响财务人员用来向业务利益相关者展示数字的报告管道。高优先级的任务通常会因为其影响而受到很多关注。向上和向外沟通和协作变得越来越重要——尤其是因为他们所有人对他们需要从你那里获得的信息都有略微不同的偏好。你可能会说，“好吧，那是经理的事情，这样工程师就可以继续工作了”，但这最终是不正确的。

有效管理工程师的一个目标是让他们对正确的利益相关者负责，并看着他们在这种光芒下成长。将他们隐藏起来，你就会阻碍他们的成长。对于经理来说，平衡的艺术在于知道工程师何时开会太多，不再有足够的时间在键盘上工作，但这又是另一回事了。将与利益相关者合作的期望放在工程师身上，你就可以帮助他们培养他们的整体技能。试图阻止他们进行这些对话，最终你只会强化这样一种观念，即他们的唯一价值在于他们编写的代码行，而不是他们为解决客户问题而构建的解决方案。

经理们，鼓励你的工程师与整个业务领域的人建立合作关系。

承担责任

可以信任他们能够达到或超过他们的水平。他们努力按时完成任务（结合第 1 点和第 2 点），并且知道为什么按时完成任务很重要。或者他们可以帮助调整期望，以便业务部门的其他人员知道为什么无法按时完成任务。

— Sean Kelly (@StabbyCutyou) 2018 年 5 月 31 日

管理责任是困难的，因为你的经验越多，你需要负责的事情范围就越大，而关于如何做的指导就越少。实际上，这意味着负责任的行为是一种与环境相关的努力，并且通常为了承担更多责任，你需要学习如何管理自己，以便你可以处理更多任务，并以更大的自主性执行它们。

让我提供两个例子来阐明我的意思。有一次，我发现自己负责管理我们整个平台的排队和后台作业基础设施。这要求我对依赖于此基础设施的其他工程师负责，以便他们不必积极担心其健康状况，提供关于如何向系统添加新功能或作业的清晰明确的建议，并帮助诊断其集成问题。我必须对整个公司的工程师和团队负责，不仅要负责系统的现有状态，还要帮助他们弄清楚如何增加他们对系统的依赖。幸运的是，当时对我来说，我基本上只需要与其他工程师互动，因此这种情况在我当时的技能范围内是可控的。

后来，我负责平台财务支柱的大规模迁移。由于在平台上转移资金的齿轮最终会影响许多业务问题，突然间我需要与来自账单部门、各种产品经理和老板的老板们互动，更不用说所有我可能接触到的代码的工程师了。这需要一个我从未接触过的协调和协作水平。这也意味着我必须更擅长与不了解工程的人交谈，他们基本上不关心工程问题，他们需要知道他们的工作会发生什么变化，并且他们只需要知道它会起作用。对他们来说，问题不是技术问题，而是业务问题：我们需要这些数据，我们需要准确的数据，并且我们需要按时获得数据。再多的以工程为中心的对代码库老化的抱怨也无法安抚他们。这花费了数月的计划、测试、执行、与我从未听说过但突然不得不信任我的人会面等等。我写的电子邮件更多了，参加的会议更多了，并且最终花在我的首选编辑器之外的时间比我职业生涯中的任何时候都多。毫无疑问，这让我成为了一名更好的工程师。我第一次真正接触到我正在为其提供解决方案的真实客户，获得了他们的意见，让他们了解问题，并与他们找到了解决问题或边缘情况的妥协方案。这真是太棒了。

作为工程师，当我们承担更大、范围更广的项目时，我们需要拥抱这种责任的全部重量，而不仅仅是躲在我们的代码中。通过与工程团队和其他团队（包括非工程团队）接触，我对我的构建和维护对象有了更好的理解，这帮助我理解了哪些优先级是真实的，哪些只是对更宏大目标的干扰。管理者不能向工程师隐瞒这些机会，工程师需要知道他们何时准备好拥抱这些机会。

能够处理失败

这是一个棘手的问题，因为并非每个人都站在平等的立场上——并且同样的错误可能会根据你是谁而受到不同的批评，这很不幸。但是，对如何从失败中学习并克服失败的普遍理解是必须的。

— Sean Kelly (@StabbyCutyou) 2018 年 5 月 31 日

对于许多人来说，谈论这个问题可能令人不舒服，因为失败自然而然地不会公平地发生。来自某些人口群体的人不成比例地面临对其表现的批评和最终的评判，比其他人多得多。对每个人来说，理解解决这个问题始于你非常重要。不要因为你的同龄人尝试和失败而惩罚他们，就像你不想受到惩罚或评判一样。庆祝失败是一种学习方式。太容易陷入拆台的陷阱，尤其是那些“不像我们”的人。不惜一切代价避免这种心态。他人的成功不会威胁你自己的成功（在许多方面，它会帮助你的成功），并且将你的精力集中在培养你周围的人身上会获得更大的回报。

像保证会失败一样计划。我不是说要着手失败，但教训是期望并接受失败的发生。

如果你发现自己今天处于一种消极的“惩罚”文化中：改变它。现在就改变它。在拉取请求 (PR) 上留下更有意义和协作性的反馈。问问自己，“我是在直接评判这个人，还是在提供关于代码的可操作的反馈？” 了解“这是肯定应该改变的事情”和“这不是我会做的方式，但这并不意味着它是错误的”之间的区别。为此，你可能会研究一个短语，你可以用它来表达这种感觉，而无需直接说出来。例如，当有人向我征求对某事的反馈，而它不是我会做的方式时，我会确保我理解他们的目标，解释我会如何处理它，并说“但你应该追随你的内心”。这样我就不是告诉他们该怎么做，只是提供关于其他人可能如何处理它的背景信息。如果他们选择不采纳我的建议，我永远不会在我的“追随你的内心”反馈中挑剔他们。当你确实需要给出批评性反馈时，选择更好的措辞。“实话实说”很容易变成“你对我来说并不重要，所以我可以随意使用任何语言来批评你的工作”。你可以诚实和直接，而无需生硬或粗暴。

总而言之，作为一名工程师，你需要学习如何看到失败的价值——因为你会经历很多失败。你所做的事情会崩溃，系统会突然崩溃，项目会失败，人们会被重新分配到其他工作，有时你就是会完全搞错事情。这只是工作的一部分，学会不要因此而气馁，而是将它视为学习机会，这将使你在你的职业生涯中成为一名更有效的工程师。

解决问题的能力

对寻求适当的解决方案和理解根本原因的自然倾向，我见过的任何工程师都没有失败过。你不必成为编程界的夏洛克·福尔摩斯才能成为一个好的问题解决者，你只需要奉献精神和专注力。

— Sean Kelly (@StabbyCutyou) 2018 年 5 月 31 日

我建议人们关注的首要技术技能是解决问题。这也是并非每个人天生擅长的技能之一，但我认为每个人都可以通过足够的时间来学习。你需要专注于解决问题的策略，因为归根结底，这就是你获得报酬的原因。

许多工程师最大的误解是他们获得报酬是为了编写代码。这是错误的。

你获得报酬是为了解决问题——但你使用的最常见的解决问题媒介是你选择的代码编辑器。因此，在你的职业生涯初期，解决问题的行为主要与你编写代码的能力有关——修复错误、遵循规范或一组大纲来添加新功能等等。但随着你的职业生涯发展以及你所从事的工作范围扩大，你会越来越发现越来越难的问题，最终突破到你无法仅用代码解决的问题。但解决这些方案的动力——知道如何快速评估情况，利用你的经验来确定可能的原因，并努力证明或证伪这些假设——将永远是你工具箱中最重要的技能。

但这并不意味着你孤立地坐着直到你可以自己解决问题——良好的问题解决通常需要让他人参与进来以帮助你思考。从外部角度看待问题可以提供一组关于你可能缺乏并且可能永远无法独自获得的信息。这是雇用来自不同背景的人的众多原因之一——如果你周围的每个人都只知道什么是钉子，你将只会制造更好的锤子，而隔壁的螺丝刀公司会抢走你的午餐。我们常常试图以一种解决方案只适合我们认为我们是谁的方式来解决问题。这会导致产品质量差，会导致代码不灵活，并且会导致机会丧失。挑战这一点。

当真正开始工作时，知道何时应该埋头苦干，何时应该扩大你的问题解决范围是这项技能的另一个方面，你需要随着时间的推移来磨练它。有时，你必须只用自己的双手来解决问题；有时你需要他人的帮助。学习何时做每件事（并且你应该始终更多地偏向后者）是经验的标志。

承认这一点可能令人尴尬，但在我正在进行的一个项目中，我确实需要复习一些基本的数学知识——指数运算规则。起初，我很犹豫要寻求帮助。毕竟，工程师应该擅长数学。但我数学很糟糕。我从小到大所有数学课都学得很一般，而且我的大学（谢天谢地，当时对我来说）对计算机科学的数学要求不高。在为如何正确地将一些基于指数的规则应用于一些财务数据而绞尽脑汁之后，我意识到我是一个懦夫。我走到离我最近的同事那里，请他帮助我用白板演示一些数学，这样我就可以再次理解这些规则。他花了将近两个小时的时间和我一起在深夜重新教我们自己它是如何工作的。我现在知道有人可以帮助我更好地审查代码，寻找更多错误或提供关于实现的更直接的反馈。我必须解决这个问题，但我不必独自解决它，并且最终获得了更轻松的审查过程。我仍然认为那是我职业生涯中最愉快的事情之一。

喜欢学习

我们的行业发展太快了。每天都有新技术出现，旧的“最佳实践”被揭露为我们一直都知道的骗局等等。你不必跟上一切，但你应该享受学习的过程。

— Sean Kelly (@StabbyCutyou) 2018 年 5 月 31 日

如果解决问题对你来说是自然而然的，你可能会认为学习也是如此。毕竟，解决问题如果不是收集和执行新信息的行为，那又是什么呢？

但很多人感觉他们“完成”学习是很常见的。他们已经从事这项工作 X 年了，他们感觉自己已经站稳脚跟，他们觉得自己是某些事情的“权威”——而且他们很可能确实如此。但是技术和我们用来维护它的工具每天都在变化。你根本不能在任何方面宣布自己“完成”学习。

具体来说，你总是有新的东西要学习如何更有效地与他人合作，你总是有新的技术领域要亲身实践，而且你总是有下一个失败隐藏在角落里，等待着你从中吸取教训。我真的没有太多明智的建议，只是想说你不应该害怕遇到你不懂的东西，并承认你不知道。此外，你不必什么都知道，尽管这感觉很诱人。这是不可能的，如果你可以信任你周围的人，你就不需要什么都知道。参加其他团队的事后分析会议。在产品中找到你不理解的东西，然后去问别人。请你的老板帮助你找到一个你学习的新代码库领域。渴望知识，它会找到通往你的道路。

我特意告诉他“你会注意到我没有提到任何具体的技术或工具”，这是有充分理由的。

与上述内容相比，这些东西更容易教会。你可以带着具备上述所有素质的工程师，教他们你的技术栈。

— Sean Kelly (@StabbyCutyou) 2018 年 5 月 31 日

但反过来就不成立——你无法带着一个了解你的技术栈的工程师，很快教会他们以上几点。事实上，一个人的资历越高，就越难纠正。

这就是为什么冒险雇用年轻工程师有时是最佳选择。

— Sean Kelly (@StabbyCutyou) May 31, 2018

在 Twitter 帖子中，我被正确地指出使用了带有偏见的词语“younger（更年轻）”，所以我想首先澄清一下，我指的是“职业生涯更年轻”，而不是年龄。现在人们比以往任何时候都更容易转行，所以我们需要注意，不要仅仅根据年龄对人们产生偏见。

在我看来，这些技能比任何技术都重要。虽然很容易指出一些常青树般的技术，但这通常不是人们想听的。他们想听的是“学习 Kubernetes，因为它实际上是每个人都在做的，所以它永远不会过时永远不会。”或者“这个新的（Apache/云原生基金会/你从未听说过的其他联盟项目）将在五年后成为潮流，所以现在就成为这方面的专家。”可悲的事实是，这些答案实际上对一个人的成长是有害的。你找的任何工作都可能拥有你无法预测的技术栈（但你可以肯定，其中某个地方会有 SQL），你将在工作中花费大量时间来学习和成长，以管理该技术栈。

相反，当有人问你他们应该学习什么技术时，问问他们想学什么。他们对什么感兴趣？也许是图论，也许是统计学，也许是艺术、摄影或音乐。这些都可以指向有趣且小众的技术，合适的人会因为这些技术实现的结果而爱上它们，而不是因为那些关于它们将如何流行的浮华博客文章。在个人层面上与人们交流，找出让他们兴奋的是什么，以及他们希望用技术解决什么问题，并鼓励他们学习这些技术。

但是，如果有人问如何成为一名更好的工程师，想想什么会让团队想要聘用他们。以我的经验来看，是这篇博文涵盖的技能和态度。在任何一天，我都会优先考虑这些东西，而不是任何一项技术或编程语言。

工程师们常常认为“进步的途径就是更努力地研究技术”。学习更多的技术，成为更深入的学科专家等等。虽然这没错，但也不完全准确。当你在职业生涯中前进时，你不能忽视上述技能组合。

— Sean Kelly (@StabbyCutyou) May 31, 2018

当我的团队中有人希望从初级职位晋升到更高级职位时，我首先关注的是上述这些方面——因为更高级的人员是更广泛地面向公众的人员。他们无法避免与他人互动，因为他们对于完成工作至关重要。

— Sean Kelly (@StabbyCutyou) May 31, 2018

作为一名职业工程师，你花费时间最多的事情是沟通。与其他的工程师沟通，与产品经理沟通，与支持和销售人员沟通，与你的老板沟通，甚至有时与他们老板的老板沟通。有效地管理这些关系——通过在多个方向上成为优秀的沟通者，即使在意见不一致时也能与他人良好合作，处理越来越困难和复杂的职责，从不可避免的失败中学习而不沉溺于其中，专注于将这些技能应用于解决问题（技术或其他方面），以及最重要的是始终成长和学习——这些技能将把你带向成功的工程职业生涯，比任何一项单独的技术技能都更重要。

也许 SQL 除外。你知道吗，帮自己一个忙，学习 SQL。任何告诉你某种时髦的新型数据库消除了学习 SQL 的必要性的人都在撒谎，无论他们是否意识到这一点。学习 SQL；它真的很有价值，而且不会过时。

如果你看到了这里，这是一张我狗狗的酷照片 pic.twitter.com/3Ex92HOdyH

— Sean Kelly (@StabbyCutyou) May 31, 2018