mod

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/39 | 职业倦怠：如何面对？.md

@@ -0,0 +1,88 @@
+<audio id="audio" title="39 | 职业倦怠：如何面对？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ae/59/ae0a979841b8ac45772fdc2369ff5e59.mp3"></audio>
+
+从今天起，咱们专栏即进入第 4 个大主题——“**徘徊：道中彷徨**”。成长的途中，我们总会面临很多的困扰与惶惑，这些困扰和彷徨很多都关乎选择，只有了解并认清这类困惑，我们才可能做出最合适的选择。
+
+职业生涯的路上，每个人都会碰到**职业倦怠期**，我也不例外。曾经好几次，我都陷入其中。如今从中摆脱出来后，我就想尝试搞清楚这样一种状态的根源，思考一种方法来缩短它持续的时间，或者说增加它出现的时间间隔。
+
+那职业倦怠到底是怎样的一种感受呢？
+
+## 倦怠感
+
+1974年，美国临床心理学家弗罗伊登贝格尔（Herbert J. Freudenberger）首次提出“**职业倦怠**”的概念，用来指**人面对过度工作时产生的身体和情绪的极度疲劳**。
+
+职业倦怠感想必你也不陌生，一般将可以明显感知到的分为两种。
+
+**一种是短期的倦怠感**。它出现的状态，可以用两个英文单词来形象地表达：Burnout（燃尽，精疲力尽）和 Overwhelm（难以承受）。
+
+作为程序员的我们想必最能感知这样的状态，因为我们处在现代信息工业时代的最前沿，快节奏、高压力、大变化的环境很是常见。应对这样的环境，我们就需要更多的 “燃料” 和更强的承受力。但有时，环境压力突然增加，短期内超出了我们的负载能力，难免出现“燃尽”（Burnout）的时刻，并感到难以承受（Overwhelming）。
+
+此时，就进入了短时的倦怠期。这种短期的倦怠感觉其实和感冒差不多常见，年年都能碰上一两次，应对的办法其实也很简单：休个年假，脱离当前的环境，换换节奏，重新补充 “燃料”，恢复精力。就像感冒，其实并不需要什么治疗，自然就能恢复。人，无论生理还是心理，都是一个 “反脆弱” 体，“凡不能打垮我的，必使我更强大”。
+
+**另一种更可怕的倦怠感是长期的**，它与你对当前工作的感受有关。
+
+有些人把 “上班” 看作工作的全部，那么这样的人去上班一般都是被动的、勉强的。这样的人就是普遍存在的 “混日子” 的上班族，虽不情愿，但又没有别的办法，毕竟不能失去这份工作的收入。而这种 “混日子” 的状态，其实就是处在一种长期的职业倦怠期。
+
+其实真正的工作，应该是一种积极的、有目标的事情，它能让我们实现对自我和他人的价值，并且乐在其中。但即使一开始我们是在做这类真正的 “工作”，时间久了后，也难免碰到职业倦怠感，这时我们可能就会困惑：难道我已不再热爱现在的工作了？对于这种状态，有一个说法是这样的：
+
+> 
+倦怠，意味着你在这一关打到头了，而新的一关的钥匙，就在你手上。
+
+
+遇到这种情况的本质，其实是我们自己的 “工作区” 发生了转移和变化，从而脱离了原来的 “工作态”，碰到了倦怠感。
+
+当倦怠感出现时，“工作态” 就隐退了；而为了消除倦怠感，我们就需要找回 “工作态”。
+
+## 工作态
+
+工作态，如其名，是一种工作的状态，一种让我们在工作中感觉到美好的状态（beautiful state）；是做我们喜欢的工作时表现出来的一种状态。
+
+每周我们有五个工作日，但不代表我们每个工作日的工作时间都能处在 “工作态”。甚至很多时候我们都无法处在 “工作态”，但却又必须在某个时间点前完成工作。这样的日子久了，就难免会滋生倦怠。
+
+据说有一半的人，每天下班回家上床睡觉前，都会想想诗和远方，早上起床都有一种不想再去上班的冲动；当感到这种冲动时，差不多就进入了工作倦怠期，并对当前的工作产生了倦怠感。
+
+去年有部电影叫《魅影缝匠》，主角是一名裁缝。他每天起床后，从早餐时刻开始就进入了他的 “工作态”，排除和避免一切干扰，专注于他的服装设计工作。其实，这个电影本身的故事并不算吸引我，只是电影中这位缝匠的 “工作态” 深深地打动了我。也许，这就是一种同为创作性工作带来的共情吧。
+
+现代心理学上有个概念叫 `Flow`，一般译作 “心流”，也是一种工作状态，它是人在专注进行某些行为时所表现出的心理状态，比如艺术家创作时的状态。在此状态下的人们，通常不愿被打扰，也比较抗拒中断，个人的精神力将完全投注在某种活动上，同时还会伴随高度的兴奋与充实感。
+
+那么 “工作态” 和心流有何不同？“工作态”，其实是我自己发明的一个概念，它的定义覆盖的期限更长久，就像长跑中的节奏；而心流的定义更像是一种 “工作态” 的局部过程表现，像一次短程冲刺。你没法长时间地处于心流状态，但在相当长的一段时间周期内，你可以处在 “工作态” 中，就像电影中那位缝匠，几十年如一日的，每天早晨都会自动进入那样一种 “工作态”。
+
+职业倦怠期，显然是与 “工作态” 互斥的一种状态。所以，要脱离职业倦怠期，最有效的方式就是进入 “工作态” ；而进入 “工作态” ，最核心的地方在于找到自己的 “工作区”。
+
+## 工作区
+
+关于工作区，我想借用下面一张图来展示。
+
+<img src="https://static001.geekbang.org/resource/image/7f/d0/7f7393885c1856c25d7873f19a063bd0.png" alt="">
+
+“工作区” 的概念不是我发明的，其原始概念图来自[国外一个站点](https://liberationist.org/change-tools/the-work-zone)，我将其翻译和重绘了一下。其中定义了关于工作的三个区域，也就是说每一份工作都包含了这三个方面：
+
+- 目的意义 Purpose
+- 职业生涯 Career
+- 工作岗位 Job
+
+**目的意义**，这是工作的终极之问。它决定了你的很多选择，以及你接受什么、拒绝什么，是工作愿景背后的灵魂所在。每个人工作都会有自己的目的与意义，而且还会随着工作过程发生变化（或者说进化更合适些）。追寻目的与意义，这可能是你、我一生的工作。
+
+**职业生涯**，是个人一生职业愿望的追寻过程。它由长期目标驱动，是追寻 “目的意义” 的一条你所期望的路径。而这条路径并不唯一，它因人而异，因你的 “目的意义” 而异。它构建在你工作过程中的所有经历、经验、决策、知识、技能与时运的基础之上。
+
+**工作岗位**，这不过是你现在上班的地方，包括了位置、角色、关系、职责与薪酬的总和。
+
+这三个区域会有交集，这里我举个实际的例子。假如你工作的 “目的意义” 非常现实，就是希望有更多的收入改善家庭生活，住更大的房子，开更好的车。而现在的 “工作岗位” 能够提供这样让你满意的收入水平，那么你就会感到 “快乐幸福”。
+
+而若你对 “职业生涯” 路径的期望是从程序员到架构师，甚至再到 CTO，当前的 “工作岗位” 能提供这样的发展路径，那你就会充满 “激励驱动”。显然，职业生涯一路达到 CTO，收入水平会更高，与你的现实 “目的意义” 相符合，那你就会感到 “成就满足”。
+
+如图中所示，这三者相交的那个位置，就是你的 “工作区”。在这个区域内，工作让你有驱动力，感到快乐，充满成就感。找到了 “工作区”，很自然就会进入 “工作态”。
+
+当职业倦怠时，自然是远离了工作区，这时很容易产生的一个决策是：换一份工作。我曾经就做过这样的决策。换一份工作没有对错好坏之分，它能改变你的工作岗位，甚至也能改变你的职业生涯路径，但它唯一不能改变的就是你对 “目的意义” 的思考与认识。
+
+做自己所爱，是对的；爱上自己所做，也是对的，关键就是要找到什么在真正驱动你前进。
+
+丹麦哲学家索伦·克尔凯郭尔（Søren Kierkegaard）说过一句话：
+
+> 
+Life can only be understood backwards; but it must be lived forwards.
+只有向后回首时才能理解生活，但生活却必须向前。
+
+
+当你回首职业生涯的来路时，终于理解了职业倦怠，但前路之上，还会碰到它，而你已经知道该如何面对它了，对吧？
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/40 | 局部最优：如何逃离？.md

@@ -0,0 +1,75 @@
+<audio id="audio" title="40 | 局部最优：如何逃离？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/63/f2/63db4c8b35fd05f578f28d37f24043f2.mp3"></audio>
+
+之前看过一些关于算法方面的书，提到了一些最优化问题。最优化问题在现实中非常常见，比如工程设计中，怎样选择设计参数，使得设计方案能以尽量低的成本预算满足设计要求。而近年来热门的机器学习建模也是一个最优化问题，基于一组已知的数据去构建一个模型，让这个模型去适配未来未知的数据达到最优，然后求解关于这个模型的参数。
+
+在求解最优参数的算法中，很多都有一个缺陷，就是容易达到一种局部最优点，即：**参数的选择尝试收敛到了一小块范围内，无论再怎么尝试变化都没法取得更优的结果**。而从全局来看，这并不是最优的选择，但算法此时就进入了一种尝试的徘徊状态，这就是局部最优点，但算法并不知道这到底是不是全局最优的。
+
+对于我们这些自诩智能的人，在成长的路上，其实也经常陷入这样的成长局部最优点。
+
+## 爬山
+
+关于成长最形象的类比便是爬山，但爬到山顶的路并不总是向上的。
+
+我长居成都，每过一阵就会去爬一回成都附近的青城山。像青城山这种著名景区的山，总有很多路标告诉你，沿着这条路一直走，你就能到达山顶。即使这条路有时会向下走，让你产生下山的感觉，但你也不会动摇，因为路标已经告诉你了，山顶就在前方，那里才是你的目的地。虽然成长这一路就像爬山，成长路上的感觉也和爬山相似，但不同的是，成长的路上并没有清晰的路标告诉你山顶在哪里。
+
+有时你很幸运地爬上了一个高点，你并不知道这个高点是否就是山顶了，因为再往前走，无论哪个方向的路都是向下的，你会心下疑惑：这是要下山了吗？
+
+即便你明确知道了这个高点便是此山的山顶，有时也会遗憾地发现原来这山只有这么高啊。就像青城山名气虽大，但山并不高，海拔只有 1200 多米。你站在山顶，虽然是此山的最高点，但你知道这不过你成长路上的局部最优点，继续前行，则不可避免地先要下山。
+
+爬山的全局最优点，应该是珠峰顶，但不是所有人都能爬得上去的。每个人都有自己期望的一个高度，比如我登高爬山是想看看云海，但青城山的高度还不够，也许峨眉山（海拔 3100 米）就够了。
+
+我们在成长（爬山）的路上，会进入局部最优点。一方面可能是 “山形” 所致，要继续上山的路需要先向下走，而向下的疑虑又会让我们徘徊不前。另一方面，可能是此 “山” 只有这么高了，就像青城山，你想看云海，可能就得换一座山了。
+
+## 徘徊
+
+所有的局部最优点，都意味着我们爬到了一定阶段，在这个位置徘徊不去，恋恋不舍。
+
+十多年前，我刚毕业找工作那时，外企在国内的吸引力可以相比今天互联网行业的头部企业。我也想进入外企这座 “山”，屡屡尝试，但每次都卡在英语口语面试，屡屡失败。同寝室的另一位同学则顺利进入一家国外的电信行业外企，获得的 offer 薪酬比我们平均高了 50%，让人羡慕不已。
+
+数年后，我们同学再次相聚，听闻该外企在中国已经被当时的华为、中兴竞争的步步退缩，业务缩水不少，已有裁员迹象。当时，同学会上，都劝这位同学早做打算，但他表现为瞻前顾后，徘徊不决，还想看看情况。一年后，我当时也正在做浙江省的电信项目，该同学所在公司的系统正被我当时的公司取代，没多久就听闻该公司进入了破产清算。
+
+曾经领先的电信行业设备服务公司，就这样退出了市场。那位同学就算曾经站的位置再好，“山” 都塌了，何谈继续攀登。这样的情况，有时主动的转身，比被动的离开可能要从容得多。
+
+而另一个朋友的故事，经历过后再回首一看，更让人扼腕叹息，可惜当时的我也是见识有限，给不了更好且更坚决的建议与支持。
+
+那时，小米公司刚成立不到一年，第一款手机尚未发布，正处在快要井喷发展的扩张期，到处找人，正好也找到了我这位朋友。但朋友觉得自己所在公司也还不错，也能成长，正“爬山爬得不亦乐乎”，遂放弃。
+
+过了两年，朋友又有了另一次机会，微信来了，给了机会，但她正考虑准备生孩子，同时又考虑在当前公司已经熟悉，且业务稳定，换新公司难免需要打破现状和当前的节奏，遂徘徊一阵，选择停留。
+
+后来再看，以前公司的最高点，相比这两座 “山”，也就相当于它们的山脚下。但有时职业的路径就是这样，我们迷茫、徘徊，正是因为 “不识庐山真面目，只缘身在此山中”。跳脱不出来，看不见 “山” 的全貌。
+
+审视下你的当下，再回顾下你的职业生涯，你花了多少时间和功夫来看清自己正在攀爬的 “山”，它的高点能让你去到你想去的地方吗？能让你看到你想看的风景吗？有时，我们大部分的努力，都没有什么进展和结果，仅仅是让我们能勉强呆在同一个地方。
+
+看清了自己目标的高山，发现自己爬错了山，要舍得离开；停留在低矮的山上，无论再努力，看到的风景也有限。
+
+## 逃离
+
+如何知道你正站在局部最优点上徘徊呢？当你知道自己做得很好，但却没有感觉到成长与进步时，那么也许你就正在徘徊了。
+
+在我的成长路上，也经历过一些徘徊点，这里我分享几个这一路上关于逃离的故事。工作早期，我做银行业的企业软件开发，被外派到了客户公司的项目组。在那里，不仅仅需要写程序、查 Bug，还需要兼顾从售前技术咨询、需求分析谈判到售后技术支持，甚至包括客服咨询解答都要涉及。正常的白天（朝九晚五）是没有一刻安静的时间能写写代码的，都是在客户下班后才能有个安静时段做做编码的事情。
+
+一年后，我有些困惑，因为我感觉自己做的事情太杂，但似乎又没一样东西做精、做深的。当时的想法是以技术立身，一年下来却不免惶惑。我感觉自己选错了山，没必要继续爬下去，因为我已经看到了当时大我十岁的项目经理也许就是这座山的一个局部最优点。一年后，我选择了逃离。
+
+之后，该怎么选下一座山？第一考虑自然是想离技术更近，做的更纯粹一些，另一个无法免俗的考虑自然还是希望收入也能提高一些。如今回想起来，当时为了一千块的差距，纠结了半天也不免哑然失笑。最后的选择，其实也是马马虎虎，运气好的一面是选对了技术，这次不做项目，做产品了，作为程序员在里面做的工作更纯粹了；运气差的一面是，还是没选对行业。
+
+从金融行业软件开发转到了电信行业软件开发，而当时一个新的行业——互联网，正方兴未艾。相比之下，当时的电信行业应该正在迅速步入成熟期，拥有成熟度最高且用户流量也最大的信息化系统。一入此 “山” 中，便埋头修炼技术，熟悉行业业务，直到数年后，蓦然发现似乎又到了一个局部最优点：技术无法再快速进步了，业务领域也已经熟得不能再熟了。
+
+在原地徘徊了一段时间后，我选择了第二次逃离，但这次困惑更大。我换了一个城市，在这里找了好几个月工作，见了很多很多的 “山”，却发现居然没有一座 “山” 乍一看比之前的更高、更大，顶多和之前差不多。
+
+我有些沮丧，我只是不愿又重新立刻去爬一次差不多的山。就像有次一早爬青城山，下午回到山脚，有人问“谁愿意再爬上去一次”一样，当然没人愿意。但如果山顶有一百万，再爬上去就能得到呢？我想这样也许会有不少人愿意吧。但现实的生活是，有时会让你迫不得已重新爬上刚下来的“山”，但“山顶”却没有任何额外的奖励。
+
+在我的故事中，我一次次逃离，是为了什么？因为失去了成长的感觉。每一座 “山” 刚开始爬时，你会对它的风景充满新奇，会有一条陡峭的上升之路，之后慢慢失去了新奇感，而很多工作任务渐渐变成了自动化的处理，不需要学习新的技能，失去了有意识的反思，从而让成长停滞。
+
+当然，逃离，不一定都是换一座 “山”，也有可能是换一种爬山的方式，找到一条新的路。
+
+在日常工作中，你可以尝试问问自己，对于十年后而言，现在的工作和事情，哪些会是很重要的？哪些会让你的技能变得更好？这就需要你有意识地试图在一些你已经知道如何做的事情上，再去做得更好。如果没有这种有意识的尝试与努力，很可能你就还在原地依赖过往的经验和技能自动化地完成同样的事情。
+
+算法进入了局部最优解，通常都是通过在环境参数中引入一些震动来帮助算法脱离，继续寻找更优点，而成长的路何尝不是呢？
+
+有时，有人会同时面对好几座山都想爬，但因为种种原因（主要还是生活所迫）只能爬其中一座。当你站在你选择的这座山的一个高点，远远看到曾经放弃的山峰，会感到徘徊遗憾么？
+
+进入局部最优，徘徊于局部最优，逃离局部最优，都是你的选择。而站在局部的最优点，走出徘徊的第一步，总是从下山开始，而这样的选择并不容易。
+
+最后，能否分享一下：如今你正在爬怎样的“山”？爬到了什么位置？以及你是如何选择的？
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/41 | 沟通之痛：如何改变？.md

@@ -0,0 +1,129 @@
+<audio id="audio" title="41 | 沟通之痛：如何改变？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/41/dc/41a2f82181a0bdc033ac67894d91f3dc.mp3"></audio>
+
+沟通问题，一直都是程序员的痛点。
+
+隔壁专栏（左耳听风）的陈皓以前在他的博客上写过一篇文章叫《技术人员的发展之路》，里面提及职业发展到一定阶段，也许你就会碰上一些复杂的人和事，这种情况下他写道：
+
+> 
+这个时候再也不是 Talk is cheap, show me the code! 而是，Code is cheap, talk is the matter!
+
+
+这里的 Talk 其实就是沟通，在工作中你要是留心观察，就会发现很多沟通问题，比如，跨团队开会时常发生的一些分歧和争论。沟通，越发成为一件重要的事，至少和写代码同等重要；沟通清楚了，能让我们避免一些无谓的需求，少写不少无效的代码。
+
+然而现实中， 沟通问题，有时却被作为程序员的我们有意或无意地回避与忽略了。面对沟通问题，我们该如何看待和分析这个问题，并做出一些改变呢？
+
+## 一、木讷与沉默
+
+木讷与沉默，这两个名词似乎已变成了程序员的标签，它们形象地体现了程序员在沟通中的表现。
+
+在程序员的世界里，沟通的主要场景可能包括：与产品经理沟通需求，与测试同学推敲 Bug，与同行交流技术，给外行介绍系统，还有和同事分享工作与生活的趣闻，等等。然而，有些程序员在分享趣闻时，与谈需求或技术时的表现大相径庭，刚才明明还是一个开朗幽默的小伙，突然就变得沉默不语了。
+
+沉默有时是因为不想说。特别在沟通需求时，有些程序员默默不言，但心里想着：“与其扯那么多，倒不如给我省些时间写代码！”然而，程序员写出的代码本应该是公司的资产，但现实中代码这东西是同时带有资产和负债双属性的。
+
+**需求没沟通清楚，写出来的代码，即使没 Bug 将来也可能是负债**。因为基于沟通不充分的需求写出来的代码，大部分都是负债大于资产属性的，这最后造成的后果往往是：出来混都是要还的，不是自己还就是别人来还。
+
+有些程序员可能会争辩道，“与人沟通本来就不是我们所擅长的，再说了我们也并不是因为热爱跟别人聊天才做软件开发这一行的。”这个言论很有迷惑性，我早年一度也是这么认为的。
+
+我毕业去找工作那年，外企如日中天，所以我也去了当时心中很牛的 IBM 面试。面试过程中的大部分交谈过程和内容现在我都记不清了，但就有一个问题至今我还记忆犹新。面试经理问我：“你是喜欢多些跟人打交道呢，还是跟电脑打交道？”当时的我毫不犹豫地回答：“喜欢跟电脑打交道，喜欢编程写代码，而且我自觉也不擅长和人打交道。”
+
+然后，我就被淘汰了。后来我才明白了，其实当时的这类外企挂着招工程师的名义，实际需要的更多是具有技术背景和理解的售前技术支持，因而就需要所招之人能更多地和人沟通去解决问题，而不只是写代码解决问题。
+
+结合我自己多年的工作经历和经验来看，即便你仅仅只喜欢写代码，那么和人的沟通能力也依然是你必须跨过去的门槛。《计算机程序的结构与解释》有云：“程序写出来是给人看的，附带能在机器上运行。”
+
+其实，写代码本身也是一种沟通，一种书面沟通。沟通从来都是个问题，书面沟通也同样困难。
+
+## 二、争论与无奈
+
+程序员最容易产生沟通争论的地方：**沟通需求**和**沟通技术方案**。
+
+在程序员的职业生涯路上，我们不可避免地会碰到和同事关于技术方案的争论。我从中得到的教训是：千万不要让两个都自我感觉很牛的程序员去同时设计一个技术方案。
+
+假如不巧，你已经这么干了并得到了两个不同的方案，那么记住，就别再犯下一个错：让他们拿各自的方案去 PK。因为这样通常是得不到你想要的“一个更好的方案”，但却很可能会得到“两个更恼怒的程序员”。
+
+既然分歧已经产生了，为了避免无谓的争论，该怎么解决呢？
+
+### 1. 以理服人
+
+首先，把握一个度，**对事不对人**，切勿意气用事。
+
+有些程序员之间的分歧点是非常诡异的，这可能和程序员自身的洁癖、口味和偏好有关。比如：大小写啦、命名规则啦、大括号要不要独立一行啦、驼峰还是下划线啦、Tab 还是空格啦，这些都能产生分歧。
+
+如果你是因为 “该怎么做某事或做某事的一些形式问题” 与他人产生分歧，那么在很多情况下，你最好先确定分歧点是否值得你去拼命维护。这时，你需要判断一下：技术的 “理” 在什么地方？这个 “理” 是你值得拼命坚守的底线不？用这个 “理” 能否说服对方吗？
+
+我所理解的技术的 “理” 包括：先进性、可验证性、和团队的匹配性、时效性、成本与收益。另外还有一些不合适的“理”，包括：风格、口味、统一、政治等。
+
+不过有时候，有“理”也不代表就能搞定分歧，达成一致。毕竟林子大了，不讲“理”的人也是有的，那么，就需要换一种方式了。
+
+### 2. 以德服人
+
+分歧进入用 “理” 都无法搞定时，那就是应了那句古词：“剪不断，理还乱”。
+
+这时继续“理”下去，不过都是互相耍混罢了。“理” 是一个需要双方去客观认可的存在，而越“理”越乱则说明双方至少没有这种客观一致性的基础，那就找一个主观的人来做裁决吧。
+
+这个人通常就是公司所谓的经验丰富、德高望重的“老司机”了，并且双方也都是认可的，比如架构师之类的。但是这类主观裁决也不一定能保证让双方都满意，有时实力相当的技术人也容易产生类似文人相轻的状况。不过看在“老司机”的 “德” 面上，也能勉强达成一致。
+
+“老司机”裁决最好站在他所认同的 “理” 这个客观存在上，这是最好的，不过这也取决于“老司机”的工作素养和价值观了。
+
+### 3. 以力服人
+
+最差的状况就会走到这一步，特别在跨大部门的沟通中。
+
+技术方案无法达成一致，也没有一个跨两个部门的有德之人可以转圜化解，就会升级到这个地步。最后就是靠粗暴的权力来裁决，看双方部门老大或老大的老大，谁更有力或给力。一般来说，非关键利益之争实在没有必要走到这一步了。
+
+## 三、认识与改变
+
+做出改变的第一步是要能认识到，否则改变不可能发生。
+
+程序员会认识到沟通很重要，有时甚至会比写代码更重要吗？著名的技术型问答网站——Stack Overflow的两位创始人杰夫·阿特伍德（Jeff Atwood）和乔尔·斯波尔斯基（Joel Spolsky）都对此有正面的认识和见解。
+
+杰夫说：
+
+> 
+成为一名杰出的程序员其实跟写代码没有太大关系。
+做程序员确实需要一些技术能力，当然还要有坚韧不拔的精神。
+但除此之外，更重要的还是要有良好的沟通技巧。
+
+
+乔尔的观点是：
+
+> 
+勉强过得去的程序员跟杰出程序员的不同之处，不在于他们掌握了多少种编程语言，也不在于他们谁更擅长 Python 或 Java。
+真正关键的是，他们能不能把他们的想法表达清楚，杰出的程序员通过说服别人来达成协作。
+通过清晰的注释和技术文档，他们让其他程序员能够读懂他们的代码，这也意味着其他程序员能够重用他们的代码，而不必重新写过。
+要不然，他们代码的价值就大打折扣了。
+
+
+按照程序员解决技术问题的习惯，就是把一个大问题拆解为多个部分的小问题，那这里我们也对沟通做下拆解，它包括三个方面：
+
+- 内容
+- 形式
+- 风格
+
+**从内容上看**，虽说你想沟通的本质是同一样东西或事情，但针对不同的人，你就需要准备不同的内容。比如，同内行与外行谈同一个技术方案，内容就是不同的。这里就需要你发挥同理心和换位思考的能力。保罗·格雷厄姆（Paul Graham）曾在他的书《黑客与画家》中写道：
+
+> 
+判断一个程序员是否具备 “换位思考” 的能力有一个好方法，那就是看他怎样向没有技术背景的人解释技术问题。
+
+
+换位思考本质上就是沟通技巧中的一种。
+
+**从形式上看**，沟通其实不局限于面对面的谈话。面对面交谈是一种形式，书面写作又是另外一种形式，连写代码本身都是在和未来的自己或某个你尚未谋面的程序员沟通。
+
+程序员确实有很多都不擅长面对面的沟通形式。面对面沟通的场景是很复杂的，因为这种沟通中交流传递的载体不仅仅是言语本身，眼神、姿态、行为、语气、语调高低，甚至一种很虚幻的所谓“气场”，都在传递着各种不同的信息。而大部分人都不具备这种同时控制好这么多传递渠道的能力，也即我们通常说的“缺乏控场能力”，这里面隐含着对你其他能力的要求，比如：临场应变、思维的活跃度与变化等。
+
+**从风格上看**，不同方式和场景的沟通可以有不同的风格。比如面对面沟通，有一对一的私下沟通，风格就可以更随性柔和些；也有一对多的场景，比如演讲、汇报和会议，风格就要正式一些，语言的风格可能就需要更清晰、准确和锐利一些。
+
+沟通之难就在于清晰地传递内容和观点。当你要向其他人详细解释某样东西的时候，你经常会惊讶地发现你有多无知，于是，你不得不开始一个全新的探索过程。这一点可以从两个方面来体会：
+
+1. 你只需要尝试写点你自认为已经熟悉掌握的技术，并交给读者去阅读与评价。
+1. 每过一段时间（比如，一个季度或半年）尝试去总结，然后给同事分享下你工作的核心内容，再观察同事们的反应和听取他们的反馈，你就能体会到这一点了。
+
+所以，沟通改变的第一步就是从考虑接收方开始的，看看接收方能吸收和理解多少，而非发送了多少。而沟通问题的三个方面——内容、方式与风格——的考虑，都是为了让接收更方便和容易。
+
+江山易改，本性难易，有时候我们做不到就在于这一点。但现实并不要求程序员成为所谓的沟通达人，只是需要主动认识到身边的沟通问题，去进行理性和逻辑地分析、拆解并做出适当的调整。
+
+从认识我们的本性开始，控制情绪，从而去规避无奈的争论；认识清楚沟通问题的本质是要方便接收，达成共识，保持换位思考和同理心，改变自会发生。
+
+关于沟通的各种形式，每个人可能都有自己擅长和偏好的方面，比如我就更擅长文字沟通，而不擅长一对一当面沟通，那么你呢？
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/42 | 技术停滞：如何更新？.md

@@ -0,0 +1,116 @@
+<audio id="audio" title="42 | 技术停滞：如何更新？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a2/a7/a2886d8ebc2a1d5d5c092a5e5e6813a7.mp3"></audio>
+
+我们从开始学习程序，到工作十来年，中间可能会出现几次自我感觉技术停滞了。而在这个过程中，我们也会不断地学习很多新技能，但而后其中的不少也会被淘汰在时间的旅程中。
+
+一方面，我们在不断地打磨、提升技能，去解决工作中的问题，但久而久之，就会发现技能的提升速度越来越慢，竟渐至停滞，感觉不到进步了。另一方面，程序员所处的这个行业，技术的变化很快，潮流此起彼伏，难免产生技能焦虑。
+
+有时，我们会不免幻想要是学会什么屠龙之技，从此高枕无忧，该多好！但这终究只是幻想，哪里又有什么屠龙之技呢？那面对技术停滞，技能过时，又该如何保持更新，与时俱进？
+
+## 技术停滞
+
+技术停滞是如何发生的？
+
+程序员，最重要的就是编程技能。每天的工作可能就是编程写代码，在早期还不够熟练时，你还能感觉到进步，这种进步就是从不熟练到熟练。进入熟练期以后，你可能感觉这项技能就提升得很慢，甚至一度停滞了。
+
+单纯的编程实战其实并不能持续地提高一个人的编程技能，想想体育运动员，又有哪一个每天的日程就只是参加比赛。运动员平时都是在进行刻意地训练，而关于习得甚至精通一门技能，最著名的理论应该是 “刻意练习”，如果非要在这份练习上加上一个期限，那就是：一万小时。
+
+关于 “刻意练习”，不少书或文章中都讲了很多案例来说明它的有效性，但总结起来关键就下面三点：
+
+1. 只在 “学习区” 练习，练习时注意力必须高度集中。
+1. 把训练的内容分成有针对性的小块，对每一个小块进行重复练习。
+1. 在整个练习过程中，随时能获得有效的反馈。
+
+刻意练习是为习得真正的技能所设计的，它和获取知识不同，知识就是那些你知道即为知之、不知即无知的东西，这可以通过读书获得。但技能是那些你以为你知道，但如果你没做过，就永远不会真的知道的事情。
+
+在程序员足够熟练了之后，每天的这种编程实战型工作就不会再是处于 “学习区” 的练习了，而是进入了 “舒适区” 的自动完成。真正的职业竞技体育运动员每天的日常训练都是在 “学习区” 的刻意练习，到了上场比赛则是进入 “舒适区” 的自动完成。然而很多熟练程序员的日常工作则是在 “舒适区” 的自动完成，工作之外则是另一种 “舒适区” 的娱乐休闲。
+
+停滞，就是这样发生的。
+
+## 技能保养
+
+感觉停滞的技能，如果工作依然需要它，其大的技术方向发展趋势依然明朗，那么这样的技能是值得好好保养，并继续提高的。而保养和提升技能的方法，“刻意练习” 依然是不二之选。
+
+关于 “刻意练习”，有时我们即使一直保持在 “学习区” 的重复练习，却也可能感觉不到进步，这有可能是因为重复的次数和强度还不够。我曾经就犯过这个错：英语这门技能从毕业后就停滞了（可能还倒退了些）十年，在工作十年后我重启了学习掌握英语这门技能的练习，但刚开始阶段我完全低估了需要重复练习的次数和强度。
+
+第一年，仅仅在每日的工作之余，我会花上大约一小时来进行听说读写的练习。但即使每日都能保障一小时的时间，一年下来也不过区区 300 多小时，更别提分散在听说读写四个分支上了。最后的结果可想而知，就是那一年结束后，并没有哪一项在让我感觉到一点点的进步。
+
+在决策科学中有一个概念叫 “基础比率（Base Rate）”：
+
+> 
+所谓基础比率，就是以前的人，做同样的事，做到的平均水平。
+
+
+也就是说，如果别人做这件事需要那么长时间，基本上你也需要那么长时间，因为可能你没有那么特殊，只是每个人都会“觉得”自己是特殊的、例外的罢了。所以，当我调查了下学英语人群的基数和真正算是掌握并熟练运用这门技能的人数，以及他们所花费的时间，我就知道自己大大低估了需要重复练习的强度。
+
+重复，是有针对性的强化练习，其本身是练习过程，而非练习内容。每一次的重复过程中都需要根据反馈进行有针对性的调整，以取得练习效果的进步。
+
+而重复的刻意练习总是辛苦的，辛苦就是我们付出的技能保养成本。
+
+## 技能开发
+
+技能不仅仅会停滞，还有可能会过时。
+
+就拿我来说，我这十多年编程生涯走过来，从早年的 Basic 语言，到后来的 C，再到后来为了做 C/S 架构的项目学习了 Delphi，之后 B/S 架构开始兴起，又开始写起了 JSP，转到 Java 上来。经历了如此多艰辛的学习路线，曾经掌握过不少技能，但如今除了 Java ，其他的都过时淘汰得差不多了。
+
+旧技术过时了，肯定是因为有另一种新的技术来取代了它，我们只需定期保持跟踪，观察现有掌握的技术是否可能被新出现的技术所取代。一般来说，新旧技术的更替都是有一定周期和一个持续的过程的，这期间给了我们足够的时间来学习和开发基于新技术的新技能。
+
+而针对不同的学习目标，采用的学习路线也会不同。
+
+如果需要学习新技能来解决工作上的一个具体问题，那这样的目标更适合采用深度路线学习方式，这是解决特定问题的一种捷径，属于痛点驱动式方法，能让你快速排除障碍，解决问题，而非先找到相关书籍，从头读到尾，知道一个整体大概。
+
+一般技术书籍的组织方式都是按主题的相关性来编排的，系统体系性很强，但却不是按你解决问题需要知道的内容来组织的。所以，技术书籍更适合于在你解决问题的过程中用来参考。完整地读技术书籍能增长你的知识，但却无法快速习得技能，并解决你的问题。
+
+反过来，另一种情况，面临一种新兴技术，比如，近年火热的人工智能与机器学习，你不是需要解决一个具体问题，而是要对这类新兴技术方向做评估、判断和决策。那么学习的方式就又完全不同，这时采用广度路线学习就更合适。
+
+对如何开发一门新技能，《软技能》一书的作者曾在书中分享过他的一个十步学习法：
+
+1. 了解全局
+1. 确定范围
+1. 定义目标
+1. 寻找资源
+1. 学习计划
+1. 筛选资源
+1. 开始学习，浅尝辄止
+1. 动手操作，边玩边学
+1. 全面掌握，学以致用
+1. 乐为人师，融汇贯通
+
+这个方法和我自己在实践中养成的习惯基本一致。在深度路线学习中，对全局、范围、目标的定向更聚焦，因此寻找、筛选的资源会更窄，学习计划的迭代期更短，很快就走完了前 6 步，并进入动手实践、反复迭代的过程中，直到把问题解决。
+
+而在广度路线的学习中，前 6 步会花去大量的时间，因为这时你面临的问题其实是对新技术领域边界的探索。这就像以前玩《魔兽争霸》游戏中，先去把地图全开了，看清楚了全貌，后面再进军时就能选择最优路径，避免了瞎摸索。
+
+这个类比中不太恰当的是，游戏中开地图实际挺简单的，但现实的技术领域中，地图全开基本是不太现实的，一是地图实在太大，二是地图本身也在演变中。只能说尽可能在前期的探索中，所开的地图范围覆盖更广至需要去解决的问题领域。
+
+## 沉淀能力
+
+技术也许会停滞，技能也可能会过时，但其中的能力却可以沉淀下来，应用于下一代的技能之上。
+
+汉语中容易把能力和技能混为一谈，在英语中，技能对应的词是 Skill，而能力对应的是 Ability。**技能是你习得的一种工具，那么能力就是你运用工具的思考和行为方式**，它是你做成一件事并取得成果的品质。
+
+程序员爱说自己是手艺人，靠手艺总能吃口饭。五百年前，鞋匠也是手艺人，但进入工业革命后，制鞋基本就由机器取代了。手工制鞋是一门技能，它的过时用了几百年时间，但如何做一双好鞋的能力是不会过时的，五百年后人们还是要穿鞋，还要求穿更好的鞋。这时鞋匠需要应对的变化是：换一种工具（现代流水线机器生产）来制作好鞋。而现代化的制鞋机器技术实际上还进一步放大了好鞋匠的能力，提升了他们的价值。
+
+对程序员来说，程序技能的过时周期相比制鞋技能却要短得多，每过几年可能就大幅变化了，是需要定时更新的消耗品，而能力才是伴随技能新陈代谢，更新换代的固定资产。技能用熟练了就成了工具，熟练应用工具能快速解决已碰到过的老问题。而沉淀下来的能力，是为了应对并解决新问题，甚至为了解决新问题，可以去开发新的技能或创造新的工具。
+
+那么程序员需要去沉淀哪些能力？
+
+作为程序员最基本的自然是代码能力。能够写程序，只能算是技能过关吧，而能写好程序，才算具备了程序员的基本代码能力。代码能力的识别，最简单的方式就是维护一份公开可跟踪的记录，比如参与开源项目贡献，在 GitHub 上留下你的代码简历。
+
+从程序员到架构师，“架构”显然不是一种技能，而是综合应用多种技能的能力。架构师也许不像在工程师阶段需要写大量代码，但实际没有代码能力是做不了架构的。代码能力是架构能力的底层能力要求。但仅此一项能力却也远远不足，这里就先不展开了，后面会专门有一篇文章谈架构师能力模型这个主题。
+
+除了技术能力，如果有可能可以适当跨出技术的边界，去了解下产品、管理、运营和传播等方面的能力。为什么呢？一方面，技术能力的提升总会到达平台期，增长变得缓慢，而了解学习一下其他方面的全新能力，可能会让你找到新的成长点，重新找回快速成长的感觉。
+
+另一方面，个人很多综合能力的差别，有时就是要靠作品来体现的。完成作品需要有一些产品思维，需要自我规划与管理能力，而推广作品需要运营和传播能力。这些相关的能力，最终都会成为你核心能力体现——作品——的放大器。
+
+如果你是一棵树，能力是根，技能是叶；春去秋来，时过境迁，技能过时，落叶归根；沉淀下来的能力，将如春风吹又生，新的技能自会发芽。
+
+而这一切的能力与技能之母，又叫元能力，自当是学习能力。
+
+虽有俗语说：“技多不压身”，但实际很多技能是有保养成本的，编程技能就是一种，特别是和特定技术有关的编程技能。所以，同时保养很多技能是不太合理和现实的，更优化的选择是：**持续保养主要的生存技能，合理开发辅助技能，形成自己独有的技能组合，沉淀能力模型，发展能力矩阵**。
+
+当时代发展，某些技能会过时，但能力矩阵不会过时，它当与时俱进；永不会有停滞的时候，它总是在进化。而对于过时的技能，除了既往不恋，我们还能做什么呢？
+
+技能如剑，金庸老爷子笔下有一 “剑魔”，一生用剑经历 “利剑无意”“软剑无常”“重剑无锋”“木剑无俦”“无剑无招”，最终剑已埋冢，人却求败。
+
+如今你的哪些技能已过时？又沉淀下来怎样的能力呢？
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/43 | 无法实现：困扰与反思.md

@@ -0,0 +1,95 @@
+<audio id="audio" title="43 | 无法实现：困扰与反思" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c7/d5/c7c2119608cbc9390e7a8d2f815f54d5.mp3"></audio>
+
+程序员有句口头禅叫：“技术上无法实现！”这句话，在我过去多年的程序员职业生涯中经常听见，甚至我自己就曾说过很多次。如今，当我再次听到有人说出这句话时，不禁开始反思起来，为什么程序员爱说这句话呢？为什么曾经我也时不时说这句话呢？
+
+一仔细思考，就惊讶地发现一个事实：这句口头禅背后隐藏着一个阻碍我们成长的陷阱。
+
+## 一、困扰
+
+当接到一个需求或碰到一个问题，我们回上一句：“技术上无法实现！”这是真的无法实现吗？还是隐藏着其他的困扰？
+
+### 1. 不知
+
+当我刚开始工作的第一年，我在一家银行客户现场工作。当时要给银行的出纳管理部做一个系统，这个系统有个功能就是上传各个国家的高清真假币鉴别对比图片，然后银行的出纳和柜员就可以在系统上学习各个国家纸币的鉴别方式了。
+
+针对这些高清纸币图片，客户因为怕别人盗取乱用，就要求必须对图片做加背景水印的功能。当我们在召开需求讨论会时，我听到这个需求就懵了，因为完全不知道要怎么做。毕竟当年我才刚刚开始学习如何做 Web 化的管理系统，从来没有用程序处理过图片。
+
+彼时，当我想起程序化的图片处理时，我就只能想起像 PhotoShop 那样高度专业化的图片处理工具软件，觉得这肯定是一个很复杂的事情。所以，当我们讨论起加背景水印的功能时，我自然脱口而出：“这在技术上无法实现！”
+
+然后我们进一步谈起，当前客户他们是怎么做的。客户确实是找了专门的外包设计公司用 PhotoShop 来给图片一张张手工加水印。这听起来就是一个比较繁琐的过程，所以，当我回答“在技术上无法实现”时，客户都是业务人员，也不太懂程序技术上的事，听到我的答案也就略显失望。
+
+好吧，如今回想起来，我说“技术上无法实现”时，仅仅是因为当时的我并不知道如何去实现。而且想当然地感觉要进行图片处理，必须要具备有 PhotoShop 一样的专业背景知识，而这对当时的我而言是完全不能想象的。
+
+因此，当时我说出的那句“技术上无法实现”，仅仅是因为不知和不解而心怀畏惧。因为畏惧，所以我用了这句口头禅来回避了这个问题，甚至没有去调研一下技术可行性，就由此固步自封，在这片知识领地留下了一片空白，也不能为客户创造更进一步的价值。
+
+“技术上无法实现” 的口头禅，此时成为了遮挡我们因不知而畏惧的面具。
+
+### 2. 不愿
+
+有一年，我出差在客户现场赶项目，连续加班了四个周末，也就是大概一个月在连续上班。终于我们的项目快要如期上线了，每个通宵的早晨，看着东方慢慢变得红润透亮的天空，感觉已经快要看到胜利的曙光了。
+
+就在这样一个曙光照耀的早晨，项目经理跑来对我们说：“原有的一块业务逻辑今天在和客户聊起时，他们说也只是试试这个流程，可能要改变。但我们的实现方式太僵硬，都是硬编码赶出来的。要不我们改成更灵活的、可以通过配置的方式，一旦上线后再改起来就更麻烦了。我可以先去和客户再沟通下，给我们再争取点时间。”
+
+一下子，我们都被打击得不行，改成配置怎么改？逻辑那么复杂，又不是那种简单的开关式配置。当时，项目经理早已脱离技术一线时间颇久，也一时半会儿没啥方案。在沉默地思考了一阵后，我又说出了那句话：“逻辑太复杂，变动太大，这短期在技术上无法实现的。”
+
+其实，那时我心里是有一个方案的，如今看来虽不是什么优秀的方案，但也是当时我唯一知道且可行的方案。就是通过 Java 的动态类加载机制，把业务逻辑外移，流程内置的方式以便可以动态热加载新的业务逻辑类。但这意味着可能要面临一次重大的重构，又是两周的持续加班，而我当时只是想赶快离开这沉默的讨论会，去美美地睡上一觉。
+
+后来，这个故事在我睡醒后依然以我妥协结束。我建议了这个方案，最后当然也是我去实施了这个方案，庆幸的是并没有如“预料”那般加上两周班，只用了一周，项目就上线了。再之后的后续维护中，我又学习了新的东西，流程引擎，动态脚本，继续下一版本的重构，我们升级成了一个更好、更通用的方案。
+
+当时我说出的那句“技术上无法实现”，只是因为觉得很麻烦，不愿意而已。后来睡醒后，回了一些血，有了能量，觉得应该接受这个挑战。因为客户的需求变化就是一个客观事实，也不会因为我的主观意愿而改变。
+
+“技术上无法实现” 的口头禅，此时成为了我们推脱的借口。
+
+## 二、反思
+
+不论是 “不知” 还是 “不愿”，“技术上无法实现” 的口头禅看来都不会给我们带来什么帮助，它反而阻碍了我们进一步做出更好的产品，从而给客户留下遗憾。
+
+随着工作经验的增多，技能的积累，我便越来越少说这句话了。事实上，我发现大部分的用户需求，技术上总是可以实现的。这些需求的真正限制，要么是时间，要么是资源。
+
+所以，面对一个紧迫的或不合理的客户需求，甚至诉求时，不应该再以如此苍白的一句话去应对了。这个需求背后涉及的技术实现，要么可能你现在未知，要么你至少知道一个方案，只是觉得过于复杂，而且会带来很多“副作用”，所以不愿意这样去做罢了。
+
+但总之，你需要一个办法去应对一个让你觉得 “技术上无法实现” 的需求。我建议不要立刻像我当年那样做出如此简单的判断就推脱过去，其实我们完全可以把这样的问题放在下面这样的框架中去思考下。
+
+### 1. 全局背景
+
+这一步的目的并不是要找到并确定实现方案，只是对这一问题涉及主题的相关内容有一个全局性的了解。
+
+近年我都在做京东咚咚，一个 IM 系统，所以就以此举个例子吧。不时我们会收到用户反馈在安卓客户端应用切到后台就会收不到消息，这里用户只是提供了一个说法，甚至都不算现象。但这是一个问题，而且是一个我觉得在技术上无法百分百根除的问题，换言之就是我可能想不出一个方案能让我的所有用户都再也不会碰到类似的问题。
+
+而用户碰到这样的问题可能的原因有：
+
+- 移动弱网络，消息投递失败率高；
+- 应用切后台就被系统杀掉，所以收不到；
+- 第三方推送渠道，比如：某一类用户完全没有这种渠道可达；
+- 应用本身的问题，比如：Bug，版本碎片导致的兼容性问题。
+
+以上简单的问题分类，背后都隐藏着一个解决或优化问题所需的巨大且复杂的实现方案。针对每一类问题的方案，可以先去大概有个了解，但这里还不需要很深入。
+
+### 2. 聚焦范围
+
+对上面列出的全局背景问题分析分类后，会发现没有一个是轻松容易就能解决的。而且这时还必然面临资源和时间的问题，也就是在特定的资源和时间下，我应该优先解决哪类？所以，这一步的本质就是从上面的全局分类中，聚焦一个范围，然后集中深入调研评估。
+
+### 3. 定义标准
+
+前面说了用户仅仅反馈了一个说法，站在用户的角度，他们总是希望没有任何问题的。但站在我的角度，我知道我只聚焦了一部分问题，所以我需要清晰定义这部分问题解决的成功标准。
+
+比如，针对应用切后台就被系统杀掉，对用户无感知，所以认为收不到消息是有问题的。针对这个问题的聚焦范围，我可以提供第三方推送渠道在十分钟内的推送通知补偿，重新唤醒用户重回应用，避免消息的遗漏。通过估算每日活跃用户和可能投递给第三方渠道消息通知量以及第三方渠道自己标榜的投递成功率和业界一些经验数据，就能估算出该解决方案的标准：通知唤醒到底能补偿多少用户的指标。
+
+### 4. 深度评估
+
+有了范围和标准，剩下的就是深度评估方案路径问题。大体上任何一个方案，其中有些是你已经轻车熟路的实现路径，另一些则是你可能从未走过的陌生之路。
+
+轻车熟路的部分可能更容易评估，但很多程序员还是容易高估自己；而从未走过的陌生之路，就评估得更离谱了。关于评估，可以保守一些，因为一般来说现实总是比理想的路径曲折一些的。
+
+经过了上面四层思考框架的过滤，这时想必你已成竹在胸了，并能很好地衡量该技术实现方案的成本与收益。除此之外，进一步还需斟酌考虑的是方案是否足够优化，毕竟我们做工程就是要找到一条最优化的实现路径。
+
+当面对任何一个需求，除非能一下从理论上发现其实现的物理限制，我们恐怕不能够再轻易说出 “技术上无法实现” 了。即使真的是无法实现的需求，也有可能通过变通需求的方式来找到一条可实现的路径。“技术上无法实现” 的口头禅仅仅是我们阻挡需求的快捷方式，但这样的思维也阻碍了我们进一步去找到真正的实现路径和优化方案。
+
+- “你看这个需求能实现么？”
+- “哦…”
+
+改掉了这句口头禅后，有些问题也挺难简单地回答了。
+
+那你是否爱说这句口头禅呢？又是在怎样的情境下说的呢？
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/44 | 完成作品：理想与现实.md

@@ -0,0 +1,78 @@
+<audio id="audio" title="44 | 完成作品：理想与现实" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e5/cf/e5b2e52c0a0366b702bb1b8943ce31cf.mp3"></audio>
+
+有时工作久了，会陷入这样一种状态中，整天不停地写代码，开发业务需求，周而复始，日子长了，自然觉着厌倦，感到似乎真的有点像 “码农” 了，日出而作，月落而息。在过去的某个时期，我应该也陷入过这样的循环之中，后来又是如何脱离的呢？
+
+## 困境：代码与罗马
+
+陷入这样一种写代码的 “困境”，还是要回归到写代码这件事本身上。
+
+写代码是因为有需求，需求来自业务的发展需要，经过产品经理再传递到程序员。刚开始，作为一个新手程序员，不停地为各种需求写代码。开发完一个，接着又是下一个，生生不息，循环不止。
+
+一开始也许会感觉有些累，但并没有产生太多的厌倦。这是一个从不熟悉到熟悉再到熟练的过程，这里有太多的新东西可以去探索和尝试，让你在疲惫中依然能获得了好奇心的满足和成长的快感，因此不会感觉厌倦。
+
+那技能从不熟悉到熟练需要多久呢？现在成为专家的要求已经有了共识：一万小时的刻意练习。但达成熟练要不了那么久，也许两三年足矣。有句俗语叫：“条条大道通罗马”。罗马，一座城市，包罗万象，类比到程序员这里就像一个个需要完成的业务需求。几年过去，每一条通往“罗马”的大道都被你走过了，再去往“罗马”时，自然找不到新鲜感了，困倦油然而生。
+
+继续停留在通往“罗马”的循环往复中，已无法让你继续成长为专家。而要想跳出这循环往复的路，无非就是不再去走那熟悉的条条通往“罗马”的大道，而是选择一条离开“罗马”的路，走出去，走向未知与未来。
+
+在一万小时的刻意练习中，“罗马”已逐渐成为过去的熟悉、熟练区，而离开“罗马”便是要进入下一个陌生的学习区。但也许还会有一种 “现实” 的困境让你不得不继续走向当前的“罗马”，那么这时就不妨换一个视角：既已对通往当前“罗马”的所有路都了然于胸，闭眼可达，那就仔细观察了解现在“罗马”的构成与运作机制，也许将来有机会去创造属于自己的“罗马”。
+
+从走向“罗马”到创造属于你的“罗马”，这里你的 “罗马”，就是你的作品。
+
+## 理想：作品与创作
+
+也许条条通往罗马的大道，堆砌罗马的砖石，有些已经消失在历史的尘埃中，但罗马作为一个时代和历史的作品，留了下来。
+
+今天我们再看什么是作品？维基百科上对“作品”的定义是：
+
+> 
+作品，亦称创作、创意、著作，是具有创作性，并且可以通过某种形式复制的成品。
+
+
+从这个定义来看，作品最重要的特质是：**创作与创意**。所以，只有包含了创意和创作性质的事物才能叫作品。那对于程序而言，怎样才算作品？你从网上复制来一段代码，解决一个问题，这不是创作，也不会成为你的作品。
+
+代码作品，可以小到一段函数、一个类，大到一个库或框架、一个服务，甚至一个系统。但打磨代码作品的方式，应该是定期对自己写完的代码进行沉淀、梳理和规整，提取可复用的功能，同样的功能只写一次，形成自己专属的编码脚手架和代码库。在以后的学习实践中定期反思，不断优化其效率和品质。
+
+当你再碰到类似功能的实现时，能直接复用库就复用库，不能直接复用的就在脚手架代码上进行扩展，后续的重心就放在了优化实现思路上。这样日积月累下来，你的程序思维和能力才会变得科学、高效，而且产生积累效应。最终，这些留下的代码库或脚手架都成为了你的作品。
+
+不过，同是作品，却有高下之分。吴军老师曾在文章里写过：“完成一件事，做到 50 分靠直觉和经验，做到 90 分要靠科学和技艺，而要做到 90 分以上则要靠艺术。”我是认同这个观点的，而且我们完成作品的目标应是 90 分以上，这是作品的特性决定的，因为创作就是艺术的核心所在。
+
+到了 90 分或以上的作品，也许分数相差无几，但市场价值却可能差异巨大。iPhone 就是一个很好的例子，它当是一件 90 分以上的作品，90 分的工程技术加上几分的艺术，相比差几分的同类，在市场上的价值和价格却是遥遥领先。
+
+作品，是创作的，创作是需要设计的，而设计是需要品味的，正如《黑客与画家》一书里所说：
+
+> 
+优秀作品的秘诀就是：非常严格的品味，再加上实现这种品味的能力。
+大多数做出优美成果的人好像只是为了修正他们眼中丑陋的东西。
+
+
+也许，我们可以先从感知和修正代码中丑陋的东西来训练这样的品味和能力。
+
+而完成作品的收益是什么？理想的情况下，也许我们期待直接从作品中获得经济收益，但这并不容易。十九世纪，有一名画家，一生作画数千幅，但只卖出过一幅，换回了四百法郎，这名画家就是梵·高。
+
+梵·高的例子比较极端，他的作品都是 90 分以上的，但在直接换取收益方面依然困难。而对于你来说，今天的作品虽不一定能立刻给你带来经济收益，但在你打磨作品的过程中，把“条条通往罗马的大道”都走完了，甚至还反复走试图找到更优化的路线，这会让你掌握系统化的知识和体系化的能力，同时还会让你的作品变得更值钱。你可以想象这样一个场景：**当你给别人介绍自己时，只需要介绍自己的作品，而不再需要介绍自己的技能**。
+
+成长的路上，写过的代码最终也许会烟消云散，但完成的作品会成为你点亮的勋章。
+
+## 现实：产品与特性
+
+作品要实现直接的经济收益，必须还要走完从作品到产品之路。
+
+产品，是指能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品，无形的服务、组织、观念或它们的组合。现实情况是，大部分时候我们的代码作品，都是存在于产品之中的，所以你需要关注包含了你的代码作品的更大范围的产品及其特性。
+
+如果产品无法获得市场的价值认同，技术作品自然也就埋没其中了。
+
+有个说法是：要做好技术需要懂业务和产品。这大体没什么问题，但需要提到的细节是懂的方向。技术不需要了解业务产品的每一个显性特征，一个足够大的业务产品，有无数的显性特征细节，这些全部的细节可能分散在一群各自分工的产品经理们中。所以应该说，**技术需要懂的是产品提供的核心服务和流程，并清晰地将其映射到技术的支撑能力与成本上**。
+
+另外，技术不仅仅需要支撑满足产品的全部显性和隐性服务特性，这些对于技术都相当于显性服务特性。而技术还有自己的隐性服务特性，这一点恰恰也正是高级和资深程序员需要重点关注的。所谓技术的隐性特性，通俗点就是程序员常说的非功能性需求，它的产生与来源都是源自程序和程序员本身。
+
+用一段新算法实现的函数取代了旧函数，那么多余的旧函数就变成了负债而非资产，是需要去清理的。重构代码变得更简洁和优雅，可读性增强，节省了未来的维护成本。一个能同时服务一万人的程序实例，你知道你没法加十个实例就能简单变成能同时服务十万人的系统。这些都是技术冰山下的隐性特征，**显性的错误会有测试、产品甚至最终用户来帮你纠正，但隐性的错误却很难有人能及时帮你发现并纠正**。
+
+产品的显性特性就如泰坦尼克号，而技术的隐性特性则是泰坦尼克号撞上冰山后的反应。一旦隐性的错误爆发，就像泰坦尼克号撞上了冰山，一切外显的繁华最终都将沉入海底。
+
+技术从特性到作品，去支撑产品的体验与服务，这是一条更现实的技术作品实现价值的路。
+
+从反复写代码实现需求的重复困境中，到打磨作品实现价值的理想，再回归产品化的现实之路。
+
+代码，有些人写着写着，就成了 “码农”；有些人写着写着，就成了作者；还有些人写着写着，就改变了你、我的生活。那你想成为哪一类人呢？
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/45 | 代码评审：寄望与哀伤.md

@@ -0,0 +1,90 @@
+<audio id="audio" title="45 | 代码评审：寄望与哀伤" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7c/27/7c7406315331b68cb3b50bba1a415627.mp3"></audio>
+
+我们都知道代码评审（Code Review）很有用、很重要，但现实中我所经历的和看到的团队，很少有能把代码评审落地得很好，并发挥出其应有作用的。这个问题困扰我已久。
+
+## 感性认识
+
+代码评审的作用，有一定经验的程序员们想必都会有感性认识。
+
+它是很多软件工程理论和方法学中的重要一环，对于提升代码质量和找出一些潜在隐患很有帮助，如果你有一些正式的代码评审经历过程，想必也能感性认知到其正面作用。但在我过去工作的这些年里，经历了几家公司，数个不同的团队，却几乎没有哪一个会把代码评审作为必要的一环去执行的。
+
+过去，我们总是在线上出现一些奇怪的疑难问题后，一群相关程序员才围坐在一起，打开相关代码来逐行分析，根据线上现场的“尸检”来做事后分析和推导。这样的事后代码分析实际上根本不是代码评审，也完全违背了代码评审的初衷。
+
+**代码评审的初衷是提高代码质量，在代码进入生产环境前经过同行评审来发现缺陷，降低损失概率**。这一点程序员都好理解，提前的代码评审就像雷达扫描我们重点关注的代码领地，以期发现或明显或隐藏的危险因素。
+
+漫画《火影忍者》里有一种忍术技能：白眼，这种技能有近 360° 的观察范围。程序员在写程序时力求思考全面，不留死角或盲点，但实际死角或盲点总是存在的。随着我们经历和经验的成长，思考和认识得越发全面（越发接近 360°），拥有了近乎 “白眼” 的能力，但即使是像 “白眼” 一样，也依然会存在盲点。
+
+正如世界上没有两片完全一样的树叶，也许也不会有两个认知视角完全重叠的人，这样相互进行代码评审也就弥补了个人单一视角和认知思考的盲点问题。除此之外，代码评审还有一个社会性功用，如果你在编程，而且知道一定会有同事将检查你的代码，那么你编程的姿势和心态就会完全不同。这之间的微妙差异正是在于会不会有人将对你的代码做出反馈与评价。
+
+代码评审的编程实践正是基于这样的感性认知，影响你的编码心理，并试图通过群体视角来找出个体认知盲点区域的隐患或 Bug，但到底这样的做法能降低多少出现 Bug 的概率呢？
+
+## 理性分析
+
+有人对代码评审的作用进行了更理性且量化的分析，结论如下（来自维基百科）：
+
+> 
+卡珀斯·琼斯（Capers Jones）分析了超过 12,000 个软件开发项目，其中使用正式代码审查的项目，发现潜在缺陷率约在 60%～65% 之间；若是非正式的代码审查，发现潜在缺陷率不到 50%；而大部分的测试，发现的潜在缺陷率会在 30% 左右。
+
+
+> 
+一般的代码审查速度约是一小时 150 行，对于一些关键的软件，一小时数百行代码的审查速度太快，可能无法找到程序中的问题。对于产品生命周期很长的软件公司而言，代码审查是很有效的工具。
+
+
+从如上的实验分析结论来看，代码评审对于发现潜在缺陷很有用，相比测试能发现的缺陷率高一倍，但也需要投入巨大的时间成本 —— 一小时审查 150 行代码，再快就不利于发现潜在缺陷了，而且更适用于长生命周期的产品。
+
+所以，下面这个现象就容易理解了。我发现在同一家公司做代码评审较多的都是研发通用底层技术产品或中间件的团队，而做业务开发的团队则较少做代码评审。两者对比，底层技术产品或中间件的需求较稳定，且生命周期长；而业务项目，特别是尝试性的创新业务，需求不稳定，时间要求紧迫，并且其生命周期还可能是昙花一现。
+
+## 多种困境
+
+从感性和理性两个角度认知和分析了代码评审的好处，但其适用的场景和花费的成本代价也需要去平衡。除了这点，如果把代码评审作为一个必要环节引入到研发流程中，也许还有一些关于如何实施代码评审的困境。
+
+**困境一**，项目期限 Deadline 已定，时间紧迫，天天加班忙成狗了，谁还愿意搞代码评审？这是一个最常见的客观阻碍因素，因为 Deadline 很多时候都不是我们自己能确定和改变的。
+
+**困境二**，即使强制推行下去，如何保障其效果？团队出于应付，每次走个过场，那么也就失去了评审的初衷和意义。
+
+**困境三**，团队人员结构搭配不合理，新人没经验的多，有经验的少。新人交叉评审可能效果不好，而老是安排经验多的少数人帮助 Review 多数新人的代码，新人或有收获，但对高级或资深程序员又有多大裨益？一个好的规则或制度，总是需要既符合多方参与者的个体利益又能满足组织或团队的共同利益，这样的规则或制度才能更顺畅、有效地实施和运转。
+
+**困境四**，有人就是不喜欢别人 Review 他的代码，他会感觉是在找茬。比如，团队中存在一些自信超强大的程序员，觉得自己写的代码绝对没问题，不需要别人来给他Review。
+
+以上种种，仅仅是我过去经历的一些执行代码评审时面临的困境与障碍，我们需要找到一条路径来绕过或破除这样的障碍与困境。
+
+## 参考路径
+
+在国内，我并没有看到或听闻哪家把代码评审作为一项研发制度或规则强制要求，并落地得很好的公司。
+
+而对于一些硅谷的互联网公司，倒是听闻过一些关于代码评审的优秀实践。比如，在一篇介绍 Google 代码评审实践的文章中说道：在 Google，任何产品，任何工程的代码，在被进行严格或者明确的代码评审之前，是不允许提交的。这一点，Google 是通过工具自动就控制了未经评审的代码就没机会进入代码库。
+
+Google 以一种强硬的姿态来制定了关于代码评审的规则，规则适用范围是全公司，对任何人都不例外。即使面对团队中超自信且强大的程序员也无例外，要么遵守规则，要么离开组织。这一点从 C 语言和 Unix 的发明者、图灵奖得主——肯·汤普森（Ken Thompson）在 Google 的趣事中可以一窥其规则的强硬性，作为 C 语言发明者之一的他因为没有参加 Google 的编程语言能力测试所以无法在 Google 提交 C 代码。
+
+所以，像 Google 这样的公司对于代码评审属于高度认可且有公司制度和规则的强硬支持，再辅助自动检测和控制工具的严格执行，一举就破解了以上四类困境。但要实践类似 Google 这样严格的代码评审制度和规则，似乎对于大部分公司而言都有不小的挑战，这需要公司制度、团队文化和技术工具三方面都能支持到位，而且还要让各方对实施此项制度的收益和代价取得一致认可，岂是易事？
+
+所以，现实的情况是，大部分公司都是在各自的小团队中进行着各种各样不同形式的代码评审，或者完全没有代码评审。
+
+## 现实选择
+
+以前尝试过要在团队内部做代码评审，听说兄弟团队搞得不错，然后就一起交流经验。交流开始不久就跑偏了，重心就落在了应该选个什么好用的代码评审工具来做，如今想来这完全是舍本逐末了。
+
+这就像以为有了好的编辑器（或 IDE）就能写出好的代码一样，而事实就是有很多好用的代码评审工具我们依然做不好代码评审。这让我联想起了古龙小说《陆小凤传奇》中的一段描述，记忆尤深：
+
+> 
+西门吹雪：此剑乃天下利器，剑锋三尺七寸，净重七斤十三两。
+叶孤城：好剑。
+西门吹雪：的确是好剑。
+叶孤城：此剑乃海外寒剑精英，吹毛断发，剑锋三尺三，净重六斤四两。
+西门吹雪：好剑。
+叶孤城：本就是好剑。
+
+
+剑是好剑，但还需要配合好剑客与好剑法。
+
+即使在最差的环境下，完全没有人关心代码评审这件事，一个有追求的程序员依然可以做到一件事，自己给自己 Review。就像写文章，我写完一篇文章不会立刻发布，而是从头脑中放下（Unload），过上一段时间，也许是几天后，再自己重新细读一遍，改掉其中必然会出现的错别字或文句不通畅之处，甚或论据不充分或逻辑不准确的地方，因为我知道不管我写了多少文字，总还会有这些 Bug，这就是给自己的 Review。
+
+**给自己 Review 是一种自省，自我的成长总是从自省开始的。**
+
+代码评审，能提升质量，降低缺陷；代码评审，也能传播知识，促进沟通；代码评审，甚至还能影响心理，端正姿势。代码评审，好处多多，让人寄予希望，执行起来却又不免哀伤，也许正是因为每一次评审的收益是不确定的、模糊的，但付出的代价却是固定的，包括固定的评审时间、可能延期的发布等。
+
+哀伤过后，我们提交了一段代码，也许没人给我们 Review，稍后我们自己给自己 Review 了，也可以得到了一段更好的代码和一个更好的自己。
+
+最后，我曾在前文[《思维：科学与系统》](https://time.geekbang.org/column/article/42866)中就用代码评审作为例子说明了这是一个系统问题，每个团队面临类似的系统问题都会有具体的情况。关于代码评审，不妨谈谈你所在环境所面临的情况和你的理解？
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/46 | 人到中年：失业与恐惧.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="46 | 人到中年：失业与恐惧" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/36/e6/36724c7b612a87a427356862f21aa1e6.mp3"></audio>
+
+刚入行的时候，听说程序员是吃青春饭的，只能干到 30 岁。过了几年，这个说法变成了 35 岁。如今走在奔四的 “不惑” 之路上，想到如果突然丢了工作，会怎样？还是不免为此有一些惶惑。
+
+人到中年，突然就多了一些恐惧感。
+
+## 恐惧感：谋生
+
+当你感到害怕丢掉工作时，说明已经不再年轻了，一种为了谋生的恐惧感油然而生。
+
+记得我步出学校后，刚工作满一年，攒下了约一万元的积蓄，然后裸辞了。但只休息了一个月，就开始恐慌起来了。第二个月初，拿着手上的账单计算着，当时在广州，大约每个月的生活成本需要 3000 元。再看着卡上不多的储蓄，不得不从魔幻的虚拟世界回到苟且的现实之中，开始了新一轮的找工作之路。
+
+彼时的恐惧不是失业的恐惧，而是没钱继续生活的恐惧。并不害怕失去工作，是感觉工作随时都可以换一个，要不干嘛要傻乎乎地裸辞呢？所以反倒是想着下次应该多攒点钱才辞职的。而下次是什么时候？当时的我也不知道。
+
+第二次裸辞，已是三年后，这次我不仅想换个工作，还想换个城市，中间休息间隔的时间更长了。辞职好几个月后，我才又在成都开始了找工作。这一次感觉到了，工作没有那么好找，看上去还行也匹配自己的工作并不多，并且工资相对原来的一线城市也整体低了一个档次，但这些也未能让当时的我产生恐惧，仅仅是困惑，看不清前路。
+
+又过了好些年，真的到了中年后，每月都有很多账单要付，贷款要还，再也不会觉得切换工作是一件很随意的事情，裸辞也早已从我的字典里消失。不随意，但未必会恐惧，只是年龄与处境让我此刻更需要认真地面对和思考这个问题。
+
+中年，每个月比年轻那会儿挣得更多了，职位也更高了，生活变得更安适和稳定，这时**真正潜伏着的威胁开始出现：技能的上升曲线可能越过了高点，走入平缓区，甚至也许在以缓慢而不易觉察的方式下降，而我们却安之若素**。
+
+但中年，悄然而生的恐惧感，并不是阻止我们再进一步的 “鸣枪示警”，而像是中场的哨声，提醒我们人生的上半场快结束了，短暂的休整之后，就该提起精神开始下半场了。
+
+所以恐惧感不应是一种束缚，而是一种警醒。
+
+## 无惧感：舍生
+
+假如你在一份工作中，对丢掉工作本身产生了恐惧，那你做工作的形式很可能会走向谨小慎微。
+
+这时工作让你产生了恐惧感，你就将会被工作绊住，只想兢兢业业、如履薄冰地做好份内工作，以保护好自己的位置。但为了保护位置所做的所有努力都会是徒劳的，因为恐惧感绊住了你，这样的工作状态，自己也是缺乏信心的，而一个对自己信心不足人，也很难让别人对你产生信心。最终，几乎没有任何办法阻止别人占有你当前的位置。
+
+而偏偏是要对工作的无惧感才能真正释放你的潜力，发挥你的能力，让你能够留在原地甚或更进一步。
+
+作为程序员，我们只有一个位置：专业阵地。这是一个专业性要求比较高的职业，我们被雇佣并要求成为一名专业人士，所以应该像一个专业人士一样行事。普通劳动者和专业人士的区别在于，普通劳动者主要被动接受指令去执行任务，而专业人士则在其领域内自己生成指令，同时在领域外还会向同事或上级提供来自该领域的输出：专业建议。
+
+普通劳动者是一种劳动力资源，他们保证执行，而专业人士则是保证选择的执行方向是有意义的，执行路径是优化的。作为专业人士，我们需要去坚持和持续地打磨专业力，守住这块阵地。
+
+有时我在想，是专业让人拥有无惧感呢，还是无惧了才能走向更专业？也许，“谋生的恐惧”害怕失去的不过是工作岗位，“舍生的无惧”才能塑造专业的职业生涯吧。
+
+## 安全感：重生
+
+安全感，是渴望稳定、安全的心理需求，是应对事情和环境表现出的确定感与可控感。
+
+本来丢掉工作并不可怕，如果我们很容易找到下一份工作，并能很快适应变化的话。但现实是，如果是因为经济大环境变化导致的失业或技术性淘汰，找下一份工作并不容易，适应这种变化也不轻松。
+
+二十年前，上一辈的中年人，他们从自认为的铁饭碗（国企大厂）中批量下岗了，这是一种社会经济与技术变革引发的批量淘汰。近一点的，如美国 2008 年金融危机，一夜之间失业的也不在少数，而且之后很长一段时间都找不到工作，这并非专业能力过时的技术性淘汰，而是环境剧变导致的萧条。
+
+而离程序员更近的案例，来自TOMsInsight的深度调查采访，也就是 2015 年的事。
+
+> 
+Tony 37 岁，清华本硕，毕业后加入全球知名的 A 记公司中国研发中心工作 11 年，年薪 80 万。在北京东三环，置业豪宅，老婆全职太太，两个孩子。但 2014 年 5 月，A 记公司中国研发中心裁员，Tony 就成为了其中之一。
+
+
+> 
+Tony 作为专业技术人士的价值依然存在，更以百万年薪身价加入著名的互联网巨头 B 厂。但后来，Tony 却无法适应互联网的节奏，感觉工作上周边环境各种 “浮躁”，管理也不 “专业”，只好再度离职。
+
+
+> 
+辞职后Tony很难找到合适的工作：不能很好地适应互联网公司，外企整体不景气招聘冻结，进入体制内早已过了年龄，创业没有机会和资源，当然也没勇气。而维持家庭高品质生活还需要不小的开支。Tony 在 37 岁这年，学会了抽烟、喝酒，仿佛人生的不顺利，来得稍微晚了一些。
+
+
+最可怕的失业就来自变革引发的技能性淘汰（如：国企下岗），其次是环境引发的萧条（如：金融危机），再次是技能虽然还有普适价值，但自身却适应不了环境变化带来的改变与调整（如：Tony 的危机）。
+
+Tony 面对的危机还是比较少见，属于个人问题。而金融危机也不多见，面对萧条 “血”（储蓄）够厚也可以撑得过去。只有第一种，技能性淘汰，积重难返。四十而不惑，不过四十岁程序员的悲哀在于，他们拥有十五年以上的经历与经验，有时却在和只有五年经验的年轻程序员竞争同样的岗位。
+
+**中年人和年轻人本应在不同的战场上。年轻时，拼的是体力、学习力和适应能力，是做解答题的效率与能力；中年了，拼的是脑力、心力和决策能力，是做对选择题的概率。**
+
+年轻时，是用体力和时间积累经历，换取成长与机会。就拿我来说，从年轻到中年我的体力状态变化是：20 岁以前可以通宵游戏后再接着上一天课；30 岁以前连续一个月加班通宵颠倒，睡一觉后就又精神满满；35 岁以前，还能上线到凌晨两、三点，睡上几小时后，早上 9 点又正常上班；35 岁以后，就要尽可能保持规律作息，否则可能第二天就精神不振了。
+
+所以，中年了体力下降是自然生理规律，但和脑力有关的学习能力并不会有明显改变。记得以前看过一篇万维钢的文章讲了一本书《成年大脑的秘密生活：令人惊讶的中年大脑天赋》，其中提到：
+
+> 
+跟年轻的大脑相比，中年大脑在两个方面的性能是下降的：计算速度和注意力。其他方面，比如模式识别、空间想象能力、逻辑推理能力等等，性能不但没有下降，而且还提高了。
+
+
+计算速度和注意力下降应该是对学习力有一些影响的，但丰富的经历和经验应该可以缩短学习路径，更有效地学习。回顾过往，年轻时学习的路径试错曲线要长得多，所以这一点在学习效率上得到了弥补。而从其他方面看，模式识别、空间想象和逻辑推理意味着中年人的大脑擅长更多高级的工作技能，所以完全没必要担心 “老了” 会导致学习能力下降。
+
+缺乏安全感，正是源自变化，变化带来的不确定性。
+
+环境和人都处在长期持续的变化中，变化总是不确定的，我们没法消除变化，只能把变化纳入考虑，承认变化是永恒的，不确定是长期的。面对这一点很难，难在反人性，我们真正需要做的是战胜自己人性里的另一面 —— 适应变化，无论世界怎样变化，内心依然波澜不惊，就像大海深处，无论海面如何波浪滔天，深处依然静谧悠然。
+
+简言之，人到中年，转换了战场，重新定位自己的优势，转变核心竞争力，浴火重生，开启人生的下半场。
+
+年轻时，我们打的是突击站，左冲右突；中年了，我们打的是阵地战，稳步推进；如今，我们进入了人生的中场战事。**这场战事从谋生的恐惧感开始，给予我们警示；到舍生的无惧感，让我们摆脱束缚，整装待发；最后经过重生的安全感，推动我们再次上升**。
+
+关于中年之惑，你有哪些看法呢？
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/47 | 该不该去创业公司？.md

@@ -0,0 +1,83 @@
+<audio id="audio" title="47 | 该不该去创业公司？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/39/f5/39633a3e736a2cdc3fb90ca4493687f5.mp3"></audio>
+
+大约是 2015 年时，那是一个大众创新、万众创业的 “双创” 年代。当时，创业公司如雨后春笋般出现，又如昙花一现般凋零。也是在那年，招聘时碰到过一个人，一年换了三个公司，我就问：“为什么这么频繁跳槽呢？”而他的答案也让我吃了一惊，他说因为他加入的每家公司，没几个月就都倒闭关门了。
+
+那时候，我和我身边的同事都收到过来自创业公司的邀约，有的同事就此去创业了，而我最终选择了拒绝。后来，我复盘了当时的场景，面临这样的选择，会同时有感性和理性的因素。感性的因素也许每个人都不尽相同，但理性的方面，更有普适性，从中我慢慢提炼和完善成了一组选择决策框架。
+
+## 一、期望
+
+为什么要加入创业公司，你的期望是什么？也许有下面几种原因：
+
+- 自由成长
+- 变身土豪
+- 追求梦想
+
+### 1. 自由成长
+
+创业公司相对成熟的大公司，会有更大的自由度，能接触的东西更多，但需要处理的问题也更多、更杂，会让人更容易自由成长为一种解决各类问题的多面手。这对于程序员而言，很可能就是综合能力更强，但在特定的专业领域又不够精深。
+
+但有些人就会觉得在大公司过于拘束，缺乏自由度，干的事情专业分工很精细，并不适合自己相对广泛的兴趣路线。那么这类人在初创公司也许就会有更多的尝试机会，更大的发挥空间。
+
+### 2. 变身土豪
+
+业界坊间一直流传着创业公司上市 IPO 一夜变身土豪的故事，但我们不妨理性地来分析一下。
+
+最早期的创业公司，大概处在天使轮阶段。作为技术人，如果你的经验和背景足以让你以技术合伙人的身份加入，那么你可以大概拿到公司占比 5% 左右的期权。假如公司最后成功 IPO 上市了，市值 100 亿，那么你的股票兑现就值大约 5 亿了（这里忽略行权和各类税务成本），成功变身土豪。但关键点在于，从天使轮到上市途中，统计数据上显示会倒下 99% 的创业公司。
+
+如果创业公司进展到了 A 轮，你再加入，成为合伙人的概率就低了，更可能成为一名高管。这时能分到的期权会少一个量级，大约 0.5%。最终公司上市，还是 100 亿市值，勉强还能成为一个“瘦”点的土豪。
+
+进一步到了 B 轮，再加入时，想成为高管的能力和背景要求都更高了，这时能拿到的期权比例会进一步下降一个量级，大约 0.05%。100 亿的市值，按这个比例就不太能成为土豪了。
+
+到了 C 轮，公司上市的可能性大大增强，前景可期。但这时加入，能拿到的比例进一步下降一个量级到 0.005%，如果这时公司的上市预期市值就 100 亿，估计也吸引不到什么人了。
+
+变身土豪，其实需要的是增值 100 倍的机会，而最低的下注金额是一年的收入。加入创业公司就是用你的时间下注，能否撞上 100 倍的机会，很多时候就是靠时运。**因上努力，果上随缘，尽人事，听天命**。
+
+### 3. 追求梦想
+
+也许创业做的事情正是你梦想的、喜欢做的事情，人生有时不就是挣钱来买一些 “喜欢” 么？那么你愿为 “喜欢” 支付多大的成本与代价？
+
+在成熟的大公司工作，无论工资还是配股的收益都有很高的确定性。而创业公司即使给你开出同等的工资加上对应的期权，相比大公司的稳定性和持续性，也依然处于劣势。更可能的情况是，创业公司给你的工资加上按目前融资轮次估值的期权价值一起，才勉强和你在大公司每年的确定收益相持平。
+
+站在创业公司的角度，公司通常也不希望招一个只要高工资，不要公司期权的人吧。公司当然会觉得期权价值的不菲，而且每进入下一轮融资期权价值一般都会增幅巨大，拥有很大的增值潜力。而站在你的角度，给期权的正确估值应该是 0，因为期权的兑现日期你无法预期，也许是五年，也可能是十年后，再考虑创业的高失败率，所以一开始就不要寄予太多期望的好。
+
+将期权更多的看作彩票，如果期权让你发了财，这非常好，但是你应当确保自己的工资报酬至少可以接受，也就是说即使你的合同中没有期权，你也仍然会选择加入这家创业公司。这中间相对你在大公司的确定性收益的差距便是追求梦想的直接经济成本，也可以理解为你选择创业的风险投入资本。
+
+最理想情况下，通过一次创业的成功，上述三者期望都一次性实现了。但，现实却往往没那么理想。
+
+## 二、条件
+
+搞清楚了自身的期望与需要付出的成本和代价，再来理性地看看其他方面的因素。
+
+1、**创始人创业的目的是什么**？**期望是什么**？创业毕竟是一段长期的旅程，大家的目的、价值观、期望差距太大，必然走不长远，身边就目睹过这样的例子。
+
+2、**创始人以前的口碑和信用如何**？有信用污点的人并不值得合作与跟随，而且前面说的创业公司期权，最终能否兑现？就国内的创业环境而言，这一点也很是关键。
+
+3、**公司的核心团队成员如何**？看看之前都有些什么样的人，你对这个团队的感觉契合么？价值观对味么？这个团队是合作融洽，还是各怀鬼胎？有些小公司，人虽不多，办公室政治比大公司还厉害。
+
+4、**对你的定位是什么**？创业公司在发展初期容易遇到技术瓶颈，会以招 CTO 的名义，来找一个能解决当前技术瓶颈的专业人才。也许你会被名头（Title）吸引，解决完问题，渡过了这个瓶颈，但这之后老板会觉得你的价值还足够大么？有句话是这么说的：“技术总是短期被高估，长期被低估”。而你自身还能跟得上公司的发展需要么？
+
+5、**公司是否有明确的业务方向**？**业务的天花板多高**？**有哪些对手**？**相对竞争的核心优势是什么**？很多做技术的同学都不太关心业务的商业模式，也许这在大公司可以，毕竟船大，一般也就感觉不到风浪。但在创业公司则不然，业务的天花板有多高？也就是能做到多大？如果公司业务没有明确的方向和优势，你憧憬着踏上了火箭，结果却是小舢板，起风时感觉还走得挺快，风一停，就只好随波荡漾了。
+
+也许还有很多其他方面你关注的条件和因素，在选择前都可以先列出来比较。只是最后我比较确定的一件事是，不会有任何一家公司满足你所有心仪的条件，这时就需要你做决策了。
+
+## 三、决策
+
+决策之前，期望是内省，条件是外因；决策就是将客观的外因与主观的内省进行匹配判断选择的过程。
+
+决策很难，让人经常很矛盾，很沮丧。往回看，我们总能找到适合自己的最优决策路径，但当初却并没有选到这条路，所以沮丧。往前看，其实有无数的路径分支，我们怎么可能选中最优路径，有这样的方法吗？没有。
+
+这样的决策就像古时先哲讲过的一个故事，大意是：你有一个机会经过一条路，这条路两边都是大大小小的宝石，但你只能走过这条路“一次”，捡起其中“一块”宝石，中间不能更换。这里捡到最大的宝石就是最优策略，但你怎么实现这个最优策略呢？其实没有方法能保证。
+
+而先哲的建议是，前 1/3 的路径，你只观察周围的宝石，最大的有多大，平均大小大概在什么水平，但不出手捡。经过这前 1/3 的路程，你应该有一个预期的大小标准，这个标准可能略比平均大小大一些，但不应该以之前看见的最大的宝石为标准。再走剩下的 2/3 路程时，你只要看见第一个符合这个标准的宝石，就可以出手捡起，之后快速走完全程。
+
+这个方法虽不能保证你捡到最大的宝石，但可以很大概率保证你捡到符合自己预期标准大小的宝石，而这个预期标准，就是你的 “满意标准”。这个捡宝石的决策就是 “**满意决策**”，满意决策是一种折衷决策，只是在当时情况下可选的最佳行动方案。
+
+人生中会有很多类似 “捡宝石” 这样的决策场景：找工作、找伴侣、选房子、买股票，甚至是买任何东西，只不过因为其中大部分东西的购买支付代价低，所以你不会有太大的决策压力。前 1/3 的路程就是让你在决策前充分观察、调研、确定你的满意标准，之后面对第一个满意对象就能够直接决策，然后继续快速前行。
+
+满意决策的方案就是让你做完决策不纠结，即使后来回头看离最优还有差距，也不遗憾。因为，人一生要面对的决策很多，“满意决策” 的办法让你省下了 2/3 纠结的路程，继续快速前行。
+
+最后，当你面临加入创业公司的选择时，问问你的期望，评估现实的条件，再做出满意的选择；决策过后，可能有遗憾，但没不甘。
+
+如今在创业公司的你，当初是如何选择的呢？或者你是怎么看待这件事的呢？
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/48 | 该不该接外包？.md

@@ -0,0 +1,100 @@
+<audio id="audio" title="48 | 该不该接外包？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/40/b4/409f18991dd6ba8273ae24a12de299b4.mp3"></audio>
+
+以前我曾接到过一些关于程序外包站点的营销邮件，也看到过身边有些人选择去接一些外包，赚点外快。当然也有人找到过我做外包项目，这时我就必须做出一个评估和选择，面对外包赚钱的诱惑，到底该如何进行更好的选择呢？
+
+## 赚钱与诱惑
+
+外包的直接诱惑，就是能立刻增加工资之外的收入，赚点外快。
+
+但反过来，我们需要问自己的是：需要为赚点外快去接外包吗？为此，我先去调研考察了一番现在的程序员外包市场。好几年前，我留意了一个程序员外包平台，已有好几万签约开发者了，如今再去看时，已有近二十万程序员了。这不免让我思考：什么样的程序员会去这样的平台上接外包项目呢？
+
+我把该平台上的程序员页面列表挨着翻了十来页，发现了一个规律。我看过的这些签约程序员多数工作经验在三到五年之间，还看到一个创业公司的创始人，可能是目前创业维艰，接点外包项目来维持团队生存吧。
+
+但总的来说，来这里接单的很大一部分程序员应该都是想要赚点工资之外的钱吧。赚钱本无错，只是程序员除了接兼职外包项目还有什么其他赚钱方式吗？我想了想，程序员赚钱的方式大概有下面这些。
+
+**咨询/培训**。一般被外部企业邀请去做咨询或培训的程序员，根据个体差异可能报酬从几千到几万不等吧，但能够提供此类服务的程序员，对其本身的素质要求较高，而且来源不稳定，所以不具有普适性。
+
+**演讲/分享**。程序员圈子经常会有一些技术分享大会，有些组织者会对提供分享的讲师支付一点报酬，具体数额可能因“会”而异吧，但一般不会比咨询和培训类更多。
+
+**投稿/翻译**。一些写作和英语能力都不错的程序员可以向技术媒体去投稿或翻译稿件。原创千字标准一百五左右，而翻译会更低些，看译者的水平从千字几十到一百左右。
+
+**写书**。也有不少程序员写书出版的，但基本都是技术类图书。对于图书版税，一个非著名作者不太可能超过 10%，而能卖到一万册的国内技术书籍其实并不多，假如一本书销售均价50元，那你可以自己算下大概写一本书能挣多少。畅销和长销的技术类图书，基本都成了教材，而现实中要写一本优秀的教材保持十数年长盛不衰，是件极困难的事。
+
+**写博客/公众号**。十年前大家写博客，现在很多人都写公众号。博客是免费阅读，靠广告流量分成赚钱，但其实几乎就没几个有流量的独立博客，都是聚合性的博客站赚走了这部分钱。
+
+而公众号开创了阅读打赏模式，有些人看见一些超级大V随便写篇文章就有几千人赞赏，觉得肯定赚钱。但其实写公众号的人真没有靠赞赏赚钱的，赞赏顶多算个正向鼓励罢了。一个拥有十万读者的公众号，实际平均每篇的打赏人数可能不到 50 人，而平均打赏单价可能不到5元。这么一算，假如一篇文章 2000 字，还不如投稿的稿费多。所以持续的博客或公众号写作基本靠兴趣，而能积累起十万读者的程序员几乎属于万中无一吧。
+
+**课程/专栏**。这是今年才兴起的形式，一些有技术积累和总结表达（包括：写和讲）能力的程序员有机会抓住这个形式的一些红利，去把自己掌握的知识和经验梳理成作品出售。但能通过这个形式赚到钱的程序员，恐怕也是百里挑一的，普适性和写书差不多。
+
+**兼职/外包**。这就是前面说的外包平台模式，平台发布项目，程序员注册为签约开发者，按人天标价，自己给自己的人天时间估值。我看平台上的跨度是一天从 300 到 2000 不等。
+
+各种赚钱方式，分析了一圈下来，发现其实对于大部分程序员而言，最具普适性的还是兼职外包方式。因为其他方式都需要编程之外的一些其他技能，而且显然兼职外包方式相比较而言属于赚钱效率和收入最高的一种方式，无怪乎会有那么多程序员去外包平台注册为签约开发者。
+
+只是，这种方式的赚钱性价比真的高吗？短期的直接收入回报诱惑很大，但长期的代价和成本呢？
+
+## 成本与比较
+
+接外包的短期成本是你的时间，那长期的成本和代价呢？
+
+桥水基金创始人雷·达里奥（Ray Dalio），也是近年畅销书《原则》的作者，制作过一个视频叫《三十分钟看清经济机器如何运转》，他在视频的末尾提出了三条建议：
+
+> 
+<ol>
+- 不要让债务的增长速度超过收入。
+- 不要让收入的增长速度超过生产率。
+- 尽一切努力提高生产率。
+</ol>
+
+
+这三条建议虽然是针对宏观经济的，但我理解转化一下用在个人身上也是无比正确啊。特别是第二条，现下多接外包提高了当下的收入，但长期可能会抑制你的生产率，让你失去竞争力。为什么呢？举个例子，我们经常在电影里能看到这样一些熟悉的画面，白天晚上打着几份工的人为生活疲于奔命，那他（她）还有时间来做**第三条**吗？疲于奔命导致个人生产率增长的停滞，未来竞争力的下降。
+
+生产率是一个宏观经济术语，用到程序员个人身上可不能直白地理解为产出代码的效率，正确的理解我认为是个人价值的产出率，即如下等式：
+
+> 
+个人生产率 = 个人价值的产出率
+
+
+基于以上理解，面临当初的外包项目我的选择是：拒绝。因为，它带来的收入是一次性的，不具备积累效应，而且相比我的全职工作收入还有差距，短期也许能增加点收入，但也没有其他任何意义了。如果老是去接这样的事情，长期的代价必然是个人生产率的降低，得不偿失。
+
+但我确实还做一些不赚钱的事，比如过去多年经常写作，偶尔翻译，我所做的这些事情的直接目的都和提高现阶段的收入（立刻多赚钱）没关系，只是想尽可能地在提高个人价值的同时提升价值产出率，也就是说在做达里奥所说的**第三条建议**。
+
+不过，个人价值的提升可能不会立刻反映到当下的收入上，就像公司的内在价值提升了可能股价还没涨一样。但长期来看，价格总是要回归价值的，这是经济规律，宏观如国家，微观如个人。
+
+## 值钱与选择
+
+该不该接外包的选择本质是：**选择做赚钱的事，还是值钱的事**？
+
+梁宁有篇文章就叫《赚钱的事和值钱的事》，文中总结了这两点的差别：
+
+> 
+赚钱的事，核心是当下的利差，现金现货，将本求利。
+值钱的事，核心是结构性价值，兑现时间，在某个未来。
+
+
+**从赚钱的角度看**，前面分析的所有赚钱方式的赚钱性价比都很低，完全不值得做。你可能会反驳说，外包项目的收入可能也不低，甚至比你的全职工资还高，怎么会认为赚钱性价比很低呢？一方面，全职工作提供的收入是稳定的；另一方面，兼职外包的收入多是临时的，一次性而不稳定的。若你能持续稳定地获得高于全职工资的外包收入来源，那么仅从赚钱角度看，更好的选择可能应该是去全职做外包了。
+
+**从值钱的角度看**，前面分析的所有赚钱方式，在以个人价值增值为出发点的前提下，是值得尝试的。正因为兼职外包接单对很多程序员具有普适性，所以针对这件事情的**出发点应该是看是否以个人价值及其增长为归依**，而非是为了当下能多赚点钱。过于专注短期的收入提升，可能会“一叶障目”，忽视了长期的价值增值。
+
+为了多赚点外快牺牲当下所有的业余时间，这值得吗？这种兼职外包项目对于自身的价值增值有多大的帮助？这是你需要反问和思考的问题。我估计很多兼职项目都是低水平的重复劳动，其实不止是兼职，甚至很多全职工作亦是如此。
+
+说个例子，刚毕业时，我被分配维护一些历史遗留 Java Web 项目，可能因为毕业时我已有了些 Java Web 相关的课程设计经验；而和我一起加入公司的另一个校友则完全没有这方面的基础，所以被安排维护另外一个历史遗留基于 IBM Lotus Notes 的系统。
+
+估计 Lotus 这套东西现在几乎绝迹了，在当时也是非技术主流，只不过因为历史原因还需要维护。既然公司出钱招聘了我们，为了生存和生活，刚毕业的我们其实没有多少挑选工作内容的机会。因此他在维护 Lotus 项目之余，还在不断地学习 Java 相关的内容，找一些业余项目来做并练习，为下一次的工作转型做准备。我认为像他这样以此为出发点的兼职或业余项目都是没问题的。
+
+为什么外包平台上（我观察下来）三到五年的签约程序员最多？我揣摩可能与他们所处的阶段有关，正是处在结婚安家的阶段，收入敏感度较高。但牺牲未来潜在的生产率增长来换取当下收入临时且不高的增幅，是不值得的。
+
+在价值积累到一定阶段之前，收入增长得并不明显，这阶段人和人之间的收入差距其实很小。想想同一家公司、同一个岗位、同样工作三到五年的程序员，收入能有多大差距呢。这阶段你即使花费所有的业余时间来赚钱，与你的同龄人拉开的收入差距也不会大。
+
+而我观察多数真正拉开差距的阶段是在工作的十年到二十年之间，根据个人的价值积累大小，价值结构变现的机遇，拉开的差距是数量级的差别，会让你生出“当时看起来我们差不多，但如今他干一天能抵我干上一个月甚至一年了”的感慨，所以**前十年不妨把关注的焦点放在个人价值的增值上**。
+
+最后，再总结下到底“该不该接外包”这个问题。我认为**值得接的外包，它包括下面一些特性**：
+
+1. 如果外包项目对你的技术积累有好处，那么收点钱去实践提升下正好一举两得；其实参与开源项目，本质上不就是不收钱的外包项目？它的收益就是让你更值钱。
+1. 外包项目的成果具有可复制、可重用性，这样就可以通过大量复制和重用来降低一次性开发成本；而成本和比较优势才是外包模式的核心竞争力所在啊。
+1. 外包项目不是临时一次性的，而是需要长期维护的，而这种维护的边际成本可以依靠技术工具手段不断降低，那这样的外包项目就是一个长期赚钱的 “机器” 了。
+
+所有以上特性都反映了一个本质：**去做值钱的事，打造值钱的结构，从知识结构、技能结构到作品结构与产品结构，然后等待某个未来的兑现时间**。
+
+末了，也谈谈你对外包项目的看法吧，欢迎留言。
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/49 | 技术干货那么多，如何选？.md

@@ -0,0 +1,90 @@
+<audio id="audio" title="49 | 技术干货那么多，如何选？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/00/ac/00181f44f35f76efbbc3b173cece89ac.mp3"></audio>
+
+在我刚进入行业的早些年，也是互联网的早期，其实网上的信息都不算特别多，而技术干货类信息更是少，所以就养成了一个习惯，遇到好的技术干货类文章就会收藏下来。这个习惯延续了多年，后来某天我突然发现仅仅是微信收藏夹内保存的技术干货型文章就已经累积了半年之多，都没时间去阅读和筛选。
+
+收藏了如此多的干货，半年没读似乎也没缺了啥，那么还有必要读吗？2011 年时，我刚进入互联网行业，那已是互联网时代的成熟期，移动互联网的孕育期，也肯定是信息爆炸的时代，但依然是技术干货寥寥的时期。如今，却已是连技术干货也进入了爆炸期，那我们该如何挑选与应对？
+
+## 循证与决策路径
+
+为什么我们会去挑选和阅读技术干货文章？我想，循证大概是一个原始诉求，通过分析别人走过的路径，来拨开自己技术道路探索上的迷雾。
+
+循证方法，也是我早年刚接触 J2EE 开发时遇到的技术决策指导思想，记得**J2EE Development without EJB**一书的译序中有一段话，很好地阐释了 “循证” 方法：
+
+> 
+任何一个从事 J2EE 应用开发的程序员或多或少都曾有过这样的感觉：这个世界充斥着形形色色的概念和 “大词”，如同一个幽深广袤的魔法森林般令人晕头转向，不知道该追随这位导师还是该信奉那个门派。
+这时，Rod Johnson 发出振聋发聩的一呼：尔等不必向泥胎偶像顶礼膜拜，圣灵正在尔等自身 —— 这就是他在书中一直倡导的 “循证架构”。选择一种架构和种技术的依据是什么？Rod Johnson 认为，应该是基于实践的证据、来自历史项目或亲自试验的经验……
+
+
+所以，我们去阅读技术干货文章，**想从别人的分享中获得对自己技术方案的一个印证。这就是一种行业的实践证据，毕竟想通过听取分享去印证的，通常都是走过了一条与自己类似的道路**。技术道路的旅途中充满着迷雾与不确定性，我们不过是想在别人已走过的类似道路中获得指引和启发，并得到迈出坚实下一步的信心。
+
+这就是**循证方式的技术决策路径**。
+
+多年前，我们刚开始做咚咚这个 IM 系统时，就是沿着这条路径一路过来的。
+
+刚启动是 2012 年，一开始其实是完全不知道怎么迈步，专门花了三个月时间来研究业界的 IM 软件系统都是怎么做的。当时行业 IM 第一的当属 QQ，但那时腾讯公司的技术保持神秘而低调，在互联网上几乎找不到任何公开的技术分享资料。
+
+退而求其次，我们只好研究起开源的 IM 软件，也就是基于 XMPP 开放协议实现的一类开源 IM 服务端和客户端，并以此为基础去设计我们自己的 IM 架构，然后实现了一个最初的原型。
+
+再后来，腾讯终于有一位即时通讯的 T4 专家出来分享了一篇关于 QQ 的后台技术架构演进之路，记得是叫《1.4亿在线背后的故事 —— QQ IM后台架构的演化与启示》。我仔细听了一遍，又把分享材料翻过好多遍，思考并体会其中的架构演化道路。
+
+数年后，微信在移动互联网时代崛起，并且在 IM 领域甚至还超越了 QQ，微信团队也分享了其后端架构演进之路。此时，我们自身的架构也基本成型并运行一些年了。而我也注意到，关于 IM 类消息应用最核心的一个技术决策是：**消息模型**。微信的方式和我们并不一样。
+
+微信的方式是基于消息版本的同步加存储转发机制，而我们则是基于用户终端状态的推送加缓存机制。微信的机制从交互结构上更简洁和优雅一些，在端层面的实现复杂度要求更低，符合其重后端、轻前端的设计思路和原则。
+
+然而，循证的方式就是：即便你看到了一个更好的技术与架构方式，但也要结合自身的实际情况去思考实践的路径。消息模型，作为一个核心的底层架构模型，也许刚起步未上线时，变更优化它只需要一两个程序员一两周的时间；但经过了数年的演进，再去完全改变时，就需要各端好几个团队配合，并忙上一两个季度了。
+
+循证，不一定能立刻给你的当下带来改变，但可以给你的演进路径方向带来调整，未来将发生改变。
+
+## 切磋与思考方式
+
+技术干货多了以后，在类同的领域都能找到不同公司或行业的实践分享，这时不仅可以循证，还能够达到切磋和多元化思考的目的。
+
+处在 IM 这个领域，我就会经常去看关于 IM 相关技术领域的干货文章，所以我知道了微信的消息模型采用了推拉结合，还有基于版本的同步机制。但我不会再纠结于为什么我们不同，而是去看到它的好处与代价。
+
+一个更具体的切磋案例：大家都熟悉且特别常用的功能 —— 群消息。关于群消息模型，微信采用的是写扩散模型，也就是说发到群里的一条消息会给群里的每个人都存一份消息索引。这个模型的最大缺点就是要把消息索引重复很多份，通过牺牲空间来换取了每个人拉取群消息的效率。
+
+好多年前我们刚开始做群时，也是采用了的写扩散模型，但后来因为存储压力太大，一度又改成了读扩散模型。在读扩散模型下，群消息只存一份，只需记录每个群成员读取群消息的偏移量，偏移量的记录相比消息索引量要小几个量级，所以减轻了存储压力。
+
+而之所以存储压力大在于当时公司还没有一个统一的存储服务组件，我们直接采用Redis的内存存储，当时原生的 Redis 在横向和纵向上的扩展性都比较受限。这在当时属于两害相权取其轻，选择了一个对我们研发团队来说成本更低的方案。
+
+再后来公司有了扩展性和性能都比较好的统一存储组件，实际再换回写扩散模型则更好。毕竟读扩散模型逻辑比较复杂，考虑自己不知道加了多少个群了，每次打开应用都要检查每个群是否有消息，性能开销是呈线性递增的。
+
+同一个技术方案在不同的时期，面临不同的环境，就会带来不同的成本，并做出不同的选择与取舍。虽然看起来是在走类似的路，但不同的人，不同的时代，不同的技术背景，这些都导致了终究是在走不同的路。路虽不同，但可能会殊途同归吧。
+
+切磋带来的思考是：**你不能看见别人的功夫套路好，破解难题手到擒来，就轻易决定改练别人的功夫**。表面的招式相同，内功可能完全不同，就像金庸小说里的鸠摩智非要用小无相功催动少林七十二绝技，最后弄得自废武功的结局。
+
+切磋，主要是带给你不同的思维方式，用自己的功夫寻求破解之道。
+
+## 连结与知识体系
+
+干货多了，时间有限，自然就存在一个优先级的选择阅读问题。
+
+就我个人来说，我的出发点很简单，有两点：基于功利性和兴趣。说起功利性也别觉得不好，毕竟整个商业社会都是基于功利性为基础的，所以基于此的选择其实是相当稳定的。考虑下所在组织和团队的功利性需求来做出技术的选择，有时甚至是必须的，而不能完全由着兴趣来驱动。
+
+我在前文[《领域：知识与体系》](https://time.geekbang.org/column/article/40160)中已经有过说明，我会把过去自己所掌握的所有技术总结编织成一张“网”，若一个技术干货分享的东西离我的“网”还太远，我就会放弃去了解。因为如果不能连结到这张“网”中，形成一个节点，我可以肯定它就很难发挥任何作用，很可能是我看过之后没多久就遗忘了。
+
+如今技术发展百花齐放、遍地开花，但人生有限，所以你必须得有一种方式去做出选择，最差的可能就是所谓的随性选择。我觉得很多情况下是需要一个选择指导框架的，而对于如何选择阅读技术干货的问题，前面比喻的那张“网”就是一个我自己的指导框架。
+
+即便是针对同一个问题或场景，我们也可以将已知的部分连结上新的知识和实践，形成更密、更牢固的技术体系之网。
+
+刚做 IM 时，曾经有个疑惑，就是 IM 的长连接接入系统，到底单机接入多少长连接算合适的？很早时运维对于长连接有个报警指标是单机 1 万，但当时我用 Java NIO 开 2G 最大堆内存，在可接受的 GC 停顿下，一台 4 核物理机上测试极限支撑 10 万长连接是可用的。那么平时保守点，使用测试容量的一半 5 万应该是可以的。
+
+之后一次机会去拜访了当时阿里旺旺的后端负责人，我们也讨论到了这个长连接的数量问题。当时淘宝有 600 万卖家同时在线，另外大概还有 600 万买家实时在线，所以同时大概有 1200 万用户在线，而当时他们后端的接入服务器有 400 台，也就是每台保持 3 万连接。他说，这不是一个技术限制，而是业务限制。因为单机故障率高，一旦机器挂了，上面的所有用户会短暂掉线并重连。若一次性掉线用户数太多，恢复时间会加长，这会对淘宝的订单交易成交产生明显的影响。
+
+他还说了一次事故，整个机房故障，导致单机房 600 万用户同时掉线。整个故障和自动切换恢复时间持续了数十分钟，在此期间淘宝交易额也同比下降了约 40% 左右。因为这种旺旺在线和交易的高度相关性，所以才限制了单机长连接的数量，而当时已经有百万级的单机长连接实验证明是可行的。
+
+在一篇关于微信红包的的技术干货文章《100亿次的挑战：如何实现一个“有把握”的春晚摇一摇系统》里提到：
+
+> 
+在上海跟深圳两地建立了十八个接入集群，每个城市有三网的接入，总共部署了 638 台接入服务器，可以支持同时 14.6 亿的在线。
+
+
+简单算一下，大概就是 228.8 万单机长连接的接入能力，14.6 亿怕是以当时全国人口作为预估上限了。实际当然没有那么多，但估计单机百万长连接左右应该是有的。这是一个相当不错的数量了，而采用 Java 技术栈要实现这个单机数量，恐怕也需要多进程，不然大内存堆的 GC 停顿就是一个不可接受和需要单独调优的工作了。
+
+以上就是从干货中提取知识和经验总结的案例，形成对已有知识的连结。这就是不断加固并扩大自己的技术知识体系之网。
+
+**总结来说：面对众多的技术干货，从循证出发，找到参考，做出技术决策，决定后续演进路线；在演进路上，不断切磋，升级思考方式，调整路径，走出合适的道路；在路上，把遇到的独立的知识点，不断吸收连结进入自己的技术知识体系之网**。
+
+回答了标题的问题，这篇文章也该结束了。面对技术这片大海，我们都是一个渔民，三天打鱼，两天结网。愿你的“网”越结越大，捞的“鱼”也越来越多，也欢迎留言分享下你的“打鱼”和“结网”经历。
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/50 | 技术分歧，如何决策？.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="50 | 技术分歧，如何决策？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/79/6a/79fefee685f214c5d7b90f2c4fe3c86a.mp3"></audio>
+
+作为一名程序员或技术人，总会碰到这样的场景：在一些技术评审会上，和其他程序员就技术方案产生分歧与争论。如果你是一名架构师或技术 Leader，站在技术决策者的立场和角度，该如何去解决分歧，做出决策呢？
+
+这背后，有什么通用的方法和原则吗？
+
+## 绝对
+
+曾几何时，我以为技术是客观的，有绝对正确与否的标准判断。
+
+在学校我刚开始学习编程技术时，捧着一本数据库教材，它在述说着经典的关系数据库表设计原则：第一、第二、第三范式。后来，我参加工作，那时的企业应用软件系统几乎都是以数据库为核心构建的，严格遵守范式定义的表结构。所以，当时觉得所有不符合范式设计的应用肯定都是错的，直到后来进入大规模的分布式领域，碰到了反范式设计。
+
+也还是在学校做课程设计时，一起学习的同学总跟我讨论设计模式。一边写代码，一边研究这个代码到底符不符合某种模式，似乎没有套进某种模式中的代码就像没有拿到准生证的婴儿，带有某种天生的错误。直到后来，我碰到了反模式设计。
+
+刚工作不久，同事和我讨论当用户删除自己的数据时，我们到底应不应该删掉它？我那时觉得理所应当写个 Delete 的 SQL 语句把它删掉。因为当时是这么想的：既然用户都不要他的数据了，我们还把它保留下来做什么呢？不是浪费资源嘛，而且服务器存储资源还算挺贵的。
+
+但今天的互联网大数据时代，用户主动或非主动提交的任何数据，你都别想再将它真正地删除了。这个时代，受益于**摩尔定律**，存储设备容量不断增加，而价格不断降低，所有关于用户的数据总是可能有用的，都先存下来再说。
+
+做技术这么些年下来，关于技术方案的判断，曾经以为的绝对标准，今天再看都是相对的。
+
+## 相对
+
+的确是的，适合的技术决策总是在相对的条件下做出的。
+
+曾经，读到一篇英文文章，其标题翻译过来就是《简化：把代码移到数据库函数中》。我一看到这个标题就觉得这是一个错误的技术决策思路，为什么呢？因为曾经我花了好长时间做了一个项目，就是把埋在数据库存储过程中的代码迁移到 Java 应用里；而且，现在不依赖数据库的代码逻辑不正大行其道吗？
+
+作者是在正话反说，还是在哗众取宠？我很是好奇。所以，我就把这篇文章仔细读了一遍，读完以后我发现作者说得似乎有些道理，他的说法我大概概括为如下。
+
+作者说，如今绝大部分的 Web 应用包括两部分：
+
+- 一个核心数据库，负责存储数据；
+- 以及围绕数据库的负责所有业务智能与逻辑的代码，体现为具体编程语言的类或函数。
+
+现在几乎所有的 Web 系统都是如此设计的，所以这像是真理，业界最佳实践，事实工业标准，对吧？但作者描述了他自己的经历，是下面这样的。
+
+他从 1997 年开始做了一个电子商务网站，用了 PostgreSQL 作为数据库，第一版网站用 Perl 写的。1998 年换成了 PHP，2004 年又用 Rails 重写了一遍。但到2009年又换回了 PHP，2012 年把客户端逻辑拆出去用 JavaScript 重写，实现了前后端分离。
+
+这么些年下来，代码重构过很多次，但数据库一直是 PostgreSQL。可是大量和数据存取有关的逻辑也随着代码语言的变迁而反复重写了很多遍。因而，作者感叹如果把这些与数据存取有关的逻辑放在数据库里，那么相关的代码将不复存在，他也不需要反复重写了。
+
+这里有个疑问，作者没事老换语言，到底是在折腾啥？他虽然没有在文中明说，但作为程序员的我还是能设身处地感受到其中的缘由。作者本身是学音乐出身，目标是建网站卖音乐唱片，自学编程只是手段。作为一个过来人，我相信他早期的代码写得肯定不咋地，又在各种流行 Web 技术趋势的引诱下，充满好奇心地尝试各种当时时髦的技术，不断重构改进自己的代码。
+
+在这个过程中发现，有一些和业务关系不太大的数据存取逻辑，被反复重写了很多遍，所以才产生出了这样的思路：假如把这部分代码移到数据库中。其实对这个思路的挑战，也是显而易见的：
+
+- 如何进行调试、回滚？
+- 如何做单元测试？
+- 如何进行水平扩展？
+
+上述“挑战”在一般情况下都成立，但对于作者来说却不是很重要。因为作者思路成立的前提是：第一，他维护的是一个小网站，数据库没有成为瓶颈；第二，这个网站的开发维护人员只有作者一个人，而不是一个团队。
+
+是的，围绕这个网站，作者创办了一家公司，雇佣了 85 名员工，并成为了公司的 CEO 也是唯一的程序员。因此，这就是一个在作者所处特定环境下的技术决策，虽看上去明显不太对，但在作者的相对限定条件下，这个决策实际省了他个人的负担（虽然扩展有明显的极限，网站也不会发展太大）。
+
+仔细看作者这个案例，可以发现其技术决策方案也是符合 “康威定律” 的。“康威定律”是这么说的：
+
+> 
+任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
+
+
+换句话说，就是系统设计的通信结构和设计系统的团队组织的沟通结构是一致的。案例中，作者的系统只有他一个人负责设计与实现，只需要和不同阶段的自己产生沟通，在他的系统和场景下，变化最小、稳定度最高的是数据存储和结构，所以他选择把尽可能多的代码逻辑绑定在系统中更稳定的部分，从而降低变化带来的代价。
+
+而**康威定律告诉我们系统架构的设计符合组织沟通结构时取得的收益最大**。这是一个经过时间检验和验证过的规律与方法，体现的就是一个相对的选择标准，那在这背后，有没有隐藏着关于技术决策更通用的判断原则呢？
+
+## 原则
+
+康威定律，是和组织的团队、分工、能力与定位有关的，其本质是**最大化团队的核心能力，最小化沟通成本**。
+
+在足够大的组织中，沟通成本已经是一个足够大的成本，有时可能远超采用了某类不够优化的技术方案的成本。每一次人事组织架构变动的背后，都意味着需要相应的技术架构调整去适应和匹配这种变化，才能将沟通成本降下来。而**技术方案决策的核心，围绕的正是关于方案的实施成本与效率**。
+
+曾经很多次的项目技术评审会上，后端的同学和前端的同学经常就一些技术方案产生争论。而争论的问题无所谓谁对谁错，因为同样的问题既可以后端解决，也可以前端解决，无论哪条路都可以走到目的地。那么还争论什么呢？无非是各自基于局部利益的出发点，让自己这方更省事罢了。
+
+这些问题的解决方案处在技术分工的临界地带就容易产生这样的争论，而技术的临界区，有时就是一些无法用技术本身的优劣对错来做判断的区域。这时，最佳的选择只能是将前后端整体全盘考虑，以成本和效率为核心来度量，应该由哪方来负责这个临界区。
+
+而**成本与效率背后的考量**又包括如下因素：
+
+- **团队**：这是人的因素，关于团队的水平，掌握的技术能力和积累的经验；
+- **环境**：能利用的环境支持，公司内部的平台服务或外部的开源软件与社区；
+- **技术**：技术本身的因素，该项技术当前的成熟度，潜在的发展趋势；
+- **约束**：其他非技术约束，比如管理权限的干涉、限定死的产品发布日期等。
+
+不同的人，同样的技术方案，成本效率不同；不同的环境，同样的技术方案，成本效率也不同；不同的技术，同样的环境和人，成本效率也不同；不同的约束，同样的团队和环境，会得到不同的技术方案，成本效率自然不同。
+
+在技术的理想世界中，技术决策的纯粹部分，其决策原则都和成本效率有关；而其他非纯粹的部分，其实都是 “政治” 决策，没有所谓通用的原则，只和博弈与利益有关。
+
+最后，简单总结下：**技术没有绝对的标准，适合的技术决策，总是在受限的约束条件下，围绕成本与效率做出的选择权衡。对于一些纯粹的技术理想主义者，追求技术的完美与合理性，初心本不错，但也许现实需要更多的行动柔性**。
+
+关于技术方案分歧，你是否遇到过类似的争论呢？又是采用的是怎样的决策方式？欢迎留言分享和大家一起讨论。
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/51 | 技术债务，有意或无意的选择？.md

@@ -0,0 +1,93 @@
+<audio id="audio" title="51 | 技术债务，有意或无意的选择？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0d/4b/0d19006fb2f42706d187e35abe53b34b.mp3"></audio>
+
+在编程的路上，我们总会碰到历史系统，接手遗留代码，然后就会忍不住抱怨，那我们是在抱怨什么呢？是债务，技术债务。以前说过，**代码既是资产也是债务**，而历史系统的遗留代码往往是大量技术债务的爆发地。
+
+然而，技术债务到底是如何产生的？它是我们有意还是无意的选择？这里就先从技术债务的认知开始谈起吧。
+
+## 认知
+
+技术债务，最早源自沃德·坎宁安（Ward Cunningham） 1992 年在一次报告上创造的源自金融债务的比喻，它指的是**在程序设计与开发过程中，有意或无意做出的错误或不理想的技术决策，由此带来的后果，逐步累积，就像债务一样**。
+
+当作为程序员的我们采用了一个非最优或不理想的技术方案时，就已经引入了技术债务。而这个决定，可能是有意的，也可能是无意的。有意产生的债务，一般是根据实际项目情况，如资源与期限，做出的妥协。
+
+而无意产生的债务，要么是因为程序员经验的缺乏引入的，要么是程序员所处的环境并没有鼓励其去关注技术债务，只是不断地生产完成需求的代码。但只要程序员在不断地生产代码，那他们就是在同时创造资产与债务。债务如果持续上升，软件在技术上的风险就不断增加，最后慢慢走向技术破产。
+
+以前看过另一位程序员写的一篇文章，名字就叫《老码农看到的技术债务》，印象还是比较深刻的。文中把技术债务分成了好几类，我记得的大概有如下：
+
+- 战略债务
+- 战术债务
+- 疏忽债务
+
+**战略债务**，是为了战略利益故意为之，并长期存在。我理解就是在公司或业务高速发展的阶段，主动放弃了一些技术上的完备与完美性，而保持快速的迭代与试错性。在这个阶段，公司的战略利益是业务的抢占，所以此阶段的公司都有一些类似的口号，比如：先完成，再完美；优雅的接口，糟糕的实现。
+
+这类债务的特点是，负债时间长，但利息不算高且稳定，只要保持长期 “付息”，不还本金也能维持下去。
+
+**战术债务**，一般是为了应对短期紧急情况采取的折衷办法。这种债务的特点就是高息，其实说高利贷也不为过。
+
+这类债务，一直以来经常碰到。比如，曾经做电信项目时，系统处理工单，主流程上有缺陷，对某一类工单处理会卡住。这时又不太方便停机更新程序，于是就基于系统的动态脚本能力去写了个脚本临时处理这类工单，可以应对当时业务经营的连续性，但缺陷是资源开销大，当超过一定量时 CPU 就会跑满了。这样的技术方案就属于战术债务的应用。为避免“夜长梦多”，当天半夜的业务低谷，我就重新修复上线了新程序，归还了这笔短期临时债务。
+
+**疏忽债务**，这类债务一般都是无意识的。从某种意义上来说，这就是程序员的成长性债务，随着知识、技能与经验的积累，这类债务会逐步减少。另一方面，如果我们主动创造一个关注技术债务的环境，这类债务就会被有意识地还掉。
+
+从上面的分类可以看出，战略和战术债务都是我们有意识的选择，而疏忽债务正如其名，是无意识的。但不论技术债务是有意的还是无意的，我们都需要有意识地管理它们。
+
+## 管理
+
+对于技术债务，开发团队中的不同角色关注的债务分类与形态也不太一样。
+
+比如架构师关注的更多是战略债务，保持系统能够健康长期演进的债务平衡。作为架构师，就像 CFO，需要长期持续地关注系统的资产负债表。战略债务可能更多体现为架构、设计与交互方面的形态。而具体某个功能实现层面的代码债务，则更多落在相关开发工程师的关注范围内。测试工程师，会关注质量方面的债务，而一到交接时，各种文档债务就冒出来了。
+
+那对于一个软件系统，我们如何知道技术债务已经积累到了需要去警示并着手计划进行还债的阶段了呢？一般来说，我们直觉都是知道的。
+
+举个例子来说明下，好几年前团队接手继续开发并维护一个系统，系统的业务一开始发展很快，不停地添加功能，每周都要上好几次线。一年后，还是每周都要上好几次线，但每次上线的时间越来越长，回归测试的工作量越来越大。再后来，系统迎来了更多的新业务，我们不得不复制了整个系统的代码，修改，再重新部署，以免影响现有线上系统的正常运行…
+
+到了这样的状况，每个人都知道，债务在报警了，债主找上门了。一次重大的还债行动计划开始了，由于还债的名声不太好听，所以我们喜欢叫：架构升级。架构升级除了还债，还是为未来铺路。当然，前提是要有未来。如果未来还能迎来更大的业务爆发增长，架构升级就是为了在那时能消化更多的长短期债务。
+
+**管理债务的目标就是识别出债务，并明了不同类型的债务应该在何时归还，不要让债务持续累积并导致技术破产**。一般来说，只要感觉到团队生产力下降，很可能就是因为有技术债的影响。这时，我们就需要识别出隐藏的债务，评估其 “利率” 并判断是否需要还上这笔债，以及何时还。
+
+有时，我们会为债务感到焦虑，期望通过一次大规模重构或架构升级还掉所有的债务，从此无债一身轻。其实，这是理想状态，长期负债才是现实状态。
+
+## 清偿
+
+在产品突进，四处攻城略地时，还需要配合周期性地还债，保持债务平衡，才能保证系统整体健康稳步地发展。
+
+首先，我们认识并理解了技术债务，识别出了系统中的各种债务，并搞清楚了每种债务的类型和利率，这时就需要确定合理的清偿还债方式了。
+
+对于战略债务，长期来说都是持续付利。就像现实中一些大企业从银行借钱经营发展，每年按期付息，但基本不还本金；等公司快速发展到了一定阶段，基本进入成熟期后，市场大局已定，再主动降低负债风险和经营成本。
+
+创业公司从小到大的发展过程中，业务在高速增长，系统服务的实现即使没那么优化，但只要能通过加机器扩展，就暂时没必要去归还实现层面的负债。无非是早期多浪费点机器资源，等业务到了一定规模、进入平稳期后，再一次性清偿掉这笔实现负债，降低运营成本。
+
+这就是技术上的战略债务，**业务高速发展期保持付息，稳定期后一次性归还**。
+
+战术债务，因为利息很高，所以一般都是**快借快还**。而疏忽债务，需要坚持**成长性归还策略**，一旦发现过去的自己写下了愚蠢的代码，就需要主动积极地确认并及时优化，清偿这笔代码实现债务。
+
+其次，还债时，我们主要考虑债务的大小和还债的时机，在不同的时间还债，也许研发成本相差不大，但机会成本相差很大，这一点前面分析战略债务时已有提及。而按不同债务的大小，又可以分为大债务和小债务。一般，我把需要以周或月为单位计算的债务算作大债务，而只需一个程序员两三天时间内归还的债务算作小债务，所以这不是一个精确的定义。
+
+小债务的归还，基本都属于日常的重构活动，局限在局部区域，如：模块、子服务的实现层面。而大债务的归还，比如：架构升级，就需要仔细地考虑和分析机会成本与潜在收益，所以大债务归还要分三步走：
+
+1. 规划：代表愿景，分析哪些债务需要在什么时间还，机会成本的损失与预期收益是多少。
+1. 计划：代表路径，细致的债务分期偿还迭代计划。
+1. 跟踪：代表过程，真正上路了，确认债务的偿还质量与到位情况。
+
+如今微服务架构的流行，基本把小债务锁定在了一个或几个微服务体内。即使债务累积导致一两个微服务技术破产，这时的还债方式无非就是完全重写一个，在微服务拆分合理的情况下，一个服务的重写成本是完全可预期和可控的。
+
+除了技术债务的管理与清偿，我们还需关注技术债务与作为程序员的我们之间的信用关系，因为毕竟债务也是我们生产出来的。
+
+## 信用
+
+生产并拥有技术债务的程序员，并不代表其信用就差。
+
+现实生活中，债务依附于借债的主体方，比如金融债务依附于个体或组织，但如果个体死亡或组织破产了，债务就失去了依附体，自然也就消失了。而技术债务的依附体，并不是程序员，而是程序构造的产品或系统，所以当产品或系统的生命周期结束时，相应的技术债务也会消失。
+
+因而，此种情况下，程序员是有充足的理由不还技术债的，这是技术决策的一种，并不会降低程序员的信用。
+
+任何一个程序系统或其一部分都会与某一个程序员建立关联，如果这个程序员此时就负责这部分系统，那么他在此基础上继续创造代码时，既增加了资产也可能引入了新的债务。这时他的一个重要职责就是，维持好资产与债务的平衡关系。如果在此期间，系统的债务失衡导致技术破产，需要被迫大规模重构或重写时，那么这个程序员的信用必将受到关联伤害。
+
+所以，**程序员的信用，更多体现在面对技术债务的态度和能力**——有意识地引入债务，并有计划地归还债务；无意识地引入债务，发现之后，有意识地归还。
+
+再有代码洁癖的人也没法写出无债务的代码，而无债务的系统也不存在。面对负债高的系统，我们不必过于焦虑，高负债的系统往往活力还比较强。作为程序员的我们，应把技术债务当作一门工具，而不是一种负担，那么可能就又获得了新的技能，得到了成长。
+
+总之，面对债务，做一个有信用的程序员；将其当作工具，做一个有魄力的技术决策者。
+
+最后，你也可以聊聊你对技术债务的态度和看法，欢迎留言一起讨论。
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/52 | 选择从众，还是唯一？.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="52 | 选择从众，还是唯一？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1c/3f/1c109edf38c4627403eea44e76a3a53f.mp3"></audio>
+
+想要取得成就，就会面临竞争，几乎所有的成就，都是直接或间接通过与他人的比较来评价的。理解了这样的评价与竞争关系，想要取得成就，出类拔萃，就意味着你要做出选择：**选择从众、随大流，还是选择一条只属于自己的路？**
+
+不同的选择，意味着面临的竞争水平不同，付出的努力自不相等。
+
+## 众争
+
+有时，我们会下意识不自觉地选择从众，随大流；这样的选择往往给人更安全的感觉，但这样的选择也意味着更激烈的竞争。
+
+随大流，属于众争之路，感觉是安全的，看上去也是热闹的，但竞争是激烈的，而且竞争所处的水平并不高，属于中等平均水平。比如：作为一名职业的普通程序员，你的任何一次求职、晋升或加薪，都面临类似水平的竞争，这样的竞争规模局限于一个局部市场，比如公司或部门内，规模不大，但人数不少。
+
+在这样水平的竞争层面，其实最顶尖的那部分程序员已被排除在外了，因为这类人在市场上其实供不应求，而且没有大规模的生产方法。处在这样的众争之地，如果你永远都在看周围的人在做什么，和他们保持类似，那么你就很可能处在这群人中的一个平均水平区间。
+
+其实，在这样的竞争水平下，你只需要稍微付出一些努力，就能超越平均水平；即使想要脱颖而出，也只需要持续地多付出一些努力。有一句流行的话是这么说的：“以大多数人的努力程度之低，根本轮不到拼天赋”，这就是众争层面竞争关系的本质。
+
+先努力拉开差距，再去找到少有人走的适合自己的路。
+
+## 稀少
+
+2% 的人创造内容，而 98% 的人消费内容；写作，就是这么一件少有人走的路。
+
+写作的竞争，其实就比职场的竞争高了一个层次。因为职场求职、晋升的竞争都是局部区域性质的，而写作不受地域的限制，最厉害和成功的写作者可以直接与你竞争。然而，写作也可以通过专业化和差异化来划分领域，从而缩小你的竞争范围。但即使是这样，你仅仅是成为你所在的小集体组织（如：部门或班级）中写作水平最高的人，也不足以赢得竞争，而是需要成为该领域最优秀的写作者之一。
+
+正因为写作所处竞争维度的残酷性，所以才会只有这么少的人在长期写作。我的写作之路，一开始本是因为有兴趣，偶尔有了感触或灵感就写写，属于灵感事件触发的兴趣写作。但这种没有约束感的兴趣写作导致的结果就是一年下来也没写出多少东西来，灵感这么飘忽的东西，似乎总也不来。后来，觉得需要增加点限制，保底平均每月至少写一篇，就像有人每月要去健一次身、跑一次步一样。
+
+就这样带着个限制，持续写了五年，从灵感触发的兴趣写作，到主动选择的规律写作，也算是写出了点东西。再后来，我把这个约束提高到了每周一篇，虽说这会带来更大的消耗，但我逐渐想清楚了它的意义：这就是一个 2% 的选择，少有人走的路。
+
+持续写作并不是为了写而写，它是为了满足自身。一开始即使写完一篇文章没人读，也是完成了最基本的价值，于我，即是每周一次的思维训练。就像每周健身一次，肯定比每月去一次效果更好。而一个写作者只需要持续去写对自己有意义和价值的东西就好，从一、两篇到一百、两百篇，也许其中某篇就和更多的人产生了共鸣，让写作和文字有了更大的意义。
+
+曾在和菜头的公众号看到有人留言：“菜头叔，我可以写，但是没人看，就非常难受……都大半年了，看的人还是二十几个……心累啊！”和菜头的回复是：“我写了十年的时候，也只有 400 人看，半年时间很长么？”
+
+当你写完一篇文字，把它推向这个世界的文字海洋，然后扑咚一声，便安静了下去，没有掀起一朵浪花。没必要纠结于此，继续写，继续改进，直到终于能掀起一丝涟漪，那么浪花也就不远了。
+
+当然，也并非一定要选择写作，本杰明·富兰克林是这么说的：
+
+> 
+要么写点值得读的东西，要么做点值得写的事情。
+
+
+写作本身就是一个关于选择的活动，而值得写的东西，本来也是稀少的。选择少有人走的路，通常也意味着你要大量地尝试，考虑自己的长处加上刻意的练习，虽不能保证成功，但却在创造可能性。
+
+## 稀缺
+
+稀少的事情，你可以有计划地去持续做；但真正稀缺的东西，比如：机会，却不会随时有。
+
+在前面 “计划” 系列的文章中，分享了我会采用计划清单来安排时间，每天其实早就做好了计划。计划得满满当当的，一件接一件地划去待办事项列表（TO-DO List）上的条目，成就感满满的。但执行了一段时间后就发现了问题，虽然有计划，但总是有变化，计划得太满，变化来了就总会让计划落空；计划得不到执行，就会产生懊恼与愧疚感。
+
+一开始我以为是计划得太满，缺乏弹性，所以无法应对变化。如果在计划里留出弹性空间，那么这些空间就是空白的，但如果一天下来没有太多变化发生，那这些留出的空白空间我又该做什么呢？这么一想，我突然就明白了，原来所有的日常计划都应该是备用的 B 计划（ Plan B），而真正的 A 计划（Plan A）就是变化，那种让你产生 “哇～噢～” 的惊叹感觉的变化。
+
+我们大多数人，对太多的东西做出了过度承诺。这些东西通常就是一些日常计划，都是些小而平庸的事情，它们填满了我们的生活。但问题是，偶尔遭遇到“哇～噢～，我的天！”这样的变化，一些事情发生了，却没有给予足够的时间和精力去注意它们，因为满脑子都在想着那些还没完成的日常计划。
+
+当一件事情来到你面前，决定是否需要去做时，如果你觉得不能让你产生 “哇～噢～” 的感觉，那么就可以坚决地说 “不”。这为你的生活留下了空间，然后当真正稀缺的 “哇～噢～” 时刻来临时，才可能有机会注意到并全身心地投入进去。“哇～噢～” 的稀缺时刻不会经常出现，所以才需要备用计划，既然是备用的，也是可以随时抛弃的。
+
+平时，计划做一些少有人做的事，然后等待稀缺的 “哇～噢～” 时刻与机会出现，这样的时刻或机会是没法规划或计划出来的，否则它就不是稀缺的。而能否让你碰到 “哇～噢～” 的稀缺选择机会，这好像有点运气。如果没碰到也就算了，但如果碰到了当时却没注意到，好几年后回过头来才发觉，那留下的将是 “哦～哎…”了。
+
+## 独一
+
+独一无二的路，要么是没有竞争的，要么是别人没法竞争的。
+
+瓦叔就曾走过独一无二的路，那瓦叔是谁？你多半熟悉，就是阿诺德·施瓦辛格，跟他有关的标签有：健美先生、终结者、美国加州州长。看过他的一个采访后，才明白：这看起来傻傻的大块头真有大智慧。
+
+他在自己发展的路上，问了自己一个问题：
+
+> 
+How can I carve myself out a niche that only I have?
+
+
+这句话怎么理解？Niche 这个词的原意是 “壁龛”，如果你参观过像千佛洞这样的地方，应该对山壁上放佛像的凹洞有印象，那就是 “壁龛”。而 Carve out 的原意是“雕刻”，所以比较形象的理解就是：如何在崖壁上雕刻出一个凹洞，把我这尊佛放进去。后来 Niche 引申为“职业生涯中合适的位置”，所以这句话就可以理解为：我如何为自己谋得一个独一无二的位置？
+
+这是他从健美先生转型进军好莱坞时问自己的问题。所以，在好莱坞他从不去试镜：“我才不会去尝试走这些常规路径，因为你知道我看起来长得就不像是一个常规的家伙。”因此，他没有急着去试镜一个角色，然后赚租金养家糊口。
+
+作为之前的全美乃至全球健美先生，已有一定的经济基础去支撑他等待一个合适的稀缺选择机会，然后他等到了一个独一无二的角色：终结者。导演詹姆斯·卡梅隆说：“要是没有施瓦辛格，我可能不会拍《终结者》这部电影，因为只有他像个机器人。”
+
+独一，可遇不可求；遇，也先得有遇的基础，它包括：**异常的努力，不错的运气，非凡的能力，也许还有特别的天赋**。
+
+可惜，我们很多时候都选择了随大流。
+
+最后，总结提炼下今天的内容：
+
+- **走众争之路，拼的是努力，只能成为平均的普通人**；
+- **走少有人走的路，拼的是选择、勇气和毅力，可以让你遇见独特的风景，为稀缺的机会创造可能性**；
+- **走独一无二的路，真的是要拼天赋了**。
+
+那么，现在你正走在哪条路上？
+
+

极客时间专栏/程序员进阶攻略/徘徊：道中彷徨/53 | 选择工作，还是生活？.md

@@ -0,0 +1,92 @@
+<audio id="audio" title="53 | 选择工作，还是生活？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/82/e4/82854f2126a29906e56305757fe082e4.mp3"></audio>
+
+从大学到职场，会经历一次失衡。
+
+在学校的时候，虽有时间课程表，但大部分时间还是属于我们自己自由安排的。毕业后，一进入职场，就会发现工作开始占据了主导，而后随着工作日久，越发陷入一种关于工作与生活平衡的选择困惑。
+
+## 处境
+
+工作与生活的平衡，到底是怎样一种状态？
+
+曾经我以为的平衡是这样的，我想很多人也这样以为过，工作与生活是完全隔离的。
+
+工作逼迫我们在寒冷的冬天早晨从热乎乎的被窝里不情愿地钻出，去日复一日地完成一些枯燥、乏味甚至令人心生畏惧的事情，但却又不得不安慰自己，工作让我们所做的这一切都是为了生活啊，再忍忍吧。
+
+而下班之后才是我们真正热切期待的生活，迫不及待地去玩热爱的游戏（对，那时我还热爱玩魔兽），周末就和朋友去游山玩水，感觉这才是生活。但似乎永远缺乏足够的时间去过这样的生活，假期总是太短，而工作的时间却总是在不断地变长。工作的第一年，我发现越来越少有时间玩游戏，总是在加班，总是坐最后一班公交车回到租住的小屋，冲个凉后，再一看时间，已经过了凌晨。
+
+而工作之后的第二、三、四年，长期地出差，似乎连周末都剥夺了，感觉总是在工作。我期待的平衡，完全地失衡了。不仅是我感觉如此，也有好些同事因此选择离开了广州，回到二、三线城市的家乡，比如：西安、长沙。那时我也在想，“我是不是也可以回成都，听说成都是一个休闲的城市呢，回去后，工作与生活是不是就会更平衡些呢？”
+
+是的，后来我就这么回来了，但却没有找到期待的平衡，工作反而变得丧失了充实与成就感，生活也变得更焦虑了。如今回首想来，当时我并没有认清和想明白自己的处境与状态，并去定义好属于那个阶段的平衡点。
+
+每个阶段会有每个阶段的生活目标。刚毕业时，对我来说合适的目标应该是：自力更生，好好生存下来并获得成长。再之后几年，生活目标会进化到：恋爱成家。再往后，目标也随之发展为：事业有成，家庭幸福。而我当时的症结在于，错把平衡当作了目标，而实际平衡更多是一种感受。有句话是这么说的：
+
+> 
+人若没有目标，就只好盯着感受，没有平衡，只有妥协。
+
+
+认清自己当前阶段的目标，定义清楚这个阶段的平衡点。一个阶段内，就不用太在意每一天生活与工作的平衡关系，应放到整个阶段中一个更长的周期来看，达到阶段的平衡即可。**通过短期的逃避带来的平衡，只会让你在更长期的范围内失衡**。
+
+作为个人，你需要承担起定义并掌握自己生活轨迹的重任，如果你不去规划和定义自己的生活，那么别人就会为你规划，而别人对平衡的处理你往往并不认同。
+
+结合当下的处境与状态，没有静态的平衡，只有动态的调整。
+
+## 关系
+
+工作与生活的关系，短期的每一天总在此消彼长地波动，但长期，应该是可以动态平衡的；当从长期的视角来看待工作与生活时，会发现二者之间并没有那么明显的分界线。
+
+长期的视角决定了，无论工作还是生活追求的都不应该是最后的目标或目的 —— 一种終点状态。你必须得关注过程，这个过程才是你的生活。所以，生活包括了工作，有时候甚至是非常艰辛的工作，就像我刚开始工作的那几年。那时，工作填满了我绝大部分生活，让我错觉工作剥夺了我的生活。
+
+只是因为当时我并没有想清楚自己到底想要一种什么样的生活，什么对我是重要的？我只是感觉从学校毕业进入工作，然后工作就逼迫着我放弃了曾经热爱的游戏。工作似乎在剥夺着我曾经生活中的很多东西，于是工作与生活就这样对立起来了。
+
+然而工作不该是受罪，我们应当从中找到乐趣，王小波是这么说的：
+
+> 
+人从工作中可以得到乐趣，这是一种巨大的好处，相比之下，从金钱、权利、生育子女方面可以得到的快乐，总要受到制约。人在工作时，不单要用到手、腿和腰，还要用脑子和自己的心胸。我总觉得国人对这后一方面不够重视，这样就会把工作看成是受罪，失掉了快乐最主要的源泉，对生活的态度也会因之变得灰暗…
+
+
+当想清楚了这点后，工作就不过是生活的一部分，何必需要去平衡。与其去平衡两者，不如从整体长期的角度去选择一种平衡的生活。一段时间，也许你的生活中充满了工作；一段时间，你决定减少一些工作，去交交朋友，谈个恋爱。再一段时间后，有了孩子，你决定把曾经生活里的一部分，比如玩游戏，换成陪孩子玩游戏。也许你没法每一天都能做到这样自如地选择，但从一个长期的角度（五到十年）你总是可以选择的。
+
+紧要的是，**去过你想要的生活，而非不得不过的生活**。
+
+而这里所指的“工作”已不再仅仅是“上班、打工”这样的狭义含义，而是更广义上的“工作”。比如，现在我正在写这篇文字，写到这里，时间已过了凌晨，窗外有点淅沥声，下起了小雨。我喜欢成都夜晚的小雨，突然想起了杜甫《春夜喜雨》中的某几句：
+
+> 
+随风潜入夜，润物细无声。
+
+
+> 
+晓看红湿处，花重锦官城。
+
+
+写作，于我就是另一种广义上的 “工作”。而且我喜欢上了这样凌晨夜里的写作，有一点点的辛苦，也有一点点的美好，是吧？这也是当下我选择的生活。
+
+## 比例
+
+既然要主动选择，从一定的长周期看，就需要确定到底怎么样的比例合适。
+
+选择工作在生活中的比例问题，是一个关于优先级和价值观的问题。从操作上来说，它其实是一个交易问题，关乎自己的所得和所失的交易。选择二者间的交换比例，意味着我们要进行权衡取舍，并为之承担相应的结果。
+
+工作与生活的平衡比例选择，既然从操作上是交易问题，那么我们也就可以借用一下投资交易中的一种颇有启发的策略：年轻时，要更多投资于风险更高、波动更大、但潜在收益也更大的股权类权益；随着年纪见长，就要慢慢增大更稳定和确定的债券类投资比例，降低股权比例。
+
+而且，这个策略还有非常具体的量化指标。就是用 100 或 120 减去你的年龄来得到你应该投资股权的比例。至于到底是用 100 还是 120，取决于你心理的风险承受能力和偏好。
+
+把这个思路用在平衡工作与生活上的话，大概是这样，假如对于一个非常有事业心和野望的人（可以理解为风险偏好大的人），大学毕业平均是 22 岁，那么就应该是 120 - 22 = 98，也就是 98% 的精力花在工作上，当然这里是广义上的 “工作”。而对于那些刚毕业但没有那么大野心的年轻人，也应该投入大约 80%（这是用 100 来减） 的精力在 “工作” 上。
+
+对于这个策略，我的理解是**早期的高投入，是为了将来需要更多平衡时，能获得这种平衡的能力**。在我有限的见识和理解能力之内，我是认同这个比例的。一开始就想获得安稳与平衡，人过中年之后是否还能获得这样的安稳与平衡，感觉就比较靠运气。掌控自己能把握的，剩下的再交给时代和运气。
+
+**人生，就是在风险中沉浮，平衡的交易策略就是用来应对风险与波动的**。
+
+工作是我们度过很长一段生命的方式，还有句话是这么说的：“我不喜欢工作，但我喜欢存在于工作里的东西 —— 发现自己的机会”，工作才会让我们找到属于自己的真正生活。
+
+而我们应该追求过好这一生，而非追求平衡，如何才算 “好”，每个人都会有自己的答案。我的答案是：**不是通过努力工作来过上想要的生活，而是先设定了想要的生活，自然而然工作就会成为生活中合适的一部分**。
+
+末了，我总结下今天的内容：
+
+- **缺乏真正的目标时，就只好盯着感受，把平衡当作了目标，由此带来了平衡选择的困扰**；
+- **不同的处境与状态，会有不同的平衡点，需要做出规划与选择**；
+- **短期只有此消彼长，长期才能动态平衡**；
+- **早期年轻时的高投入，换取将来平衡的能力与选择权**。
+
+那么关于工作与生活的平衡选择，你有怎样的看法呢？
+
+