每个开发者都在隐瞒什么——AI 解决不了

"我会想办法解决"的开发者心态

是的，我们都在撒谎。你可能也在撒谎。让我证明一下 😉

这周我真的被完全压倒了 😅 我刚刚完成了 JSNation 演讲的准备，同时另外两个很棒的机会出现了——一个专业的，一个感觉更像是童年梦想成真 ☺️ 但我还不想说出来怕坏了运气。

而且说实话，不是所有事都神奇地为我解决的——我最近也收到了几个被拒的 CFP。那些我真正在乎的！但说实话？这就是这个游戏的一部分。今年拒绝你的一个会议，明年可能很乐意接受你的另一个演讲。

所以是的，真正的大话题还得再等一会儿 🙂 这不意味着这个话题是微不足道的。

现在我们到处都在谈论 AI，好像它会解决我们所有的问题。但我们已经注意到，没有人类就没有 AI，在每个"智能"模型的背后，仍然有某个人类——至少目前是这样 😉

这也许就是为什么，在实际中，编码 Agent 确实能加快速度……但远远不如很多人预期的那样。有些研究甚至表明它们会拖慢开发者的速度。

因为真正的问题通常不是代码本身。真正的问题是编写或生成代码的人。

而不幸的是，我们都以某种方式撒谎。有时对别人，有时对自己。

有些开发者对自己做的事情知之甚少

我认识的一位最优秀的开发者曾经向我坦白过什么。

这个家伙真的很聪慧。那种公司争抢的工程师。他目前从事 LLM 驱动程序优化工作，经常获得晋升，即使在这个可爱的"科技危机"时代，他在考虑换工作时仍然有多个工作机会可以选择。

然而，每次他加入一个新项目时，他都感觉自己像个完全的白痴。

其他人似乎都很有生产力。人们在交付任务。写代码。自信地推进项目。而他呢，坐在那里盯着代码库想：

这里到底发生了什么？我们甚至在构建什么？这为什么这样工作？为什么我们以这种方式实现它而不是其他方式？

然后他开始提问。

通常，事实证明没人真正知道他们在做什么，为什么做，或者他们是否在解决正确的问题。

这让我想起了一个关于伐木工人砍伐森林的老笑话。最后，团队领导爬上最高的树，往周围看了看，尖叫道：

"伙计们！我们砍错森林了！"

下面的工人们喊回来：

"谁在乎？我们进展很快！"

老实说，没有任何 LLM 能在这里救我们。特别是如果我们甚至从不提出正确的问题。

有些人对如何做某事撒谎

这基本上是之前问题的延伸。

一个经验不足的开发者接到一个任务，自信地说："是的，我知道怎么做。"

不幸的是，他们通常的意思是："我希望我能想办法搞定。" 😅

实际上，他们可能不知道如何解决问题，使用什么工具，什么架构有意义……甚至不知道如何写 prompt 从编码 Agent 得到有用的帮助。

但他们害怕提问。

因为在团队面前他们会看起来怎样？经理会怎么想？技术主管？

最好的情况：他们最终会提问……只是太晚了。

最坏的情况：他们根本不问，交付了完全错误的东西。这通常甚至没有被正确捕获，因为……

有人对拥有时间撒谎

现在我们进入高级和领导力领地 😅

动机不同。有些人把自己的自我价值建立在"那个可靠的人"上。有些人害怕失去地位、影响力，甚至他们的工作。

所以他们继续承担更多：

与支持部门的讨论，

与业务部门的讨论，

架构决策，

让我们诚实地说。最终一定会有什么东西崩溃。

人类不是由钢铁制成的。没有人能永远以 100% 的效率运作。

那么会发生什么？人们开始在电话会议中半听。代码审查变得仓促。文档悄悄地死在某个角落。

但他们仍然拒绝承认——无论是对别人还是对自己——他们只是超负荷了。

有些开发者对事情需要多长时间撒谎

我经常从更高级的初级和中级开发者那里看到这一点。

他们毫无根据地抛出滑稽的乐观估计。

当然——如果他们能不间断地工作八个小时，应用程序不包含遗留代码，边界情况不存在，其他人类从不与系统交互……也许估计实际上是正确的 😄

然后冲刺审查到来，突然每个人都震惊团队没有交付一切。

但这不是估计的唯一问题。

我曾经和一个特别有趣的高级开发者一起工作。

他把估计当作神圣的真理。他会在规划会议中激烈地为他的数字辩护，坚持说这个特定的任务绝对非常复杂。团队的其他成员通常怀疑情况没有那么糟，但最终我们会投降只是为了结束讨论。

然后——至少有三次单独的情况——他个人接过他大大高估的确切任务……并在大约一个小时内完成了它。

这基本上意味着估计讨论本身花费的时间比实现功能还多 😅

这个经历改变了他的行为吗？

没有。

有些人对什么都是最好的撒谎

这些可能是最危险的。

我避免那些说这样的话的人：

"使用这项技术，只有这项技术，因为其他都是垃圾。"

插入你最喜欢的圣战：Angular 对比 React，Java 对比 Python，Rust 对比基本上任何东西 😄

我从不这样写。即使当我发表标题为"我喜欢 Tailwind。抱歉没法向你道歉"的内容时，我仍然谈论它的缺点并解释它绝对没有意义的地方。

如果有一天我开始声称某项技术对所有可能的情况都是客观完美的，请留下评论说：

"Sylwia，立即去接接地气。" 😅

老实说，我一直想知道这种绝对确定性从何而来。

因为不是所有这些人都是付费的影响者。有些人似乎在情感上被附着到技术圣战中。也许有些人只深入了解一个技术栈，所以其他一切都自动感觉"不好"。

虽然这种行为在技术影响者中非常普遍，但你在公司内部也绝对会看到它。

问题是这种确定性可能会严重损害项目。人们停止质疑决策。其他开发者害怕说出来。利益相关者假设"那个自信的人"一定是对的，仅仅因为他们听起来很确定。

最好的情况：你最终会得到一个只知道框架的讨厌开发者，而不知道实际的业务领域。

最坏的情况：你最终会得到一个可怕的技术栈选择和由自我维系的意大利面条式架构。

人就是……人

当然，我自己也不是无辜的。

我过去也用过许多这些谎言。也许我现在年纪大了。也许略微聪明了一点。或者也许我只是更容易识别这些模式。

但我肯定还在某个地方撒谎。也许不是对别人——也许是对自己。

因为我们在软件开发中的许多问题实际上根本不是技术问题。它们是深层次的人类问题：

害怕看起来很傻，

害怕承认错误，

害怕说"我不知道。"

老实说，我对此没有什么神奇的解决方案。我们不会要求每个开发者在被允许进入冲刺规划会议之前接受三年的治疗 😄

但我注意到了一件事。

非常经常地，承认你不知道某事、在规划中公开讨论不确定性，或者干脆说：

"抱歉，我仍然不理解这个。你能再解释一遍吗？"

不会让人们把你视为较差的开发者。

相反的情况非常经常发生。

突然间，团队内的沟通改善了。其他人也开始提问。对话变得更诚实。问题被更早地发现了。

真的。至少试一次。你可能会惊讶 🙂

那么……你在你的团队中最经常看到什么样的开发者谎言？

一些评论可能仅对已登录的访客可见。登录以查看所有评论。

关于进一步的操作，你可能会考虑屏蔽这个人和/或报告滥用。