你上一次写出一段自己都知道很丑的代码，是什么时候？
有人提出一个观察：过去初级开发者的问题是"知道得太少"，现在的问题变成了——他们再也没有机会在没人发现的情况下，把一件事做得很烂。
学编程的过程，本质上是一长串令人尴尬的猜测。你以为 bug 在数据库里，结果它在循环里；你以为自己懂了递归，其实没有，直到它第三次把你击垮。那个丑陋的、猜错的阶段，才是真正建立理解的地方。没有人能跳过它，从来没有人能。
每一次猜错，现在都有目击者
问题不在于某一个环节。代码评审是好事，结对编程也是好事。但当它们全部叠加在一起，每一次错误的猜测都会有一个见证者。
而一旦一个猜测有了见证者，它就不再是猜测了。它变成了一场自信的表演——因为在别人面前显得不确定，比独自犯错更让人难受。
于是他们开始对冲风险。先搜索再动手，先在频道里问一句再尝试自己修，不是因为懒，而是因为：独自失败、没人看见你尝试过，感觉是一场没有回报的风险。
如果没人看见你尝试，你失败了，你就是失败了。如果有人看见你尝试，你失败了，至少他们看见你试过。
这就是大多数初级开发者在不自知的情况下做出的交换：优化"看起来懂"，而不是那条更慢的路——真正去弄明白。而你无法通过看别人弄明白，来让自己弄明白。
表演准备就绪，和真正建立能力，是两种技能
这未必是他们的错。多数工作场所奖励"能力的表象"，速度快于奖励"能力的构建过程"。
表演准备就绪和真正建立能力，是两种不同的技能。它们之间并不互相迁移。
旧的方式更慢、更孤独，它能奏效恰恰是因为孤独。你坐在那个坏掉的东西旁边，直到你不再害怕坏掉的东西。没有人给修复前的那四个小时打分，没有人需要知道那四个小时。这正是它们起作用的原因。
在某个地方，仍然有一个初级开发者用旧的方式在做。合上笔记本，里面是半坏的东西，不告诉任何人，第二天带着比前一天少一点的恐惧回来。比房间里所有人都慢。但确实在建造什么东西。
所以真正的问题或许不是"怎么让初级开发者学得更快"，而是：当每一次试错都被记录、被围观、被评价，那个允许人安静地搞砸的空间，还剩下多少？
热门跟贴