mod

极客时间专栏/大厂晋升指南/加餐/加餐一 | 晋升等级：不同的职级体系如何对标？.md

@@ -0,0 +1,141 @@
+<audio id="audio" title="加餐一 | 晋升等级：不同的职级体系如何对标？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c6/da/c6db952ec4bdbf019edd10c20713aeda.mp3"></audio>
+
+你好，我是华仔。
+
+现在，跳槽已经成为职场常态，很多人都是通过跳槽来实现职级的提升和工资的大幅增长。但是，你在跳槽到另一家公司的时候，很可能在评级阶段面临左右为难的尴尬。
+
+如果你的预期过高，而新公司认为你没有达到相应的等级，那么你可能会错失一个很好的工作机会；但如果你要求的级别太低，在谈薪酬股票的时候又会比较吃亏。
+
+这是因为不同的公司采用的职级体系往往也是不同的。你平时要是不关注其他公司的职级体系，在能力对标的时候，就无法准确地评估自己的能力级别和市场行情。
+
+所以，你需要形成合理的自我级别认知，对各个公司的级别对应关系有一个比较明确的了解。
+
+为了让你能够清晰地了解公司之间的级别对应关系，在这一讲中，我挑选了几家最具代表性和最有影响力的大公司作为例子。我会带你分析它们的职业等级信息，让你在面试评级时心里有底，能够自信地向HR和面试官提出自己的要求。
+
+<img src="https://static001.geekbang.org/resource/image/82/01/82fc15a678348f3a448ff917885f4a01.jpg" alt="">
+
+## 对比原则
+
+刚才提到，不同的公司职级体系不同，有的是跨越式职级，有的是阶梯式职级。即使两个公司职级体系类似，在级别设计、岗位名称上也会有很多区别，并没有通用的规范来一一对应。所以，我们需要明确一条通用的标尺，来衡量不同公司的两个岗位是否能够对等。这个衡量标准就是**“年度总收入”**，简单来说，**年度总收入相近的岗位基本可以认为是对等的岗位**。
+
+总收入包括薪资、奖金和股票期权等部分，你可以通过以下渠道去了解：
+
+1. 面试的时候找HR详细了解。
+1. 跟BAT或TMD的同事/朋友聊聊。
+1. 找猎头聊聊。
+
+因此，你在跳槽的时候首先要明确面试定级到底是什么，尤其是跨越式职级体系。因为它除了明确的级别之外，还可能隐藏的细分等级，比如P6可能还分P6-、P6和P6+。另外， 你也要根据谈的薪资来大概推断一下定级是否合理，这样就避免因为过高的薪资期望而错失机会，也不会因为只看级别而损失一些本来可以拿到的回报。
+
+## 阿里：职级硬通货
+
+从目前整个行业的认可度来看，阿里巴巴的层级可以称得上是行业“硬通货”，所以我先从阿里说起，然后再拿其他公司跟它对比。
+
+阿里采用的是跨越式职级，相邻级别之间的跨度很大，目前技术人员基本上都是从P5开始定级的。你可能在网上还看到过P1～P4的等级，但这几个级别主要是给一些初级职能岗或者外包定级用的。
+
+下面我从P5开始，逐一介绍各个级别的特点。
+
+P5是**应届生定级起点**，包括本科和研究生，以及工作2年内社招高潜人才。
+
+P6是**开发主力**，能够独立承担业务需求的开发任务。优秀的P6可能还会带3～5个人。
+
+P7是**团队核心**，要么作为Team Leader带人，要么作为初级架构师负责子系统的设计开发。
+
+P7有点像王者荣耀的“永恒钻石”段位，很多人到了这个级别就很难再晋升了。它虽然对应的管理级别是**经理**，但通常情况带的人在10个以内，跟很多其他公司的经理相比，团队规模要小得多。所以，P7实际上就是一线的主管而已。
+
+P8是**部门核心**，基本都是带团队的，需要负责一块完整的业务。这里的业务规模可以理解为创业公司的一个初创业务的规模，所以P8去创业公司基本就是CTO了。
+
+P9是**业务核心**或者**行业专家**，基本算是打工的巅峰了，比如著名的安全大神云舒，在阿里时是P9。各路业界专家、科研大牛进阿里也基本都是从P9开始定级的，比如网上出名的王垠，他受邀加入阿里时，面试的岗位也是P9级别。
+
+P10是**业界大牛**，从这个级别开始，我已经不太能够用普通的语言来定义了。
+
+如果说P9是“最强王者”，那么P10就是“荣耀王者”了。现在科大讯飞的副总裁刘鹏，当初拿阿里offer时给了P10；Facebook的HipHop项目负责人赵海平加入阿里的时候，级别也是P10。
+
+P11是**业界领军人物、科学家**。
+
+这个级别既需要天才，还要有运气。比较有名的P11，有江湖人称“道哥”的吴翰清，他是阿里首席安全科学家、阿里云安全负责人；还有阿里合伙人多隆，他是淘宝的第一代程序员，号称淘宝的“扫地僧”。如果还要拿游戏来类比，我愿意称他们是“国服最强”。
+
+我把这些级别的信息整理汇总在这个表格里，方便你查看和对比。
+
+<img src="https://static001.geekbang.org/resource/image/e6/9a/e631701b34593605yy7abdff2093ee9a.jpg" alt="">
+
+关于阿里的跨越式职级，我还想补充几点：
+
+1. 像工作年限这些信息，都是针对大部分人的情况来说的，**不是绝对的标准**。比如阿里P6，我说“需要工作2～5年”，是因为大多数人工作2～5年可以达到这个级别，但可能有些厉害的人，工作5年就达到P8了。
+1. 岗位要求是我根据个人经验做的总结，**不代表公司的详细要求**。实际面试之前，你还是得对照职位描述（JD，Job Description）进行自我评估。
+1. 低于阿里P5的级别，我没有做说明和比较，因为现在已经基本不会再定这个级别了。
+1. 超过阿里P11的级别，我也没有做说明和比较，因为我对这部分内容并没有什么认知。
+
+## 腾讯：天梯式职级
+
+有了阿里巴巴的职级体系作为基础，我们理解其他公司的职级就轻松多了。接下来，我先说说与阿里并驾齐驱的腾讯。
+
+腾讯在2019年进行了职级的升级，不过现在很多技术人员还是更熟悉腾讯以前职级体系。为了方便理解和交流，我把腾讯新、旧职级体系放在一起来跟阿里对比。它们之间的对应关系如下表所示：
+
+<img src="https://static001.geekbang.org/resource/image/d7/f7/d7a09afbcaefe6f9bffb3aaf9a64fbf7.jpg" alt="">
+
+腾讯内部每年会有两次整体评估，如果评估合格，就可晋升一个职等。在旧的体系中，腾讯大部分员工处于T2.3～T3.2区间，这个区间基本上对应了阿里的P6～P7区间。
+
+腾讯的晋升标准主要有两部分：
+
+1. **硬性指标**，也就是工作年限、考核成绩和是否有重大贡献等。
+1. **答辩**，也就是专业通道面试。
+
+在腾讯，T3（新的9级）是一个门槛。因为通常公司从 T2.3（新的8级）开始会严格要求硬性指标，并且安排严格的晋升面试。
+
+## 百度：此总监非彼总监
+
+百度的级别采用的也是跨越式职级体系，级别数字刚好比阿里小一，所以很方便对比。它们之间的对应关系如下表所示：
+
+<img src="https://static001.geekbang.org/resource/image/06/86/06ae44c5fb745c8e3964c444e6ea5986.jpg" alt="">
+
+和阿里类似，百度的大部分工程师处于T5～T6这个区间。应届生毕业进去会给T2或T3，根据学历和面试表现来定级，低级别阶段一般都能1年1升；从T4开始，晋升的时候需要答辩；从T5开始，晋升就越来越难了。
+
+需要注意的是，这两套体系里的**“总监”**差异还是挺大的。阿里P9对应的管理级别叫“总监”，而百度的“技术总监”是T10，相当于阿里P11的高级研究员，对应到阿里的管理序列是“副总裁”。
+
+<img src="https://static001.geekbang.org/resource/image/51/55/51286a184c55ff6a6b5e17ddc1715a55.jpg" alt="">
+
+简单地说，百度的总监，其实级别要比阿里高不少。
+
+## 头条：升级就像“升官”
+
+了解完老牌的大厂，我们再把目光转向互联网新贵。其中影响最大的，应该就是字节跳动了，为了交流方便，我们还是叫它“头条”吧。头条的级别跟阿里的对应关系如下：
+
+<img src="https://static001.geekbang.org/resource/image/57/a5/57950f7c93f2b9yy197e93f36c1841a5.jpg" alt="">
+
+如果只看级别数字编号，头条的职级体系似乎是阶梯式的。但从实际的级别差异来看，它本质上还是跨越式的。比如头条的2-1和2-2，实际上对标的是阿里P6和P7，差别很大。
+
+头条的职级体系还有一个特点是，级别命名比较有特色。3-1以前是按照**专业线**来命名的，比如“初级工程师”。从3-1开始，就变成了按照**管理线**来命名了，例如“team领导层”。
+
+而且，这里的“team”和“部门”覆盖的范围很大。比如头条的3-2相当于阿里的P9，在阿里对应的管理岗位是总监，这个级别管理的范围已经远远不是我们通常所说的“team”这个范围了。因为我们说的一个team，一般是10人以内的小团队。
+
+这种命名方式偏向于从**职责范围**来描述能力，而不是从**专业程度**，在业界也算比较特殊的一类。
+
+## 滴滴：大家都是工程师
+
+至于另一家移动互联网时代崛起的大厂滴滴，它的职级体系跟阿里几乎是完美对应的，具体如下：
+
+<img src="https://static001.geekbang.org/resource/image/6e/95/6e9f067f6334c8767f5d1e0006a72d95.jpg" alt="">
+
+虽然滴滴的级别和阿里一一对应，但它的命名辨识度没有阿里那么高。
+
+首先，滴滴所有级别全都叫“工程师”，不像阿里，还会用“工程师”“专家”“研究员”这样的名字以示区分。
+
+其次，滴滴的命名也很有迷惑性，你很难通过名字判断等级高低。比如“专家”和“资深”，并不能很好地区分，“首席”和“杰出”更是难分高下。很多人第一次听到都会被误导，连我一开始也以为“首席”是最厉害的，没想到“平平无奇”的杰出工程师比首席还牛 ：）
+
+## 小结
+
+这一讲以阿里的职级体系为标杆，对比了几个知名公司的职级体系以及与阿里职级的对应关系，希望能够帮助你更好地评估自己在行业中大概的水平位置。
+
+我用一张表格来整理汇总了这几家公司的职级对应关系：
+
+<img src="https://static001.geekbang.org/resource/image/83/7a/83a2853491bf42bc859df3e0b518ea7a.jpg" alt="">
+
+需要注意的是，这个对应关系只是根据级别本身的要求和薪酬来对标的，并不是说实际面试的结果一定遵循这个对应关系。因为决定面试结果的原因，还有你的临场发挥、面试官本身的水平等多种因素。这也是很多人说的“要多面试几家”的原因之一，因为只有综合多次面试结果，才可以更准确地评估自己的水平。
+
+另外，美团的职级体系今年刚刚调整，现在还没有详细的参考资料，所以暂时没有加入对比。如果你有需要，可以在了解详细信息之后，按照我教你的对比原则自己做一个对比。
+
+## 思考题
+
+这就是今天的全部内容，最后留一道课后思考题给你吧。在你曾经的面试经历中，是否有面试定级与自己心理预期差别较大的情况（超出和低于预期都可以），你觉得可能的原因是什么？
+
+<img src="https://static001.geekbang.org/resource/image/b9/27/b90fa0bacd1983f555fc6a915b885f27.jpeg" alt="">

极客时间专栏/大厂晋升指南/加餐/加餐三 | 10000小时定律：成为大牛的秘密是什么？.md

@@ -0,0 +1,154 @@
+<audio id="audio" title="加餐三 | 10000小时定律：成为大牛的秘密是什么？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ca/c7/ca0d65ca18d05de5a9734e1ddae678c7.mp3"></audio>
+
+你好，我是华仔。
+
+在第16讲中我向你介绍了我自己总结的一套系统的学习方法，而这套方法的指导原则就是**10000小时定律**。
+
+那么这个理论是谁提出来的呢？它有用吗？要怎么用？用它的时候要注意些什么？今天这一讲，我将会带你探寻10000小时定律的来龙去脉，尝试破解成为大牛的秘密。
+
+## 10000小时定律的发展史
+
+在10000小时定律的发展过程中，一共有3个不得不提的关键人物，他们分别是本杰明·布鲁姆（Benjamin Bloom）教授，安德斯·艾利克森（Anders Ericsson）教授以及作家马尔科姆·格拉德威尔（Malcolm Gladwell）。
+
+### 布鲁姆：长期大量的练习
+
+布鲁姆是美国知名的教育心理学家，芝加哥大学的教授，在“教育目标分类”和“精通学习”这两个领域作出了很多贡献。
+
+1985年，他出版了一本书《如何培养天才》（Developing Talent in Young People），专门介绍怎么从青少年群体中发现天才。
+
+他研究了来自多个职业领域的120个成功人士的童年，包括音乐会上演奏的钢琴家、精湛的雕刻师、奥运会游泳运动员、世界级的网球运动员、杰出的数学家、杰出的神经学家等，涵盖了科学、艺术、体育、医学和工程等多个领域，想确认到底有没有“预测孩子未来成就的指标”（比如最广为人知的“智商”）。
+
+但是研究结论却推翻了这个想法，不存在这样普遍适用的指标，智商和孩子将来的成就**没有直接关系**。
+
+既然如此，那些成功人士又是靠什么获得成就的呢？难道是完全随机的吗？也不是。研究发现，对于大多数成功人士来说，最重要的因素是**家人的鼎力支持、长期大量的练习<strong><strong>和**</strong>专业老师的指导</strong>。
+
+但是对于“长期大量的练习”这个因素，布鲁姆没有明确研究出“长期”到底有多长，也没有提出“10000小时定律”。
+
+### 艾利克森：10000小时练习时间
+
+布鲁姆虽然没有研究出量化“长期”的方法，但是他的研究打开了一扇通往新领域的大门。于是很多学者开始跟进，其中美国佛罗里达州立大学的心理学教授艾利克森就发现了“**10000小时练习时间**”这个现象。
+
+艾利克森对柏林音乐学院的学生进行了研究。他让音乐教授根据潜力将小提琴学生分成三组，依次是顶尖小提琴家（Best） 、优秀小提琴家（Good）和音乐教师（Teachers），然后详细分析这三组学生之间水平差异的原因。结果他发现，只有**练习时间**这个因素是区分不同组的关键指标，顶尖小提琴家的练习时间比音乐教师多3倍。
+
+后来，他又研究了中年专业小提琴演奏家（Professionals）年轻时的练习时间，同样发现了练习时间这个关键因素。
+
+为了进一步证实结论，艾利克森又对钢琴演奏家进行了研究。这次他挑选了专业演奏家（Experts）和业余爱好者（Amateurs）进行对比，结果发现专业演奏家的练习时间是业务爱好者的10倍。
+
+在这两组研究中，他都发现了10000小时这个数据，如下图所示。
+
+<img src="https://static001.geekbang.org/resource/image/41/5b/41b77yy0b6fc91c177da2af370398d5b.jpg" alt="" title="引自艾利克森的论文">
+
+1993年，艾利克森把研究成果整理成了论文“[The Role of Deliberate Practice in the Acquisition of Expert Performance](https://www.researchgate.net/publication/224827585_The_Role_of_Deliberate_Practice_in_the_Acquisition_of_Expert_Performance)”发表。这篇论文不但描述了详细的研究细节，还介绍了各种跟成功有关的研究和它们的分析框架。
+
+但是，他也没有提出“10000小时定律”。
+
+### 格拉德威尔：10000小时定律
+
+后来，加拿大作家格拉德威尔根据艾利克森的论文结论，提炼出了“**10000小时定律**”，也就是说，**要想成功就必须要有10000小时的投入**。
+
+他分析了很多成功案例来证明“10000小时定律”的普适性，比如甲壳虫乐队走红前在德国汉堡的酒吧中演出超过10000个小时，Sun公司创始人比尔·乔伊的编程时间超过10000小时，微软公司创始人比尔·盖茨的编程时间也超过10000小时，音乐神童莫扎特真正成才前的作曲时间超过10000小时等等。
+
+2008年，格拉德威尔把他的观点写进了新书《异类：不一样的成功启示录》（Outliers: The Story of Success，以下简称《异类》）。这本书上架以后，雄踞《纽约时报》排行榜榜首20个星期，半年时间北美销售量超过了100万册，从此“10000小时定律”广为人知。
+
+<img src="https://static001.geekbang.org/resource/image/93/c0/935311b73c455c1235cc5ae1594ac4c0.jpg" alt="">
+
+## 10000小时定律剖析
+
+因为在《异类》这本书中，格拉德威尔只用了一章的篇幅来阐述10000小时定律，并不能涵盖艾利克森论文的完整内容，所以也引起了一些争议。
+
+批评者的主要观点是，10000小时定律**过于简化**了“如何才能成功”这个问题，会给人造成误导。
+
+事实上，无论是格拉德威尔还是艾利克森，都没有说过“只要练习10000小时就一定可以成功”。格拉德威尔《异类》中也探讨了很多和成功相关的因素，包括环境、文化和时机等；艾利克森在论文中也分析了家庭和个人等因素对成功的影响。
+
+所以，我们不必纠结10000小时定律到底是否全面。合理的做法是，把10000小时定律理解为成功**必要条件**，而不是**充分条件**。换句话说，没有10000小时的投入，很难成为专家，但有10000小时投入，也不一定能成为专家！
+
+要想通过10000小时的练习成为专家，还有几个关键的因素也不能忽略。美国作家丹尼尔·科伊尔的《一万小时天才理论》这本书就做了很好的总结：**精深练习、激情、伯乐三个因素是10000小时定律的关键**。
+
+<li>
+**精深练习**：你需要设定努力的目标，然后挑战自己的能力极限，不断地重复练习更高要求的技能才能提升自己。写10000小时“Hello world”不会让你成为编程高手，唱10000小时《两只老虎》也不会让你成为周杰伦。
+</li>
+<li>
+**激情**：10年10000小时的持续投入并不是小菜一碟，而是一项非常大的挑战，靠外力的强制或者自我意志力来强迫达成是不可能的，必须要有个人的激情作为持续投入的动力。所以你自己要喜欢这件事情，能够从中感受到快乐和满足。
+</li>
+<li>
+**伯乐**：每个领域都有大量的经验教训积累，单纯靠学员去试错来找到所有这些经验和教训是不可能的，需要有伯乐对学员进行观察，然后指出需要改正的地方和练习的方法，这样学员才能够快速提升。
+</li>
+
+《一万小时天才理论》整理了一个完整的[理论图示](https://19826785.s21i.faiusr.com/4/ABUIABAEGAAg-8eS6wUopvaO8QMwgAg40AQ.png)，非常具有参考意义。
+
+<img src="https://static001.geekbang.org/resource/image/b7/7a/b7f24e4dc9d2acyyd59eb437fd5e607a.jpg" alt="" title="引自《一万小时天才理论》（重新绘制）">
+
+从这张图里我们很容易看出来，单纯练习10000小时是不够的，还需要个人的激情作为动力，以及优秀的伯乐进行指导。这也就回应了人们对于“10000小时定律”的批评。
+
+## 互联网技术领域如何落地？
+
+不过，刚才我们提到的研究主要集中在音乐（小提琴、钢琴）和体育（足球、网球）等传统领域。在互联网时代，尤其是现在的移动互联网时代，10000小时定律的应用可能还会面临一些新的问题。
+
+### 1. 没有伯乐怎么办？
+
+传统领域的发展都有100年以上的历史，训练体系非常成熟，有很多优秀的专业教练能够对你进行指导。相比之下，互联网行业发展的历史就很短了，也不存在成熟的训练体系，更没有专业的教练能够像小提琴、网球那样进行一对一的指导和训练（要是能够请教练了，谁还996上班啊）。
+
+所以为了保证10000小时投入的效果，我们需要一些变通的方法。
+
+第一种方法是在团队内部找导师，不一定是主管，同事中的高手也可以。在代码Review、设计评审和方案讨论的时候，拉上导师一起参与，给你提建议。
+
+第二种方法是看书和学习线上课程。书籍和课程都是作者对知识和技能的一次梳理与整合，对经验和教训的一次总结和传承，所以购买一本书或者一门课就相当于请了一个教练，虽然它不能提供实时和具体的指导，但是我们可以通过它来详细地了解一个领域。
+
+第三种方法是参加行业会议。行业会议会邀请行业内的专家来进行分享，每个分享主题也都是很有价值的经验总结，对你的提升具有指导意义。
+
+第四种方法是参加线下的训练营。现在有一些机构开始尝试线下的训练营模式，邀请行业内的优秀人才作为导师，针对某个主题，集中进行一段时间的强化训练来提升学员的能力。训练营的模式和运动员教练很类似，能够实时地对学员进行指导，效果是最好的，但时间成本和资金成本也是最高的。
+
+### 2. 技术变化太快怎么办？
+
+跟传统领域相比，互联网行业的技术更新换代要快得多，比如最近10年影响比较大的新技术就有大数据、App开发、微服务、容器化和人工智能等；而且各个细分领域的技术变化也很多，典型的就是前端开发，包括jQuery、HTML5、Node和Vue/Reactor/Angular等。
+
+技术的快速变化确实会导致之前的一部分技术积累在新的环境下失去了原有的作用，比如现在我们很少用Flash来做开发了，但这并不意味着我们之前在领域的积累完全归零。
+
+首先，**很多基础的技术是不会频繁变化的**，比如操作系统、数据库、浏览器、网络等。比如虽然iOS和Android开发是最近十几年才兴起的，但它们的基础仍然是操作系统、计算机网络和编程语言这些“老”技术。
+
+其次，**新技术往往是在老的技术基础上进化出来的**，它们的目的是更好地解决老技术的问题。比如jQuery是为了解决JavaScript DOM编程太复杂的问题而设计出来的，Vue/Reactor/Angular等前端框架又是为了解决大型项目中使用jQuery所导致的难以维护和协同的问题而设计出来的。
+
+所以技术的变化不但不会让我们之前的积累失去价值，反而还会让我们之前的积累更有价值。绝大部分新技术的出现，都是业界顶尖的公司或者专家，结合他们以往的经验，再发挥他们天才的灵感才创造出来的。如果没有足够的经验积累，也就无法推陈出新。
+
+## 20小时学习法
+
+10000小时定律关注的是**怎么成为顶尖的领域专家**，比如小提琴家和钢琴家等。但是无论在日常生活还是工作中，我们都不可能在每个领域都成为专家，更多的时候只是想**熟练掌握一门技能**而已。
+
+比如我们大部分人学开车，只是为了上下班通勤、节假日旅游或者当司机赚钱，而不是成为F1赛车手；大部分技术人员学习Redis，也只是为了学习原理，方便在项目中使用，而不是想成为Redis的开发者。
+
+这种情况下，如果还只靠10000小时定律来规划学习安排，显然是不够的。
+
+美国学者乔希·考夫曼（Josh Kaufman）在《关键20小时，快速学会任何技能！》（The First 20 Hours: How to Learn Anything... Fast!）这本书中指出：如果学习目的不是“学精”（成为专家甚至大师），而只是“学会”（知道怎么用），那么只要花20小时，就可以快速掌握一项新技能。
+
+考夫曼并没有否定10000小时定律，而是指出针对不同的目标应该采取不同的方式，不要一概而论，如果全都套用10000小时定律，时间和精力肯定都不够用。
+
+所以他总结出了一套提升学习效率的“20小时学习法”，分为四部分：
+
+1. 分解步骤：把技能最大程度地细分，分成若干小步骤。
+1. 充分学习：基于分解步骤得到的小步骤，逐一练习。
+1. 克服困难：克服练习过程中的各种困难，包括生理、心理、情绪、工具、环境等。
+1. 集中练习：至少用20小时集中学习最重要的小步骤。
+
+虽然我暂时还没有看到针对20小时学习法的严谨的科学研究和证明，但它看起来确实很符合人的直观感觉。
+
+比如我们学车的过程，就非常符合20小时学习法：考试分为四个科目，每个科目有固定的考试项目，我们在教练的指导下针对考试项目逐一练习，最后通过考试拿到驾照，真正练习的时间也就差不多20小时。
+
+在互联网技术行业，如果你想初步入门某项技术，可以按照20小时定律来进行实践，不要看到某个技术就觉得要花费太多时间，还没开始就把自己吓到了，结果一直都不去学习。20小时定律同时也提醒我们，不要一上来深入研究源码这些，可以先从掌握基本的使用开始来学习技术，这样能够快速掌握基本的使用，然后有时间和有需要后再逐步深入。
+
+## 小结
+
+这一讲我跟你分享了10000小时定律和20小时学习法这两个跟时间相关的学习理论。其中10000小时定律是专业领域提升的总的指导原则，而20小时定律适合指导你快速入门学习单项技术。
+
+现在，我们回顾一下这一讲的重点：
+
+1. 布鲁姆发现了“长期大量的练习”是成功最重要的因素之一，阿利克森发现了“10000小时练习时间”是成功的关键指标，格拉德威尔提炼出了“10000小时定律”并加以传播。
+1. 单纯练习10000小时是不够的，还需要个人的激情作为动力，以及优秀的伯乐进行指导。
+1. 10000小时定律适用于在某个领域成为专家，而如果只是想熟练掌握一项技能，采用20小时学习法会更合适。
+
+## 思考题
+
+这就是今天的全部内容，留一道课后思考题给你吧。评估一下你在目前的专业领域大概投入了多少时间？如果你觉得自己投入了足够的时间，但是能力却没多大的提升，你觉得可能的原因在哪里？
+
+欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
+
+<img src="https://static001.geekbang.org/resource/image/d9/72/d908de16b08138d3d0cyye4715310e72.jpeg" alt="">

极客时间专栏/大厂晋升指南/加餐/加餐二 | 提名词：怎么夸自己才最加分？.md

@@ -0,0 +1,80 @@
+<audio id="audio" title="加餐二 | 提名词：怎么夸自己才最加分？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/93/08/93b2d9d37eaf98ecb5774147cfcc4408.mp3"></audio>
+
+你好，我是华仔。
+
+整个晋升流程从开始到最终结束，持续的时间可能长达3个月，很多环节是需要你和主管参与的。其中最关键的步骤当然是评审阶段的晋升答辩过程，但并不意味着其他环节可以随便应付一下，因为任何环节的事情做得更漂亮一些，都可能增加晋升通过的机会。
+
+对于很多人来说，自己专业上的工作可能得心应手，但是一遇到写材料的时候就头大，不知道怎样做才好。
+
+晋升流程的第一份重要材料，就是提名词了。今天我就跟你分享一下提名词的写作技巧，带你了解一下怎么夸自己才最加分。
+
+## 提名词的易错点
+
+在提名阶段，你需要提交一份提名词（也叫推荐语），通过200～300字概要地介绍自己的能力。这份材料对提炼和概括能力有比较高的要求，通常由主管来写，也可以由你自己写，然后给主管审核。
+
+很多人在写提名词的时候都会犯以下4点错误：
+
+第一，**罗列事项**，将自己做的项目一个一个流水账式地列出来，以为列得越多越好，比如“19年3月负责A项目架构设计，19年4月负责B业务开发，19年7月负责C版本开发。”
+
+第二，**写得太虚**，没有案例和项目说明，比如“具备优良的系统设计能力，对XXX业务非常熟悉，具备非常丰富的分布式经验。”
+
+第三，**没有条理**，所有的内容都挤在一段话里面，不能明显的看出有拿几个关键点，需要看材料的人费力去找。
+
+第四，**画蛇添足**，写一些跟目标级别几乎没有关联的内容。比如一个申请晋升P8的同学如果写“负责组织了团队的年度活动”，这是完全不合适的，如果想体现组织管理能力，至少也要写“负责部门TOP3战役中的YY战役”之类的。
+
+## 提名词的三大写作要点
+
+那么，提名词到底应该怎么写呢？我根据多年的经验，总结了三大要点：
+
+第一，**提炼重点**，抽象出3～5个和晋升强相关的关键能力点。
+
+比如你是Java后台开发，想要晋升P7，关键能力点就包括Java相关的能力、数据库设计的能力和业务的理解能力。相应地，提名词也应该围绕这些能力点来展开，不一定所有的点都面面俱到，但最关键的几个是必不可少的。
+
+第二，**虚实结合**，提炼出关键能力后，必须要给1～2个案例证明。
+
+比如能力概括写的是“具备优秀的并发设计能力”，那接下来就应该写“负责设计618 XX活动，线上峰值TPS 30K，单机TPS 5K”。案例尽量用数据证明，这里的数据可以是业务数据和系统数据，也可以是团队规模的数据；如果实在不能用数据证明，那也要描述事项的关键点，比如“从0到1搭建系统”或者“负责XX系统演进的架构设计，完成XX系统从1.0到2.0的升级”之类的。
+
+第三，**条理分明**，通过排版让成果与亮点一目了然，不要让管理者费劲去找。
+
+很多人在写材料的时候不喜欢换行，所有的内容挤在一起。这样就算内容写得再好，效果也大打折扣，因为这些材料一般都是通过表格汇总，放在一起来看的。对于一个P8/P9的管理者来说，他不是专门看某一个人的材料，而是在列表中同时看几十个人的材料，所以绝大部分都是扫读，不会逐字逐句去看。
+
+如果你的排版有问题，管理者看完也不一定能找到重点，或者他理解的重点跟你想展示的完全不一样，提名词的推荐效果就会大打折扣。
+
+## 提名词修改案例
+
+在这里，我放了一个提名词的反面教材，你能分析出它的问题，并提出相应的修改建议吗？
+
+> 
+小明同学具备优秀的设计能力，承担过多个关键业务的设计和开发，是团队的核心骨干，熟练掌握Java/Redis/MySQL等系统，具备高并发系统设计经验，承担了多个关键项目的负责人。
+
+
+这一份提名词的核心问题就是写得太虚，罗列了能力项，但是没有给出案例说明；并且是一口气写完的，没有排版，显得缺乏条理，评委没办法一目了然地看出有几个关键能力项。
+
+下面是我根据三大写作要点的要求修改之后的版本。
+
+> 
+小明同学具备优秀的设计能力，承担过多个关键业务的设计和开发，是团队的核心骨干，他的能力具体体现在以下三个方面：
+<ol>
+- 优秀的设计能力：熟练掌握Java/Redis/MySQL等系统，具备高并发系统设计经验，其19年设计的618活动系统，线上峰值流量达到TPS 20K；
+- 熟练掌握业务：对业务很熟悉，负责A项目/B项目/C项目的需求分析、方案设计、代码实现，项目上线后运行稳定；
+- 团队核心：能够承担关键任务的负责人，是2019年业务双十一的保障负责人，整个双十一活动流量峰值增长10倍，系统表现平稳，没有任何问题。
+</ol>
+
+
+你可以跟之前的版本对比一下，效果不是好多了呢？
+
+## 小结
+
+现在我们回顾一下这一讲的收获，写提名词的时候要记住下面三大写作要点：
+
+1. 提炼重点，抽象出3～5个和晋升强相关的关键能力点。
+1. 虚实结合，提炼出关键能力后，必须要给1～2个案例证明。
+1. 条理分明，通过排版让成果与亮点一目了然，不要让管理者费劲去找。
+
+## 思考题
+
+最后，留一道课后思考题给你吧。请你对照自己将要晋升的级别，尝试给自己写一下提名词，我会以评委视角帮你给出点评意见。（涉及到需要保密的项目，你可以做适当的模糊化处理。）
+
+欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
+
+<img src="https://static001.geekbang.org/resource/image/28/72/2808ca6a2ebd7a1dca4e3d97fb05c372.jpeg" alt="">

极客时间专栏/大厂晋升指南/加餐/加餐四 | 学习基础技术：你对“基础”的理解准确吗？.md

@@ -0,0 +1,228 @@
+<audio id="audio" title="加餐四 | 学习基础技术：你对“基础”的理解准确吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e8/2e/e8c49a1d4699b0ae3c979225c812f02e.mp3"></audio>
+
+你好，我是华仔。
+
+如果说IT技术领域有哪个说法最深入人心，那一定是“基础很重要”；而如果说有哪个说法让很多人花费了大量时间去学习，却没什么效果的话，那么多半也是这句话。
+
+我相信你曾经被人谆谆教诲过：做技术，基础很重要，一定要打好基础，比如说数据结构和算法、操作系统、编译原理等等；而且很多公司面试的时候，也采用了“面试造航母，工作拧螺丝”的方式，对基础能力的考察远远超过实际工作需要。
+
+结果，很多人费了很大的力气来提升所谓的“基础能力”，但是却发现根本看不到提升效果，工作中也用不上，白白浪费时间和精力。
+
+难道说“基础很重要”这个说法不对吗？其实这个说法本身没有问题，但是它模糊太笼统了，很难准确地理解，再加上一些口口相传的经验误导，搞得很多人都掉到坑里去了。
+
+这一讲，我来跟你聊聊到底什么才是“基础”，怎么提升基础技术才能事半功倍。
+
+## 典型的错误观点
+
+基础能力确实很重要，但是对于什么才是“基础”，业界并没有统一的定义。不过，有几个错误的观点流传很广，误导了很多人，其中最典型的就是以下三个：
+
+**1. 基础 = 底层**
+
+有些人以为越底层的东西越基础，比如操作系统内核（管控程序的运行），编译原理（所有编程语言的基础），CPU的指令和内存（程序运行的基础）……毕竟从字面意思来理解，底层的东西当然是基础了，而且是越底层越重要，因为越底层越通用。
+
+**2. 基础 = 源码**
+
+有些人喜欢“Show me the code”，认为只有源码才是最基础的东西，源码面前没秘密，要学基础就一定要去看源码，要自己能写出来才算真正掌握了“基础能力”。
+
+**3. 基础 = 不变**
+
+有些人认为不变的东西才是基础，比如数学、算法和数据结构、计算机组成原理、汇编语言、甚至包括离散数学和逻辑电路等，把这些学好了，以后无论做什么都用得上。
+
+很多人抱着这样的想法去提升基础，结果却没什么效果。
+
+我有个同事花了6个月时间去研究编译原理，感觉没什么收获，然后找我来讨论原因。
+
+我也有位朋友花了大量的时间来看Linux内核源码，看完好像知道了一些源码，但线上出了问题之后，连Linux定位工具都不会用。
+
+也有很多技术人员用了很多时间来背算法和数据结构的源码，但在实际工作中，要么不知道什么时候用什么算法，要么就滥用算法，明明一个很简单的逻辑也要硬套一个算法。
+
+## 核心就是工作相关
+
+**要想打好基础能力，首先要明确什么才是真正的“基础能力”**。
+
+我的观点是“**基础能力是指工作任务相关的基础能力，不是整个计算机技术的基础能力**”，核心就是“**工作相关**”，千万不要单纯照搬别人口中的基础能力。
+
+基于这个观点，我们来澄清一下前面提到的几个错误观点。
+
+**1. 基础！= 底层**
+
+如果底层技术和当前的工作内容没有关系，那就不是工作要求的基础能力。
+
+比如CPU指令和内存寻址，对于做嵌入式开发来说是基础，而对于做Android/iOS业务开发来说就不是基础了。
+
+**2. 基础！= 源码**
+
+如果当前的工作并不需要我们去修改其源码或者理解其源码细节，那就不是工作要求的基础能力。
+
+比如Linux内核源码和Hotspot虚拟机源码，对于做虚拟机开发来说肯定是基础，但是对于Java业务开发来说就不是基础了。
+
+**3. 基础！= 不变**
+
+不变的东西确实应用很广，但是随着技术的发展，不变的东西越来越稳定，封装也越来越抽象，基本上就可以认为不再需要关注它了。
+
+这就像电一样，我们天天用，电学的原理，你只要上过中学基本都知道。但是我相信，现在没有人在使用电器的时候，还要去翻一翻物理课本吧。
+
+很多人为了证明“基础很重要”，都会举建房子的例子，因为地基是房子的基础。
+
+但其实认真思考一下，就算是建房子，打地基的方式也是不断变化的，古人用夯土打地基，后来用石头打地基，现在用钢筋水泥打地基，而且工人在用钢筋水泥打地基的时候，也不需要知道“如何制造水泥”“如何炼钢”这样的基础知识。
+
+麻省理工大学以前有一门非常火的课程，叫“计算机程序的构造和解释”（SICP，Structure and Interpretation of Computer Programs），但后来他们停止了这门课，给出的原因如下（[Why MIT stopped teaching SICP](http://lambda-the-ultimate.org/node/5335)）：
+
+> 
+<p>They felt that the SICP curriculum no longer prepared engineers for what engineering is like today.<br>
+Sussman said that in the 80s and 90s, engineers built complex systems by combining simple and well-understood parts. The goal of SICP was to provide the abstraction language for reasoning about such systems.<br>
+Today, this is no longer the case. Sussman pointed out that engineers now routinely write code for complicated hardware that they don’t fully understand (and often can’t understand because of trade secrecy.)<br>
+The same is true at the software level, since programming environments consist of gigantic libraries with enormous functionality.</p>
+
+
+简单来说，就是SICP课程不是为今天的程序员准备的，而是为20世纪80～90年代的程序员准备的。
+
+这是因为那个时候的程序员是通过组合简单和深刻理解的部件（其实就是指从底层开始构建）来构建复杂系统，而现在的程序员在复杂的商业硬件和大型的开发库上面来构建复杂系统，就算程序员想了解这些底层硬件和开发库，也可能因为商业秘密等原因无法做到。
+
+## 举例说明
+
+按照工作相关这个原则，我举两个常见的例子对比说明一下。
+
+**1. Java业务开发 vs AJDK开发**
+
+它们都是Java相关的开发，我们假设一个是用Java来在Linux平台上基于Spring Boot框架完成业务开发，另一个是要负责阿里的AJDK（基于Hotspot实现，目前已经[开源](https://github.com/alibaba/dragonwell8)）开发，那么它们的基础能力差异如下表所示：<br>
+<img src="https://static001.geekbang.org/resource/image/e1/41/e19a45e1a21f30308cf485772eb95541.jpg" alt="">
+
+**2. Android业务开发 vs Android动态化框架**
+
+它们都是Android相关的开发，我们假设一个是做业务开发，一个是开发动态化框架，那么它们的基础能力差异如下表所示：<br>
+<img src="https://static001.geekbang.org/resource/image/74/17/742b3a780297852459639cyy46459117.jpg" alt="">
+
+## 细化基础范围：技能图谱
+
+明确了“工作相关”这个原则之后，提升基础的第一步，就是使用**技能图谱**的方式，从以下4个维度来细化基础能力的范围。
+
+1. **工具**：工作中常用的工具，比如IDE、编程语言、问题定位工具和版本管理工具等。
+1. **生态**：系统或者产品运行时依赖的所有组件或者系统，比如第三方库、中间件、数据库、文件系统和游戏引擎等。
+1. **容器**：系统或者产品在哪里运行，比如Android、iOS、Linux、浏览器和云服务器等。
+1. **原理**：需要掌握的原理知识，常见的有计算机网络和数据结构等。
+
+<img src="https://static001.geekbang.org/resource/image/c8/0d/c8e7e8a6b6b874126d44cea7e181230d.jpg" alt="">
+
+我们以前端开发为例，基础能力的范围如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/78/d2/78b17e75655a786a21d27afb812ac6d2.jpg" alt="">
+
+注：
+
+1. 上图仅为示例，不代表完整的前端领域基础能力范围。
+1. 图中没有涵盖“JavaScript编程语言”，因为这个可以说是核心能力，不是基础能力。
+
+有了技能图谱之后，我们就能够大致地了解每个技术领域的基础能力到底包括哪些了。
+
+## 提升技术的技巧
+
+明确了基础能力的定义和范围，我们就可以把有限的时间和精力用在更有价值的地方，避免眉毛胡子一把抓，从而实现投入产出效率的最大化。
+
+但是，单个基础技术怎么学，这也很关键，否则学习还是可能事倍功半。
+
+### 常见学习误区
+
+常见的学习误区有两个。第一个是认为，**既然是基础技术，那肯定是掌握得越深越好**，比如数据结构和算法、计算机网络和操作系统这些，几乎是所有程序员的基础，所以每一项都应该深入了解。
+
+但是这样做还是会导致你浪费很多时间和精力。
+
+以数据结构和算法为例，很多人学习的时候都采用了背代码的方式，认为只有自己能手写这些代码，才算是真正的掌握。
+
+而且，有些面试官在面试的时候喜欢让应聘者写简单的算法代码，进一步强化了这样的认知。
+
+我就曾经跟几个这样的面试官聊过，对话过程几乎一模一样，很有意思：
+
+问：“为什么你们要用这种方式来判断应聘者的水平？”
+
+答：“如果一个程序员连个简单的算法都写不出，那就说明他肯定不合格！”
+
+问：“那你们要自己修改算法和写数据结构吗？”
+
+答：“怎么可能？直接用Java库里面的，自己写的质量怎么跟Java库的比啊？”
+
+问：“一般你们考什么算法和数据结构？”
+
+答：“冒泡啊、快排啊、链表、字符串之类的？”
+
+问：“那为什么你们不要求手写B+树，不手写ConcurrentHashMap这些呢？这些难度更高。”
+
+答：这个要求有点高啊，现场写不完，其实我自己也写不出……
+
+在上面的对话中，我们可以看到，其实这种面试方式就属于“面试造航母，工作拧螺丝”，不能判断应聘者水平高低，只能反映出他们面试准备程度的高低；而且能考的也就是这几个简单的数据结构和算法题目，因为面试官自己也只能看懂这几个。
+
+第二个误区是认为，**要完全掌握基础，一定要掌握源码**。
+
+这个观点更加容易导致你投入大量时间却没什么收获。尤其是Linux内核源码、JVM虚拟机源码和MySQL源码这些，如果你不具备深厚的C/C++的开发功力，基本上连看都看不懂，更不用说考虑代码规模和复杂度了。
+
+即便是Netty这些代码相对少一些的开源项目，就算你拥有很强的Java开发技术，要想每一行代码都了解，也要花非常多的时间的。
+
+因为一个成熟的开源项目，都是几十个人用了很多年的时间慢慢积累的，你一个人想一下子就全部搞懂所有代码，这是不现实的。而如果你把时间浪费在这个地方，用来提升其他更有用的技术的时间就没有了。
+
+### 如何判断学习深度？
+
+所以说，就算是同一个基础技术，不同的技术人员学习的深度也是不同的。核心的原则还是之前提到的“工作相关”，根据工作内容来决定基础技术的学习深度。
+
+下面，我举几个常见的例子来说明。
+
+**1. 数据结构和算法**
+
+对于绝大部分开发人员来说，主要是熟悉数据结构和算法的原理、优缺点与应用场景，还有自己所用的编程语言提供的算法和数据结构。
+
+而对于中间件开发的技术人员来说，在做极致的性能优化的时候，Java的ConcurrentHashMap之类的并发数据结构，就需要掌握算法的原理和代码实现细节了。
+
+**2. 计算机网络**
+
+对于绝大部分开发人员来说，能够熟练掌握抓包工具抓取TCP/IP包，并且能够看懂包信息，定位网络问题就行了。
+
+而对于运维人员来说，抓包、路由协议、组网配置等就需要深入掌握了。
+
+**3. 操作系统**
+
+对于绝大部分开发人员来说，掌握基本的操作系统原理和概念，能够使用操作系统提供的工具来定位程序问题就行了。
+
+而对于驱动开发、内核模块开发的技术人员来说，操作系统原理、实现机制和代码都需要深入掌握。
+
+### 如何让理解更加深入？
+
+明确学习深度之后，因为基础知识点比较多，看起来比较散，所以你可能学了很多知识，但是不知道它们之间的关联关系，理解不够全面和深入。
+
+应对这个问题办法就是[第19讲](https://time.geekbang.org/column/article/331463)中介绍的“链式学习法”，通过领域分层将基础技术和顶层的实用技术关联起来，形成系统化的理解，这样能够理解得更深，记得更牢固。
+
+### 基础积累会不会浪费？
+
+看到这里，你可能会有疑问：判断基础能力范围和基础技术学习深度的原则都是“工作相关”，那么如果工作发生变化，岂不是很多基础技术的积累都白费了？
+
+这里就要看所谓的“变”具体是怎么变。
+
+如果是前后两个工作的领域基本一致，那么基础技术的积累基本上是可以通用的。比如我曾经从PHP服务端开发转为Java服务端开发，在数据结构和算法、计算机网络、数据库和操作系统方面的积累完全可以通用。
+
+但如果前后两个工作领域差异很大，那么基础技术的积累确实可能无法通用。比如我的一位同事从Android开发转为服务端后台开发，虽然数据结构和算法、计算机网络可以通用，但是SQLite数据库和Android操作系统这些就不能通用了。
+
+所以跨领域转岗一定要慎重，要转的话就尽早转，越晚损失越大。
+
+## 我的实际经历
+
+我刚去UC的时候，是用C/C++做中间件，对高性能和网络都有比较高的要求。于是我深入地学习了CPU和网络的一些基础知识，最典型的就是SMP架构的CPU 的False Sharing（伪共享）问题。
+
+这个知识点理论上属于计算机组成原理，但是计算机组成原理一般只会写CPU有L1/L2/L3 Cache，很少提到多核CPU的的Cache Line（缓存行）对齐会导致False Sharing问题，并且对性能有很大影响。MySQL也被这个问题给坑过，而Disruptor的高性能则是采用padding避免了这个坑。
+
+你看到这里，可能会急着想去看看我说的False Sharing到底是什么。别急，这个基础知识点在我后来负责业务开发的时候就没用了，因为接触不到这个深度。
+
+但是做业务开发的时候，MySQL的索引原理和Elasticsearch的倒排索引这些基础理论就很有用了，因为你要设计合理的索引和存储方案。不过这个时候，你也不需要把B+ tree的数据结构写出来，只需要知道原理，就可以设计合理的索引和存储方案了。
+
+## 小结
+
+现在，我们回顾一下这一讲的重点。
+
+1. 基础能力是指工作任务相关的基础能力，不是整个计算机技术的基础能力。基础不等于底层，不等于源码，也不等于不变。
+1. 提升基础的第一步，就是使用技能图谱的方式，从工具、生态、容器和原理这4个维度细化基础能力的范围。
+<li>提升基础技术的技巧包括：根据工作内容来决定基础技术的学习深度；通过链式学习法将基础技术和实际用到的技术系统串起来；跨领域转岗要慎重，要转的话就尽早转。<br>
+<img src="https://static001.geekbang.org/resource/image/ea/78/eae375bb7971a24d7b4a15bed39dff78.jpg" alt=""></li>
+
+## 思考题
+
+这就是今天的全部内容，留一道课后思考题给你吧。按照这一讲的内容，你能够整理出你当前工作岗位要求基础技术包括哪些，以及你需要学到怎样的深度吗？
+
+欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。<br>
+<img src="https://static001.geekbang.org/resource/image/fy/c6/fyyeedd06a76490e2ac7ae173fe1a2c6.jpeg" alt="">

极客时间专栏/大厂晋升指南/加餐/放学别走 | 如何画好领域分层图？.md

@@ -0,0 +1,119 @@
+<audio id="audio" title="放学别走 | 如何画好领域分层图？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b4/52/b4787040f8748054b08c20513af96152.mp3"></audio>
+
+你好，我是华仔。
+
+在[第19讲](https://time.geekbang.org/column/article/331463)中，我为你介绍了用于提升技术深度的**链式学习法**。链式学习法的第一步，就是要明确一项技术的深度可以分为哪些层，并画出**领域分层图**和**细节分层图**。
+
+其中细节分层图基本上可以按照固定的模板去画（接口设计、设计原理、设计方案和实现源码），但是领域分层图并没有统一的模板，因为不同技术领域的分层方式可能会有很大差异。
+
+我之前没有详细讲解领域分层图的画法，而是跟你说“尝试画图本身就是一个梳理结构、强化认知的过程”。
+
+因为我想强调的是：**画图本身的技巧和效率并没有那么重要，对你成长帮助最大的，是为了画出这张图而去整理、思考和探索的过程。**
+
+## 不用担心画得不准确
+
+你可能会担心，如果领域分层图画得不准确怎么办？
+
+**首先，领域分层图本来就是需要迭代优化的，很少有人一开始就能画得非常准确。**
+
+实际的情况是，你先画一个初稿，然后通过整理、思考和探索，对相关技术的理解更加深刻和全面，发现原来存在的一些问题，比如分层关系不合理、某一层遗漏了一些技术点等，然后再进行修改，经过不断地迭代优化，最终得到比较准确的版本。
+
+**其次，领域分层图就算画得不够准确，你学习的过程也没有白费。**
+
+一般情况下，你不会错得太离谱，你学到的内容就算跟当前想学的技术关联没有那么强，但下次提升另一项技术的深度时，很可能就用上了。而且随着你积累的经验越来越丰富，以后再画领域分层图的时候就会越来越熟练。
+
+当然，你可能过几个月就要参加晋升了，没有多少时间用来慢慢试错迭代；或者你真的对自己的探索能力没什么把握，必须掌握一个具体可靠的画图方法才能放心。
+
+考虑到这些情况，这一讲我就分享一下画领域分层图的具体经验吧。
+
+## 拿来主义
+
+最简单的方法当然就是**拿来主义**，你可以找团队内部熟悉某项技术的高手来帮你画，也可以根据网上搜到的相关文章或者思维导图来整理。
+
+这种方法的好处是耗时少，也不会走偏，但是它也有缺点。
+
+首先，**你自己的理解深度还是不够**，因为你缺少了自己去探索的过程。
+
+其次，**对外界的依赖太高**，你并不是刚好每次都能找到这样的高手，而网上的资料也存在不完整、老旧过时甚至错误的风险。
+
+最后，**这种方法往往只适合热门、成熟的技术领域**，而对于冷门、新兴的技术领域，你能拿来的内容非常少，还是得靠自己去产出。
+
+## 画领域分层图的步骤
+
+那么，假设你对某个技术完全不了解，团队里也没有人熟悉，在网上又只能找到非常基础的资料，这个时候，你要怎么画领域分层图呢？
+
+以下是我最近学习ClickHouse时的画图过程，供你参考。
+
+**第一步，搜集资料。**
+
+有官方文档的情况下，先看官方文档是最保险的，比如我看的就是ClickHouse的英文[官方文档](https://clickhouse.tech/docs/en/)，它已经很全面了。
+
+你可能会有疑问，如果我想学的技术不像ClickHouse这样有比较成熟的官方文档，该怎么办呢？
+
+我的想法是，成熟的项目一定有成熟的文档。如果一个项目没有官方文档或者官方文档很烂，只能靠你自己看代码去摸索，那么我建议你先不要去学。
+
+首先，这样学效率太低了；其次，这说明项目本身就有问题，要么是还不成熟，容易误导你，要么就是没什么人维护，出了问题也没人管你，无论哪种情况你都很容易踩坑。
+
+当然，不同的学习对象有不同形式的资料，但不管什么类型的资料，我推荐你首先都要看权威资料，包括官方文档、经典书籍、研究论文等，比如ClickHouse的官方文档、《UNIX环境编程》《TCP/IP详解》和谷歌的大数据论文等，都属于各自领域的权威资料。
+
+**第二步，挖掘技术点。**
+
+我根据[官方文档](https://clickhouse.tech/docs/en/)中的内容，挖掘出了一些相关的技术点。
+
+> 
+ClickHouse® is a **column-oriented database** management system (DBMS) for online analytical processing of queries (**OLAP**).
+
+
+> 
+<p>Why Column-Oriented Databases Work Better in the **OLAP** Scenario？<br>
+Column-oriented databases are better suited to OLAP scenarios: they are at least 100 times faster in processing most queries.</p>
+
+
+这两段话涉及两个技术点，**列式数据库**（Column-Oriented Database）和**OLAP**。
+
+> 
+There are two ways to do this:
+<ol>
+- A **vector** engine. All operations are written for vectors, instead of for separate values. This means you don’t need to call operations very often, and dispatching costs are negligible. Operation code contains an optimized internal cycle.
+- **Code generation**. The code generated for the query has all the indirect calls in it.
+</ol>
+
+
+而这段话又涉及两个技术点，**矢量计算**（Vector）和**代码生成**（Code Generation）。
+
+你可以看到，光是简单的一篇ClickHouse介绍文档，我已经挖掘出了至少4个关联的技术点。
+
+**第三步，针对技术点学习。**
+
+比如你已经挖出了列式数据库这个技术点，但是没有相关的积累，那么你可以立刻开始先学跟它相关的内容，也可以初步看完ClickHouse的资料之后再来学习。具体采用哪种方式，根据你的个人习惯来选择就行了。
+
+我看到列式数据库这个技术点之后，就在网上找到了一篇不错的[文章](https://zhuanlan.zhihu.com/p/35622907)，里面又引出了HBase、NSM、DSM等相关的概念。当然，只看这一篇文章肯定是不够的，我会结合多篇资料，最后形成综合的理解。
+
+**第四步，画出初稿。**
+
+**学习了解了这些重要的技术点之后**，我尝试整理了ClickHouse领域分层图的初稿，如下所示：
+
+<img src="https://static001.geekbang.org/resource/image/82/1b/82fd120a404391bc495653ac7ea3c51b.jpg" alt="">
+
+**第五步，迭代优化。**
+
+你可能会觉得这张图好像比较简单。不过没关系，在阅读资料和思考的过程中，我会继续**迭代优化**这张图，比如之后还可能加上矢量计算相关的CPU结构。
+
+即使是这张简单的领域分层图，内容已经足够我学上几个星期了，我会以这张图为基础先开始学，学习的过程又会拓展我对这个领域的认识，促使我继续迭代优化。
+
+当我把图片上的内容学完之后，我可以通过培训的方式给团队讲解ClickHouse，回答他们的疑问，借助群众的力量来帮助自己加深理解，进一步迭代优化这张图。
+
+## 小结
+
+现在，我们回顾一下这一讲的重点内容。
+
+1. 画领域分层图的技巧和效率并没有那么重要，对你成长帮助最大的，是为了画出这张图而去整理、思考和探索的过程。
+1. 画领域分层图最简单的方式是拿来主义，找团队内部熟悉某项技术的高手来帮你画，或者根据网上搜到的相关文章或者思维导图来整理。
+1. 如果拿来主义不能满足你的需求，或者你对自己有更高的要求，可以通过5个步骤来画领域分层图：搜集资料，挖掘技术点，针对技术点学习，画出初稿，迭代优化。
+
+## 思考题
+
+这就是今天的全部内容，最后留一道课后思考题给你吧。参考这一讲的方法，你能够把自己最近想提升的一项技术的领域分层图画出来吗？
+
+你可以用文字的形式在留言区分享出来，让我来帮你把把关。相信经过深度思考的回答，也会让你对知识的理解更加深刻。<br>
+<img src="https://static001.geekbang.org/resource/image/6c/c2/6ced1462d2d48df3d44d856ef4eca5c2.jpeg" alt="">