没有人会告诉你，工作不再预先确定好的那一天。
两年来，工作任务都是预先确定好的。“在搜索中添加价格过滤器。”你打开服务，找到查询语句，添加一行代码，在午餐前就部署上线。有人已经画好了框。你只是在延伸他们的决策。
然后有一天，工单不再是一个普通的工单了。它只有两个字：“负责搜索。”没有人再递给你一个需要扩展的查询语句，也没有一个已经解释清楚该做什么的路线图项目。
这实际上是一种怎样的感觉呢？一位购物者访问了你的商店。在一个缓慢的周六，她正在浏览四十件商品，而你的搜索响应感觉是瞬时的。你是基于单个表和一个 WHERE 子句构建的，在一万种产品的规模下，这正是适合该任务的机器配置。
随后，商品目录增长到了两百万种产品。同一位购物者现在同时按价格、品牌、尺寸和颜色进行过滤。这里有一个不为人注意的情况：没有任何东西崩溃。WHERE 子句仍然返回结果。只是耗时从四秒变成六秒，再变成九秒。它在变得缓慢中失效，远在任何人提交错误报告之前，因为一个缓慢的回答看起来仍然像是一个正常运行的系统。
添加更多的过滤器，情况会以一种从代码中无法察觉的方式恶化。十个过滤器各自扫描同一个表，开始相互阻塞。本能反应是去寻求更大的服务器。但修复方法并不是更多的机器资源。而是一个完全不同的组件：一个专用的搜索引擎索引，一个专为搜索构建的模块，而不是让一个数据库表去执行它从未被设计用于承担的任务。
这就是“实现”与“负责”之间的全部区别。实现一个工单意味着在别人画好的框内编写代码。负责一项服务意味着决定存在哪些框。哪一个容纳数据。哪一个执行搜索。然后承受当这些选择背后的假设不再成立时所带来的后果。
每一项负责的服务都归结为三个问题。这是为谁服务的：是周六随意浏览的用户，还是过滤两百万种产品的人？它实际上构建于什么之上：哪些组件，以及每一个组件能否在你即将达到的规模下胜任其工作，而不是你今天的规模？当它增长时会发生什么：哪个组件最先崩溃，答案是同一事物的更大版本，还是完全不同的事物？
这些不是资深工程师的问题。它们是关于所有权的问题。当这些问题需要由你来回答时，你就不再是在实现功能。你是在做决策。
这是我看到初级工程师错过的关键一步。他们在等待。他们看到表格悄然变成了错误的工具，却等待它出现在路线图上。但负责任意味着你自己把它放入路线图，因为你是那个能看到产品否则将无法在其自身增长中生存的人。没有人会来为你添加那行待办事项。本应进行重新设计的空白区域并不是你指令中的缺失。那就是你的工作。
人工智能加剧了这一点。它并没有使其变得轻松。人工智能会编写 WHERE 子句。它也会编写搜索引擎索引配置，速度比你输入任何一项都要快。但它不会注意到一个表格已悄然变成了错误的工具。这个决策仍然属于你，而且正是这个决策决定了系统能否在其自身的增长中生存下来。
在课程 1 中，我教授七大构建模块，与其说是作为目录，不如说是作为一种词汇。一旦你能命名这些组件，这三个关于所有权的问题就不再模糊。“它构建于什么之上”变成了“这是一个执行搜索的表格，还是一个执行搜索的搜索引擎索引”，这是一个你真正能够回答的问题。
你不会因为关闭更多的工单而获得晋升。你会因为决定什么应该列入路线图而获得晋升，因为你是那个能看到产品需要什么才能生存下去的人。
附言：这封信有一个姊妹篇：为什么判断力，而非产出量，才是如今的工作核心
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
