人们常会建议别人学习自己掌握的技能，或采用自己惯用的流程。例如，Steve Yegge 写过一系列博客文章，建议读一读编译器方面的书，学习编译器知识。他的理由大致是：如果你懂编译器，就会发现编译器问题无处不在，也能看出人们何时明明在解决编译器问题，却没有运用编译器知识。与其东拼西凑出一个考虑不周、注定行不通的方案，不如运用一点计算机科学知识，用更少的力气把问题解决得更好。此话并非没有道理，但它不足以说明为什么偏偏应该研究编译器，因为计算机科学和数学中的许多领域都可以套用同样的说法。排队论、计算机体系结构、数学优化、运筹学，等等。
面对这种反驳，一种回应是说，人应该什么都学。做一个涉猎极广的通才或许行得通，但如今要做到「每样都懂一点」而且卓有成效，已经难得多了，因为随着时间推移，各方面的知识无论广度还是深度都在不断增长。即使没有这种变化，我也觉得「应该」二字说得太重；一个人喜不喜欢如此广博，本来就是个人口味。还有一种同样可行、也更合我口味的做法，就是借用 Gian Carlo Rota 的说法：学会少数几个诀窍：
很久以前，一位年长而知名的数论学家说了些贬低 Paul Erdos 工作的话。你和我一样敬重人们对数学作出的贡献，所以当这位年长的数学家直截了当、斩钉截铁地断言，Erdos 的全部工作都可以归结为他在证明中反复使用的少数几个诀窍时，我感到很恼火。这位数论学家没有意识到，其他数学家——哪怕最杰出的数学家——也都依靠少数几个一用再用的诀窍。以 Hilbert 为例。Hilbert 文集第二卷收录的是 Hilbert 关于不变量理论的论文。我特意认真读过其中几篇。令人遗憾的是，Hilbert 的一些优美成果已经被彻底遗忘了。然而，细读 Hilbert 那些惊人而深刻的不变量理论定理的证明后，我惊讶地发现，Hilbert 的证明依靠的也是同样那几个诀窍。就连 Hilbert 也只有少数几个诀窍！
如果你观察人们如何在各个领域取得成功，就会发现这是一种常见做法。例如，这项对世界级柔道选手的分析发现，大多数选手只倚仗寥寥几种投技，并得出以下结论[1]
柔道讲究专精。你必须使用最适合自己的技术。你必须坚持行之有效的做法，不断练习自己的技术，直到它们化为本能反应。
如果你看的是一部「关于」格斗的动画或电视剧，角色往往靠增加掌握的技巧数量来变强，因为这很容易表现出来；但在现实中，把已经掌握的技巧练得更精，往往比拥有几百种「招式」的庞大招式库更有效。
我曾经听到过一条建议：把自己的优势放大。我们每个人都有长处和短处，也会花很多时间讨论「有待改进之处」。人很容易觉得，进步的最佳办法就是把这些短处全部消除。然而，如果某个方面确实是我们的弱项，即使投入大量时间和精力，也可能几乎看不到起色。当然，你仍然要确保自己没有任何严重的短板；但在做到这一点之后，就应该把重点转向放大自己的优势。怎样才能把一件你擅长的事变成你的超能力？
我亲身体会到，这在许多不同领域都成立。程序员的效能几乎不可能以接近客观的方式衡量，但我做过的另一些事情，其水平却可以较为客观地衡量，比如竞技电子游戏（那已经是很久以前的事了，当时竞技游戏里还没有「真正的」钱）。让我从一名相当不错的玩家变成非常优秀的玩家的关键，是不再练习自己不太擅长的东西，转而集中精力，在少数几件自己格外擅长的事情上进一步扩大对所有人的优势。
这种做法在游戏和体育运动中行得通，是因为你既可以更善于把自己带入能够发挥优势的局面，也可以避开会暴露弱点的情形。我认为，它在工作中其实比在体育或游戏中更有效，因为工作不同于竞技活动，没有对手会设法揭你的短，逼你进入优势毫无用处的局面。如果我选择研究排队论而不是编译器，与我竞争的同事并不会阻止我去做那些能用上排队论知识的项目，再把我赶到一堆非懂编译器不可的项目面前。
有一点值得注意：技能不一定非得是人们眼中的学术领域或一项项独立的技巧。过去三年里，我主要运用并精进的技能，是一种姑且可以称为「看数据」的东西；之所以加引号，是因为我不知道该用什么更合适的名称。我认为它并不是大多数人理解的「统计学」，因为我很少需要做逻辑回归这么复杂的事，更不用说真正复杂的分析了。也许有人会说，这正是数据科学家做的事；但若把我的工作、我们聘用的数据科学家的工作，以及数据科学家面试所考查的能力放在一起看，我们似乎既不打算招募具备我正在培养的这项技能的数据科学家，数据科学家所做的也不是我正在做的事（这个话题很长，我以后或许会单独写成一篇文章）。
我不会像 Matt Might 或 Steve Yegge 那样说你应该采用某一种特定方法，但我可以说：只专攻少数几件事、不求面面俱到，这种做法已经在多个截然不同的领域对我奏效，看来也同样适用于许多其他人。
如果你想采用这种方法，仍然要回答一个问题：该学哪些技能。这是别人最常问我的问题之一，而我的答案恐怕并不是他们真正想听的，也不怎么令人满意，因为它既显而易见，又难以付诸实践。
对我来说，要判断该花时间学什么，有两个要素：一是对某件事具有相对天赋（这里是相对于我可能去做的其他事情，而不是相对于其他人），二是有一个良好的学习环境。叫人去寻找这两样东西，听起来含糊得几乎毫无用处，但仍然胜过常见的那类建议；那类建议归根结底无非是「学我学过的东西」，于是便会出现这样的说法：「职业小贴士：如果你想真正擅长——非常、非常擅长——在现实环境中大规模设计复杂而有状态的分布式系统，那就学习函数式编程。二者所需的技能组合几乎一模一样。」有些编程语言社群的说法甚至更加极端，比如 Chuck Moore 声称，Forth 能让生产率至少达到使用无聊语言时的 100 倍。
职业生涯早期，我采纳过互联网上流传的一般性建议，其中也包括编程语言方面的建议（当时这类建议大多刚兴起不久，人们还不容易看出：尽管许多人都照着做了，采纳这些建议的人并没有特别高效，而那些特别高效的人往往也没有采纳过它们）。我学了 Haskell、Lisp、Forth，等等。我职业生涯中有一段时间待在一个两人团队里，我们实现了一款即使十年后也可能仍是现存性能最高的 Forth 处理器（它是一款面向 IPC 的 2GHz 处理器），我也为它编写程序（把它设计成栈处理器有充分理由，因此 Forth 和其他选择一样合情合理）。和 Yossi Kreinin 一样，我想我可以说，为了熟练掌握 Forth，我付出的努力超过了大多数人；也和他一样，我不但没有发现它是一件能让生产率达到原来的 100 倍的工具，甚至无法确定它一般而言能否让生产率达到原来的 1 倍。公平地说，另有一些工具确实能把生产率提升至原来的 1 倍以上；但总体而言，听从互联网建议给我带来的 ROI 很低，而我学到的那些 ROI 很高的东西，却并不是别人推荐的。
现在回想起来，当人们说「Forth 的生产率很高」之类的话时，我猜他们真正想表达的是：「Forth 让我拥有很高的生产率，而我没有考虑这能在多大程度上推广到天资不同或身处不同情境的人。」Forth（或 Lisp、Haskell，乃至任何其他工具或技巧）对某些特定的人特别好用，我觉得完全有可能；但人们往往会高估「对自己有效」在多大程度上意味着「对别人也有效」，所以建议通常都没什么用，因为它们没有区分只适用于特定天赋或情境的建议和可以普遍推广的建议；这与那些真正会讨论具体技巧利弊的领域形成了鲜明对比[2]。
教练可以通过 1 对 1 或小组指导，给出为你量身定制的建议，但这在互联网上很难做到。因此，我在这里能给出的最好建议，也只能是含糊得毫无用处的「选择适合自己的技能」。仅举两个例子，与我特别合拍的技能是「对抗性思维」和「看数据」。一条或许没那么无用的建议是：如果你很难判断自己的这类技能是什么，不妨去问非常了解你的人。例如，我的经理和 Ben Kuhn 各自独立地指出，想出横跨多个抽象层次的解决方案，是我经常运用的一项技能（在他们点明之前，我甚至没有意识到自己一直在这样做）。
还有一种办法，是寻找那些你忍不住会去做、但大多数人似乎不会做的事情；对我而言，「看数据」和「对抗性思维」都属于这一类。仍以对抗性思维为例：我任职的一家公司对一款新的定制缺陷跟踪器做 Beta 测试时，我提交了最早的一批缺陷，还故意在字段里填入不寻常的内容，看看能不能把它弄坏。有些人完全不明白为什么会有人做这种事，觉得莫名其妙、厌恶甚至惊恐；但也有少数人真正懂了，并且很高兴看到这个系统被推到极限之外，其中就包括它的开发者——我知道他们不会介意。试探一个系统的边界，看看它会在哪里崩溃，对我来说不像是在工作；如果不想做，我反而得刻意拦住自己。因此，花十年时间不断精进测试与验证技术，更像是一件我很难忍住不做的事，而不像工作。深入审视数据是另一件我已经做了十多年的事；对我来说，不继续提高这方面的能力，甚至会让人在情感上觉得有些不对劲。
这些事情之所以适合我，基本上源于我的个性，并非人类身上固有的某种共性。其他人自然会有另外一些让自己觉得格外轻松、顺手的事情；这很好，因为如果人人都热衷于看数据，却没人愿意动手构建东西，那就麻烦大了（不过在我看来，平均而言，「看数据」的价值仍然被低估了）。
我决定学什么时考虑的另一个主要因素，是能否找到有利于学习的环境，让我培养与自身特点契合、对自己有意义的技能。建议别人也这么做，听来或许显而易见得近乎无用；但从我见过的人们选择加入哪个团队、哪家公司时的表现来看，几乎没有人真的这么做。因此，讨论这一点或许还不至于毫无价值。
一个很典型的反例，是我偶然听说的一件事。当时我和一位经理聊到，为什么这位经理的团队会失去一名刚从实习生转为全职员工的新人。我之所以追问，是因为这位经理很擅长留住员工，团队的人员流动率也很低，很少有人会离开。原来，这名实习生想做基础设施工作，却进了这位经理的产品团队，因为这名实习生不知道自己可以要求加入更符合个人偏好的团队。经理了解情况后，希望这名实习生能工作得开心，便帮其转入了一个基础设施团队。在这个案例中，这名新员工可谓错上加错，因为这名新人从两个层面都没有考虑要在有利于学习目标技能的环境里工作：这名新人根本没有尝试进入自己感兴趣的领域；随后又加入了一家公司，而这家公司的基础设施组织运作失常，设计与运维实践普遍很差。也就是说，这名新人不仅没有设法加入基础设施团队，所选的公司本身还是个相对不利于学习基础设施的地方。这个例子虽然格外糟糕，但就我见过的中位情况而言，人们做出的决定在学习方面往往得不到特别好的结果，尽管「良好的学习机会」总是他们声称最想得到的东西之一。
例如，Steve Yegge 曾指出：
大学生求职者最常问的问题是：「你们提供什么样的培训和／或辅导？」……UW 的一位面试者刚刚跟我讲了 Ford Motor Company 的辅导计划，Ford 似乎曾把这项计划作为招揽面试者时的卖点之一。[我省略了细节，因为它们与此并无关系。 -stevey 3/1/2006]这名学生竟把全部内容记得极其详细。这倒不怎么让我意外，因为这本来就是求职者最关心的事情之一。
就我而言，我很幸运，第一份工作所在的 Centaur 是个绝佳的环境，很适合培养测试与验证方面的对抗性思维。那里的验证团队所取得的成果，足以媲美其他公司同类项目的成果，而后者动用了大得多的团队来做非常相似的事情，成效却相当甚至更差。这说明那支团队的生产率极高，也使那里成为一个绝佳的学习场所。
此外，我不认为单靠自己摸索，或照着书本和互联网的建议去做，也能学得这么快。我认为，真正擅长一件事的人，脑中关于如何做好它的信息实在太多，根本无法真正压缩进一本书，更不用说一篇博客文章了。在体育运动中，优秀教练能够在长期指导中传授这种知识，但我不知道编程领域有什么类似的机制；所以在现有条件下，要想提高学习速度，最好的办法大概就是找到一个高手云集的环境[3]。
至于「看数据」，即使我过去是在人们并不真正重视数据的环境里磨炼这项技能，仍然取得了很大进步；但过去几年里的进步速度要快得多，因为在现在的环境中，我可以和一群既善于理解数据所能说明之事的局限、又善于借助深厚领域知识指导数据分析的人来回交流想法。可以说，在目前这份工作的每一年里，我在这方面取得的进步都超过了此前十年的总和。
也许需要指出，环境——也就是你每天如何度过时间——本质上是局部的。在我工作过的三家大型科技公司中，我目前的雇主可能是数据驱动程度最低的一家；但我身边的工作环境却非常适合提高「看数据」的能力，因为我有相对较多的时间与 Rebecca Isaacs 这样极擅长运用数据的人共事，而只有相对较少的时间需要和那些不认真对待数据的人打交道。
本文一直着眼于这些策略为何可能有价值，但我得承认，我向专家学习并不是为了创造价值。更主要的原因是，我觉得学习本身很好玩；有些领域足以让我产生强烈动力，无论环境如何都会运用相关技能，而向专家学习又是尽享这种乐趣的绝佳机会，实在令人难以抗拒。这样做了二十来年，结果证明的确很有用，但在相当长一段时间里，我并不知道事情会变成这样（而且在从硬件转向软件之前，我根本不知道这些能力可以有效迁移到一个新行业）。
我看到的许多职业建议都围绕事业、成功或成长展开。这类建议往往告诉人们，要有长远的目标或策略。它们常提出大意如下的论证：「随机游走只能让你朝某个方向移动 sqrt(n)，而定向行走能让你朝某个方向移动 n。」我不认为这有错，但对许多人来说，这类建议隐含的判断低估了找到一个适合自己的领域有多难[4]，而我基本上是靠反复试错找到的。
附录：本文没有详细讨论的问题
本文没有讨论的一个重要话题，是该如何权衡自己应该培养哪个「层级」的技能：高层技能可以是「看数据」，低一层的可以是「贝叶斯多层模型」，再低一层则可以是「打字速度」。这个话题很大，值得单独写成一篇文章，而且我料想那篇文章会比本文更长；不过眼下，这里有 Gary Bernhardt 对一个相关问题的评论，我相信它也适用于这个话题[1]。
另一个没有讨论的重要话题，是如何选择相对更有可能派上用场的技能。只说一个人应该考虑学习自己有天资的技能，却完全不考虑这些技能是否适用，未免过于天真。
我们很容易挑出一些很难帮助你影响世界、赚到可观收入或实现其他目标的技能，比如「篮球」或「拳击」；但要在计算机体系结构与 PL 这类看起来都合情合理的技能之间作选择，就困难得多。
不过我认为，只要与本人契合，那些听起来还算合理的技能就很有可能带来高回报。因此，在这类技能中反复试错并无不可；当然，能够快速尝试各种东西大概会有所帮助
附录：相关文章
- Ben Kuhn 从某种意义上谈真正学会某样东西是什么感觉
- Holden Karnofsky 谈在职业选择上以天赋为先，而不是以职业路径为先，这有些类似于关注「看数据」或「对抗性思维」这类跨领域技能，而不只考虑「编译器」或「排队论」这样的技能
- 彼得·德鲁克谈如何了解自己的长处和短处，并从事符合自身倾向的工作
- Alexy Guzey 谈建议的有效性
- Edward Kmett 提供了思考学习问题的另一个视角
- Patrick Collison 谈如何最大限度地进行有用的学习，并找到自己会喜欢的事
感谢 Ben Kuhn、Alexey Guzey、Marek Majkowski、Nick Bergson-Shilcock、@bekindtopeople2、Aaron Levin、Milosz Danczak、Anja Boskovic、John Doty、Justin Blank、Mark Hansen、「wl」和 Jamie Brandon 提供评论、指正与讨论。
- 这是一项旧分析。如果今天再做一次，你会看到不同的投技组合，但专精型选手依然能取得很大成功，例如擅长大外刈的 Riner。
- 要替这种一概而论、脱离语境的建议说句公道话：在学习某个特定主题时，函数式编程的确与我很合拍。我可以想象，如果这种思维方式对我来说并不是本来就很自然（我之所以觉得自然，是因为有硬件背景），那么「应该学习函数式编程，因为它会改变你思考问题的方式」这条建议或许对我有用。不过换个角度看，这也意味着那条建议完全可以改成「学习硬件工程」。
- 我的样本不够大，也没有调查足够多的人，无法很有把握地说这种办法可以作为一套普遍适用的算法；但在寻找世界级专家群体这件事上，对我奏效的办法是寻找优秀的经理。我工作过的两个世界级专家密度最高的团队，都由真正出色的经理管理。我心目中「优秀管理」的门槛比大多数人高；根据我和许多人谈论此事的经历，几乎没人曾为一位达到我所谓优秀标准的经理工作过，甚至几乎没人认识这样的经理（而且通常对方也认同我的判断，这说明并不是他们的经理只在我不重视的维度上表现出色，或者情况恰好相反）。根据这些讨论，我猜，我眼中的优秀经理至少胜过 99.9% 的经理。至于如何找到这样的经理，是个很长的话题，我以后或许会另写一篇文章。
不管怎样，尽管我的样本相当小，我认为背后的机制是说得通的：我认识的优秀经理不仅人员留存率很高，还有一大群人排着队想为他们工作；因此，他们相对容易招到并留住具有世界级专业能力的人，毕竟其他地方的景象实在太惨淡了。
一种更常见的策略，是去解决身边听起来最有趣和／或最困难的问题；我认为这种策略通常无效，至少我尝试时效果也不怎么样。在努力解决有趣／困难的问题的过程中，我确实和一些真正优秀的人共事过，其中包括我合作过的最优秀的工程师之一；但若目标是与自己真正想向其学习的人共事，我认为这种做法远不如寻找良好的管理有效。我相信，这套方法的普遍问题，和仅仅因为电子游戏很酷和／或有趣就投身电子游戏行业的问题一样：太多人想做听起来激动人心的事情，反而使运作失常的环境能够无限期延续下去。
有一次，我所在的团队在九个月内人员流动率达到了 100%；若不是其中一人花了很长时间才找到可转入的团队，达到这一流动率原本只需六个月。就中位情况而言，与我同期入职的一批人（也就是大致在我前后加入的人）的年人员流动率约为 50%，而我认为大家离职都有相当充分的理由。如此高的流动率不仅表明环境往往令人相当不快，这类环境还会不成比例地逼走那些我希望与之共事和／或向其学习的人。例如，我曾加入一个团队，那里的 TL 不认同使用版本控制、自动化测试或流水线式设计；我在那个团队和非常优秀的 Ikhwan Lee 共事过。当然，Ikhwan 很快就离开了，而 TL 留了下来，六年后仍在那里。 - 我在熟人中多次看到，人们还完全不知道某个方向是否适合自己，就已经选定了它。往往要经过很长时间（有时超过十年），他们才发现自己其实对所走的方向极其不满；有时是因为它不合自己的性情，有时则是因为自己确实不擅长。无论如何，与沿着一条令你不快乐的路走到 n 处相比，漫无目的地兜兜转转，最后发现自己在一条令你快乐的路上走到了 sqrt(n) 处，似乎也没有那么糟。
Thoughts Memo 汉化组译制
感谢主要译者 gpt-5.6-sol-xhigh，校对 Jarrett Ye
原文：What to learn