身为一名资历深厚的程序员，究竟会洞察到哪些职场真谛与生存要诀呢？
GrumpyOldDev，是一位开发者给自己和网站取的网名，他是一位在金融服务领域深耕的技术人，早期从他父亲将 Apple II 电脑带回家时起，他就对科技深深着迷。据他所言，若是居住在美国进行信用卡或借记卡交易的人，极有可能与他在幕后所设计和推出的软件产生过交互。
在职场中，恰如这位开发者给自己取的网名含义一样，他是个脾气略显暴躁的老开发者。就在近日，他在分享自己职业生涯故事时发布了一篇名为《The One Where I Lie To The CTO》（我对 CTO 撒谎的情况）的文章，在 HN 上引起关注，其中他所阐述的职场生存法则引发了部分开发者的强烈共鸣，不过其做事方式也存在一定争议。
接下来，我们就来看看他在开发工作中如何上面对 CTO、外面对客户以及内对接外包公司的。
原文：https://grumpyolddev.com/post/the-one-where-i-lie-to-the-cto/
编译 | 苏宓
出品 | CSDN（ID：CSDNnews）
以下为译文：
这是几年前的事情了。要知道，在我职业生涯的早期，父亲曾告诉我，做好工作往往意味着不顾老板的反对，做该做的事。他的意思是，你要么可以让你的老板成功并快乐；要么你执行老板的每一个决定，在这种情况下，没有人会感到成功或快乐。
当时，我在一家财富 500 强公司工作，我们的 CTO 和一个重要客户签约了一个大项目，他与这名客户有私人关系。此外，他还决定将项目中的一个关键部分外包给一家大型科技技术服务公司来完成，这家公司声称他们有一种产品可以为我们完成大部分繁重的工作。
不靠谱的外包
在我的职业生涯中，当外包供应商公司说他们有一个产品时，他们真正的意思是他们有一个隐约类似于产品的东西，隐约符合我们的需求，通过大量的定制，他们可以把它变成我们需要的东西。
当然，通过定制他们的“产品”，我们巧妙地将供应商软件的所有缺点与定制软件的所有缺点都结合在了一起。我们同时实现了“坏主意”中的“圣杯”：一个不灵活的供应商软件包，它必须被迫去做一些它本来不应该做的事情，而且还要从他们的主产品代码库中分叉出来——一旦供应商意识到维护它的成本有多高，它迟早会被淘汰。
作为开发人员，我们内部互相吐槽这是一个多么可怕的馊主意，尤其是考虑到过去外包开发公司往往不会按时交付产品。
然而，因为我们的 CTO 每年都会更换他的直接下属，所以每次他的下属向他汇报有关项目的状态电话都是“老板，这是个好主意”，尽管实际上根本没有人认为这是一个好主意，甚至从心里认为这是一个平庸的想法亦或是个坏主意。
错误开始
项目的其他部分都需要在公司内部进行大量开发，所以我们也有自己忙碌的事情和种种挑战，忙得不可开交。但即便如此，随着整个夏天项目日期的推迟，外包供应商承诺他们的产品可以在 10 月份发布日期之前随时集成过来，然而除了 CTO 之外，其他人都越来越明显地感觉到项目遇到了麻烦。
终于在八月份，外包供应商交付了他们的“产品”，我们开始了与之「集成」的死亡之旅。
九月份，我们遇到了一个令人窒息的错误：
外包供应商的产品将每笔客户交易作为 json 记录存储在一个巨大的 json 文档中。
因此，随着测试数据的积累，产品的性能变得越来越慢。它的原理大致是：添加一个新的交易需要从数据库中读取整个 json 文档，然后将新记录添加到文档末尾。
外包供应商声称，他们可以通过对交易字段进行索引来解决这个问题，这似乎有点帮助，直到我们遇到了第二个问题。
他们选择的数据库是 MongoDB，而当时 Mongo 的记录限制是每个文档只有 16MB。
因此，到了 10 月份，当转换团队开始将真实的客户数据放入其中时，我们开始遇到 16MB 的限制，事情发生了非常有趣的转变。
隐瞒与真相
我们决定向客户隐瞒这一限制，并推迟一个月上线，但同时启动了一个Skunkworks 项目（秘密研发的项目）来替换外包供应商开发的功能，而且也没有告诉供应商。因此，我们同时欺骗了客户和重要的技术合作伙伴。
当时，GrumpyOldDev 组建了自己的团队来构建替代方案。供应商在这个项目上大概有 70 个人参与。GrumpyOldDev 指派了 3 个人来开发功能替换它：
一个负责设计数据库；
一个负责构建与数据库接口的后端；
还有一个负责构建业务逻辑/网络服务。
客户被告知，我们将在一月份推出新版本供他们测试。新版本将修复他们在最初上线时接受的最关键缺陷，但他们并不知道我们要重写整个核心系统。
此时距离新约定的交付时间只有不到两个月的时间。而最初的项目启动却花费了一年多的时间。我们只有 3 个人，而供应商那边却有 70 个人。更关键的是，3 个人还是只利用了假期的时间。
因此，大约在 12 月中旬，所有参与项目的人都被告知（不是要求）要在假期中工作。
要知道，在过去的 6 个月里，我们中的大多数人已经每周工作 60-80 个小时，只为赶上原定的发布日期。每个人都累坏了。
此时此刻，如果你是一名开发者，且不是一个以交付为导向的技术人员，你可能会觉得这太疯狂了，是时候辞职了。
或许你是对的。
但，我们中很多真正喜欢软件开发的人都觉得自己有点像摇滚明星。你花了几个月甚至几年的时间来准备这场演出，然后你的发布日期就像一场真正的表演，大家都想在发布日期一炮而红。
其中部分原因就像剧院里的人：演出必须继续。但你也希望当你所有的辛勤工作第一次触及真实用户，并且你感受到那种“我做到了”的兴奋时，觉得自己像个摇滚明星。
那时的用户喜欢我做的事情。我战胜了不可能。对于内向的人来说，软件发布就像是现场表演。
所以，这个时候差不多快到圣诞节了。团队基本上用一个月的时间就完成了替换软件的工作。只不过还有一些功能有待完善。
但这些开发人员都很聪明，他们一直在按部就班地完成任务，我知道如果他们不累垮的话，我们一定能赶上测试日期。
所以，当 CTO 找到我并说接下来的假期取消都来加班时，我说“好吧”......
然后，在我一生中最自豪的时刻，想起我父亲关于不管老板如何都要完成工作的建议……
我告诉我的三个伙计，“这周休息吧 我来搞定。”
每天早上我都会拨通 CTO 的电话，跟他汇报项目进度情况，我撒谎说：
“团队正在努力工作。今天我们达到了里程碑式集成的第 73 步了”
“团队昨天进展顺利，我们又完成了一项网络服务”
每天，我都会出现在大老板面前，告诉他我们正在努力工作，而这些工作实际上我们已经在上个月完成了。
一周后，我的三个小伙伴精神焕发地回来了。
我们在一月份如期完成了任务，上线后取得了很好的效果，还当了一段时间的「摇滚明星」，感觉还是不错的。
就在那一次，我对 CTO 撒了谎。
见解与看法？
面对 GrumpyOldDev 的经历，不少人将原因归咎为“公司不健康的工作氛围”，也有很多开发者感同身受。
网友 knodi123：
这对你来说听起来是不是很疯狂？不过，在我的第二份工作中我就处理了完全一样的事情。
整个客户和产品数据库存储在一个面向公众的 .js 平面文件中，该文件必须在应用程序执行任何操作之前完成加载（使用 2000 年代早期的互联网）。而最糟糕的是，这个应用程序是一个单一的整体文件，位于一个名为 index.1.js、index.final.js、index.newest.js、index.45.js 等的目录中。
我有足够的最佳实践经验，可以去找我们的 CEO 并解雇 CTO，然后着手用 git、mysql 和带有实际架构的服务器端逻辑来重写它。然后，它所运行的那个 Windows 服务器被攻破变成了一个色情服务器，尽管我从未见过该服务器，甚至没有管理员权限，但不知何故，这是我的责任。
伙计，我最初的几份工作真是受教育啊！
@karmajunkie：
我曾在一家公司（我就不提名字了）非常短暂地工作过，这家公司使用 ElasticSearch 来做这件事。每个客户基本上都有一个用于数据输入的定制表单，并且该表单上的每个字段都成为 ES 中的一个字段，即使系统中的所有其他表单上都有相同的字段名称和类型。最终，他们不得不与另一家公司签订合同，在定制集群上运行定制的 ES 构建，因为他们超出了 ES 中默认的 10k 字段数量限制。
当很明显他们对解决这个问题的兴趣为零时，我提出了辞职，并很快找到了一份有合理架构原则的新工作。
网友 Flarg： 即使是最健康的大公司也会做这种事情，我曾在一些公司工作过，我也向几家公司销售过。不知何故需要一队承包商来交付业务功能的低代码解决方案，延迟的项目放弃关键集成以实现按时交付，但在功能上毫无用处，CTO 的下一份工作取决于给外包供应商提供工作。最糟糕的是，那些坚持说他们购买而不是构建的组织，但其软件团队却比他们的外包供应商还庞大。
motbus3： 如果你是一个“交付驱动”的人，取消假期继续工作，我会根据自己的经验对你说：别再犯傻了。 我知道，特别是当你因努力工作而得到认可时，这很困难，但你每一分钟都会后悔。 如果你在一家依靠你的假期和休假来销售产品的公司工作，那么你正在帮助创造一个有问题的世界。如果很多人都这样做，那么还需要做更多的事情。如果没有人这样做，并且表现得好像要求这样做是荒谬的（事实确实如此），那么没有人会被迫这样做，公司也被迫进行真实的估计，即使这会损害你最喜欢的 CEO 的口袋。
对此，你是否有过这样的经历？在开发中，又遇到哪些出乎意料的“坑”?欢迎留言，分享你的看法。
热门跟贴