与我共事过的最有效率的工程师不是那些一周工作80小时通宵或打卡的工程师。他们也不是工程师，他们可以毫不费力地设计出一个优雅的五行x86程序集，以简洁高效地解决问题。他们是工程师，他们似乎总是首先解决正确的问题。如果神话中的10x工程师真的存在，那么解决正确问题的可能性将是原来的10倍。虽然作为工程师，我们可能总是怀着最好的意图去解决正确的问题，但我们可能会犯许多错误，这会使我们走上错误的方向。解决错误的问题是什么样子想象一下你正在硅谷最新、最热门的独角兽创业公司工作。你的工作是建立最好的新的待办产品，因为人类第一次把笔写在纸上，项目符号列表出现了。公司伟大的远见者，返利怎么用，产品副总裁，走过来告诉你是时候了。你要建立一个杀手级的新功能：手机上的通知提醒你处理你的待办事项。你马上就会想到这个主意。"让我们在Go微服务中构建一个通知传递框架，"这似乎是一个很好的主意，因为你要避免这个你多年来一直在使用的单一应用程序的遗留问题，淘客公众号，它一直让你发疯。您将完美地将这个发送通知的简单任务封装在它自己的小服务中。更重要的是，你要用一种非常适合这种网络呼叫繁重工作负载的语言来编写它。你要做这个，这样以后你就可以给这个东西添加通知了。从表面上看，这似乎是个好主意，对吧？你的创业公司最终获得了一项关键技术，它将在未来几年内解决重要问题。但这句话吓坏了我。它有一堆警告信号，表明你将要离开，完全浪费大量的时间、精力和金钱来解决错误的问题。那么，解决正确的问题意味着什么？软件工程师并不是为了简单地生成代码行而得到报酬的。借用Tyler Treat、Phil Haack和其他许多人提出的观点，软件工程师并不是为了简单地生成代码行而获得报酬的。如果我们退后一步，我们真的会得到报酬来构建特性，提高效率，使它们越来越大，并修复问题或防止停机。代码是解决这些问题的副产品。但更重要的是，工程师最终得到的报酬是为我们所工作的组织在现实世界中的成功做出贡献。工程师的报酬是用来解决增加收入、降低成本、提高客户满意度、减少流失的问题。当你的工作集中在移动这些指标上时，你就知道你真正解决了正确的问题。所以，回到你完美的通知解决方案。你解决的问题对吗？我要讲三个我在这里看到的错误。这些年来我看到工程师们在开始一个新项目时犯下的错误。错误告诉我你没有解决正确的问题。误区一：技术驱动发展您所做的第一件事就是非常快速地跳转到一个非常技术性的解决方案——在Go微服务中构建一个通知传递框架。您已经收到了一个高级功能请求，您已经立即做出了语言和体系结构的选择，而不必停下来喘口气。通过跳转到特定的技术，您跳过了许多非常重要的问题：你真的需要解决让这项服务尽可能高效的问题吗？或者，全国大数据中心，您是否牺牲了大量开发人员的工作效率，从而从您不需要的Go中获得性能提升？这是微服务的地方吗？在主应用程序和新的通知传递服务之间必须共享的信息量是否会将它们紧密地耦合在一起，买服务器云，从而增加了复杂性？作为工程师，我们可以对使用一种技术特别热情，因为我们想学习它，在它上面做得更好，非常了解它，或者在过去用它取得了很大的成果。如果你只有一把锤子，顶多你碰到的每一个螺丝钉都用一个笨拙的工具。最坏的情况下，你会找到钉子。你会找出你选择的工具最适合的问题。它们可能不是需要解决的正确问题。相反，写下你的问题的描述和你为什么要解决它。专注于解决这个问题将给你的组织带来的价值，避免提及任何解决方案或技术。即使你99%确信你知道你将如何解决问题，也要尽你所能不让这个潜在的解决方案影响你对它的描述。稍后，当您设计解决方案时，您可以根据对问题的描述对其进行测试，以确保您没有偏离目标，解决不需要解决的问题。错误2：框架不成熟写一段最简单的代码来解决这个问题。你所提出的解决方案所犯的第二个错误是你对未来的巨大赌注。您可能需要在某个时刻传递各种不同的通知，但是如果其他通知类型从未成为具体的需求呢？如果它们之间的差异太大了以至于不能真正适合你的框架呢？这是一种庞大而昂贵的过早抽象形式。作为工程师，我们想制造出很酷的东西。我们想要建立一个更复杂的系统——一个解决比我们实际拥有的（现在或将来）更大问题的系统。在这个例子中，你肯定有一个问题，产品副总裁让你解决的问题——发送任务提醒通知。集中精力解决这个问题。写一段最简单的代码来解决这个问题。但是，遵循良好的编码实践，这样当你知道更多的时候，云实，你就有可能在将来改进你的代码，而不是在将来赌一把而显式地增加灵活性和可扩展性。如何避免过早的框架？在你写下你的问题的描述和你为什么要解决它之后，再去复习一下。一个没有沉浸在你将要开发的酷的新服务的兴奋中的同龄人会更加客观，能够指出你应该关注的小问题。这意味着你将着手实际解决正确的问题。错误3：沉没成本路线图第三个也是最后一个错误是最严重的，但它并不立即显现出来。当你加倍努力解决错误的问题时，它会在几个月后出现。您将花费大量时间构建一个通用的通知传递框架，它将非常复杂且运行成本高昂。记住，它只有一个用例，提醒通知，但你会发现自己坐下来，梦想着你可以用它构建的所有其他东西。您将忽略实际的业务问题和来自真正客户的特性请求，并构建一系列适合您已经具备的解决方案的特性。那么，我们如何才能避免沉没成本路线图呢？我敢说，这就是提高警惕性的地方，我敢说，是一些少量的过程。写下你的问题的描述，以及你为什么要解决它，并且每次都要检查它。如果你养成了这个习惯，或者你把它融入到你的过程中，你会在你即将建立一个错误的东西的时候冲出去——不管它们是如何进入你的路线图的。在对讲机，我们已经练习了很多年，我们称之为"间歇"。这只是一个项目简介的古怪名字。在我们开始开发新的软件之前，它迫使我们回答这样一个问题："我们在解决什么问题，为什么？"。虽然最初是我们的产品经理在考虑新的面向客户的特性或产品时使用的工具，但我们发现它对后端工程项目也非常有效，因为它使我们专注于提供真正的价值。每次都要关注问题所以在开始任何项目之前，写下你要解决的问题以及你为什么要解决它。在你做任何决定或写任何代码之前，先检查一下。在你开始构建一个新的软件之前，确保你每次都这么做。这样做，你就可以避免许多阻碍工程师解决正确问题的陷阱。