技术人的思维修炼
[toc]
德雷福斯模型
德雷福斯是一个专业人员能力成长模型，这个模型认为所有专业人员都需要经历 5 个成长阶段，不管是医生还是律师，或者是软件开发，任何专业技能的从业者都需要经历新手、高级新手、胜任者、精通者、专家 5 个阶段。
通常一个人进入专业的技能领域，即使在学校已经系统学习过这个专业的相关知识，但依然无法独立完成工作，必须在有经验的同事指导下，学习相关的技能。这里主要学习的是有关工作的规则和套路。比如用什么工具、什么框架，如何开发程序，如何开会、写周报，如何和同事合作，业务领域的名词术语是什么意思等等这些各种各样和工作有关的大小事情。这个阶段叫做新手阶段。
通常说来，一个人大约工作两三年后，就差不多掌握了工作的各种套路，可以摆脱新手阶段，独立完成一些基本的工作了。通过新手阶段的人，少部分会直接进入胜任者阶段，而大多数则进入高级新手阶段。
高级新手其实是新手的自然延续，他不需要别人指导工作，也不需要学习工作的规则和套路，因为高级新手已经在新手阶段掌握了这些套路，他可以熟练应用这些规则套路完成他的工作。但是高级新手的能力也仅限于此，他不明白这些规则是如何制定出来的，为什么使用这个框架开发而不是另一个框架，也不明白这个框架是如何开发出来的。
一个悲观的事实是，新手会自然进入高级新手阶段，而高级新手却无法自然进入其后的其他等级阶段。实际上，在各个专业领域中，超过半数的人终其一生都停留在高级新手阶段，也就是说，大多数人一生的工作就是基于其专业领域的规则在进行重复性的劳动。他们不了解这些规则背后的原理，也无法在面对新的问题时，开创出新的方法和规则。那些简历上十多年如一日使用相同的技术方案、开发类似软件项目的资深工程师大部分都是高级新手。
导致一个人终身停留在高级新手阶段的原因有很多，其中一个重要的原因是：高级新手不知道自己是高级新手。高级新手觉得自己在这个专业领域混得很不错，做事熟练，经验丰富。
事实上，这种熟练只是对既有规则的熟练，如果岁月静好，一切都循规蹈矩，也没什么问题。而一旦行业出现技术变革或者工作出现新情况，高级新手就会遇到巨大的工作困难。事实上，各行各业都存在大量的高级新手，只是软件开发领域的技术变革更加频繁，问题变化也更加快速，使高级新手问题更加突出。
少部分新手和高级新手会在工作中学习、领悟规则背后的原理，当需要解决的问题变化，或者行业出现技术革新时，能够尝试学习新技术，解决新问题，这样的人就进入胜任者阶段。胜任者工作的一个显著特点是，做事具有主动性。他们在遇到新问题时，会积极寻求新的解决方案去解决问题，而不是像高级新手那样，要么束手无策，要么还是用老办法解决新问题，使问题更加恶化。
胜任者能够解决新问题，但他们通常只会见招拆招，局限于解决问题本身，而缺乏反思精神以及全局思维：为什么会出现这样的问题？如何避免类似问题再发生？这个问题在更宏大的背景下处于什么位置？还有哪些类似的问题？
而拥有反思精神和全局思维，即使没有新问题也能够进行自我突破、寻求新的出路的人，就进入了精通者阶段。精通者需要通过主动学习进行提升，主动进行大量的阅读和培训，而不是仅仅依靠工作中的经验和实践。他们在完成一个工作后会反思：哪些地方可以改进，下次怎么做会更好？
精通者拥有了自我改进的能力。
高级新手会把规则当做普适性的真理而使用，甚至引以为豪；而精通者则会明白所有的规则都只在特定的场景中才会有效，工作中最重要的不是规则，而是对场景的理解。
最终，各行各业大约只有 1% 的人会进入专家阶段，专家把过往的经验都融汇贯通，然后形成一种直觉，他们直觉地知道事情应该怎么做，然后用最直接、最简单的方法把问题解决。专家通常也是他所在领域的权威，精通者和胜任者会学习、研究专家是如何解决问题的，然后把这种解决方案形成套路，成为行业做事的规则。
如何在工作中成长
1. 勇于承担责任
好的技术都是经过现实锤炼的，能够真正解决现实问题的，得到大多数人拥护的。所以自己去学习各种各样的新技术固然重要，但是更重要的是要将这些技术应用到实践中，去领悟技术背后的原理和思想。
而所有真正的领悟都是痛的领悟，只有你对自己工作的结果承担责任和后果，在出现问题或者可能出现问题的时候，倒逼自己思考技术的关键点，技术的缺陷与优势，才能真正地理解这项技术。
如果你只是去遵循别人的指令，按别人的规则去做事情，你永远不会知道事物的真相是什么。只有你对结果负责的时候，在压力之下，你才会看透事物的本质，才会抓住技术的核心和关键，才能够让你去学好技术，用好技术，在团队中承担核心的技术职责和产生自己的技术影响，并巩固自己的技术地位。
2. 在实践中保持技能
有个说法叫做1 万小时定律，是说要想成为某个领域的专家，必须经过 1 万小时高强度的训练才可以，对软件开发这样更强调技术的领域来说，这一点尤其明显。我们必须要经过长时间的编程实践，从持续的编程实践中提升技术认知，才能够理解技术的精髓，感悟到技术的真谛。
但是 1 万小时的编程时间并不是说你重复的编程 1 万小时就能够自动提升成为专家的。真正对你有帮助的是不断超越自我，挑战自我的工作。也就是说，每一次在完成一个工作以后，下一次的工作都要比上一次的工作难度再增加一点点，不断地让自己去挑战更高难度的工作，从而拥有更高的技术能力和技术认知。
通俗说来，就是要摘那些跳起来才能够得着的苹果，不要摘那些伸手就能够得着的苹果。但是如果难度太高，注定要失败的任务，其实对技术提升也没有什么帮助。所以最好是选择那些跳起来能够摘得到的苹果，你要努力再进步一点点，才能够完成。通过这样持续的工作训练和挑战，在实践中持续地获得进步，你就可以不断从新手向专家这个方向前进。
3. 关注问题场景
现实中，很多人觉得，学好某一个技术就大功告成了。但事实上是，即使你熟练掌握了强大的技术，但如果对问题不了解，对上下文缺乏感知，也不会真正地用好技术，也就无法去解决真正的问题。试图用自己擅长的技术去解决所有问题，就好像是拿着锤子去找钉子，敲敲打打大半天，才发现打的根本就不是一个钉子。
所谓的专家其实是善于根据问题场景发现解决方法的那个人，如果你关注场景，根据场景去寻找解决办法，也许你会发现解决问题的办法可能会非常简单，也许并不需要多么高深的工具和方法就能够解决，这时候你才能成为真正的专家。也就是在这个时候你会意识到方法、技术、工具这些都不是最复杂的，而真正复杂的是问题的场景，是如何真正地理解问题。
这个世界没有万能的方法，没有一劳永逸的银弹。每一种方法都有适用的场景，每一种技术都有优点和缺点，你必须要理解问题的关键细节、上下文场景，才能够选择出最合适的技术方案，真正地解决问题。
软件技术的生态江湖与等级体系
我们按照每个人的影响力和技能水平，使用二八定律进行划分，得到一个如下的金字塔结构。
80% 的工程师处在这个金字塔最底层，全世界绝大多数的代码出自这一层的工程师之手，但是他们却没有任何技术决策能力和技术影响力。用什么编程语言，用什么数据库，用什么编程框架，日志规范与代码规范如何制定，统统不由他们决定。大多数情况下，一个 10 人团队，有 8 个是这样的人，他们在金字塔的第零层，在这个体系中，他们没有自己的称呼。
这一层之上，剩下的 20% 技术人员中的 80%，也就是总数为 16% 的工程师，他们被称为团队影响者。他们是项目架构师、技术经理、技术骨干，他们撑起了项目的技术核心，在项目范围内决定着各种技术方向，核心的代码由他们开发，出了重要的问题也要找他们去解决。这样的人，在一个 10 人团队中，大约有一两人。
团队影响者之上，是公司影响者，大约占总数的 3.2%，他们决定整个公司的技术方向，用 Java 还是用 PHP？用 MySQL 还是 SQLServer？微服务用 Dubbo 还是 Spring Cloud？在一个有 300 名技术人员的公司，这样的人大约有 10 个。他们通常是公司的技术元老，在公司的技术团队中拥有较大知名度的技术牛人。
团队影响者和公司影响者又如何做出技术判断和决策呢？他们的技术从何而来？通常他们会关注国内最新的技术风向，参加各种技术峰会，阅读各种技术图书，通过这些信息获取知识并做出自己的技术判断和决策。而向他们传播这些最新技术动向的人，是全国影响者。这些人通常来自知名的 IT 互联网公司，当他们说，我们在淘宝、腾讯如何做开发的时候，全中国的开发者都静心倾听。
而这些全国影响者通常是通过关注国外的技术动向来获取信息，主要是一些美国的公司，比如 Google、Facebook、微软这些公司的工程师。当他们讲，我们在 Google 是如何做开发的时候，全世界的开发者静心倾听，想要了解下一次的技术潮流在哪里。他们是全球影响者。
在这个技术影响力体系里面，越往高，背景越重要。你是谁不重要，你代表谁更重要，人们关注的不是你叫什么名字，而是你来自哪个公司，这也是很多人想要加入 Google，阿里巴巴的原因。有趣的是，来自知名大厂的一些工程师常常忘记了这一点，觉得自己得到关注和掌声是来自自己的成就和能力，结果导致对自己的职业发展产生重大误判。
技术等级体系直到这里，关注的都是技术影响力，通过影响力决定使用何种技术进行软件开发。那我们常用的这些软件技术又从何而来？事实上，正是这些知名软件的开发者，推动了一次又一次软件编程的革命，领导了一次又一次技术进步，带领软件技术行业不断前进。
他们有的开发了一些关键性的技术产品，比如一些广为使用的 JSON 解析器、单元测试框架、分布式缓存系统，他们是一些关键开创者。
还有一些则开创了一个领域，比如 Spring，构建了一个完整的 Java web 开发技术栈，这些软件的核心开发者是领域创建者。
而在这个金字塔的最顶层，则是那些开创了一个行业的行业开创者，Hadoop 成就了大数据行业，Linux 引领了操作系统行业，Linus、Doug Cutting 这些人就是软件技术领域的王者。
技术进阶之捷径
直接去做一个全国影响者，在工作之外，通过持续地维护一个技术博客，或者技术公众号，不断地发表一些高质量的原创技术文章，在某个技术领域打造自己的技术影响力。并通过在一些有影响力的技术峰会上做主题演讲，以及出版一些高质量并畅销的技术图书，持续扩大自己的影响力。
应该说，每一次大的技术浪潮，都会使一批默默无闻的技术人员快速获得全国性的技术影响力，在分布式技术、移动互联网、大数据、AI、区块链等领域，莫不如此。
因此，通过这种方式获得全国性的技术影响力，一方面要持续努力，不断学习、实践，持续获得知识，并把这些知识有效地传播出去。另一方面，还要有眼光，你在一个已经非常成熟的技术上耕耘，再努力也很难获得足够的关注；而在那些尚不成熟的技术上努力，你又如何知道将来这个技术会成功？这就需要有足够的技术敏感性，进行足够多的技术尝试，做出有战略眼光的技术决策。
所以，所谓的捷径只是路径上的捷径，要想在这条捷径上获得成功，需要付出更多的努力和聪明才智。
事实上，如果你足够努力并有足够的天分，你甚至可以超越影响者阶层，直接进入开创者阶层，比捷径更加捷径。
比捷径更捷径的路不是没有，只是更加艰难，不只需要你个人的努力，还要看历史的进程。
所以，从根本上说，技术进阶根本没有捷径，所谓的捷径，其实是你经历了各种努力和挫折后，最后化蛹成蝶的惊鸿一瞥。
为了最后众人瞩目的成功，你依然需要经历金字塔每一层的考验。
在工作中，技术实力固然重要，但是技术实力要转化成公司需要的成果和价值，技术影响力非常重要，通过技术影响力引导团队、部门、公司按照你的技术价值观去构建产品架构和技术发展路径，凝聚公司的技术力量，让你自己和公司向着更高的技术等级前进。
关于如何构建自己的技术影响力，有两点建议：
- 承担责任：重大的技术决策可能会带来重大的技术风险，要有勇气承担风险，并因此赢得他人的尊重。
- 帮助他人：团队成员遇到技术问题的时候，即使不是自己的工作范围，也可以帮助他们去解决问题，一方面建立自己的技术影响力，另一方面，通过解决问题获得更快的技术成长和领悟。
当然，技术影响力的前提是真正的技术实力，没有实力的影响力就是空中楼阁，不堪一击。
技术落地之道：你真的知道自己要解决的问题是什么吗？
- 不要把解决方案当作问题的定义，而忽略了真正要解决的问题是什么
- 你不需要去解决别人的问题，你只需要提醒他问题的存在
- 鱼是最后一个看到水的，身处问题之中的人往往并不觉得有问题。身处问题之中的人常常并不能感知到问题的存在，正如身在水中的鱼儿看不到水一样。太多的问题被人们的适应能力忽略掉了，直到有人解决了这些问题，身处其中的人才恍然，原来过去的方式都是有问题的。
关于问题的定义有个公式：问题 = 期望 - 体验。
青青翠竹尽是法身,郁郁黄花无非般若。
技术沟通之道：如何解决问题？
如果某人能够解决问题，而他自己却感受不到问题，那么就让他感受一下
用人的最高境界是用上司。
直言有讳：要批评而不要责难，要对事而不要对人。以赞成的方式表示反对。
如果你想解决一个大家都不关注的问题，那么试试让问题变得更糟
如果你不填老师想要的答案，你就是个傻瓜
技术管理之道：你真的要转管理吗？
彼得定律
彼得在 20 世纪 70 年代，研究了美国数千个组织，包括政府部门、学校、企业等各种类型的组织后，发现，在一个成熟有效的组织中，当一个员工在其岗位能够出色完成工作，就会得到晋升，被提拔到更高一级职位。如果在这个职位，他能够继续出色完成工作，就会继续得到晋升，直到他晋升到某个职位以后，无法出色完成工作为止。
这是职场晋升的一般规则，看起来似乎也没什么，但是彼得在对这些得到晋升的人进行各种观察以后，得到一个结论：在一个层级组织中，每个员工都会趋向于晋升到他所不能胜任的职位。这就是彼得定律，事实上，我们根据晋升的一般规则，也能推导出这个定律。利用这个定律做进一步的推导，还能得到一个彼得定律的推论：一个成熟的组织中，所有的职位都被不能够胜任它的人承担着。这个推论也很好理解，每个人都会晋升到他不能胜任的职位，那么稳定下来以后，所有的职位都被不能胜任的人承担。不得不说这个结论实在是让人有点吃惊，但是却很好地解释了组织中的各种奇怪现象。
彼得进一步对这些不能胜任自己职位的人进行观察，发现当一个人位于他不能胜任的职位上时，他必须投入全部的精力才能有效完成工作，这个职位也被称作这个人的彼得高地。一个处于彼得高地的人，精疲力尽于他手头的工作，就无法再进行更进一步的思考和学习，他的个人能力提升和职业进步都将止步于此。
所以，一个人在其职业生涯中能够晋升的最高职位，能够在专业技能上进化的最高阶段，依赖于他的专业能力和综合素养，依赖于他拥有的持续学习和专业训练的条件与环境。和他晋升的速度无关，有时候也许恰恰相反。
对公司而言，真正有价值的是你为公司解决了多少问题，而不是完成了多少工作，工作本身没有意义，解决问题才有意义。对于你自己而言，真正有价值的不是你获得了多快的晋升，多高的加薪，而是你获得了多少持续高强度训练的机会。而这两者，本质上是统一的。
所以，对自己未来有更多期待，更有进取心的工程师们，应该将精力更多放在发现企业中的各种问题并致力于去解决问题，在这个过程中，你将同步收获职场晋升和个人能力提升。
用目标驱动
在技术管理领域，常见的管理方式有两种，一种是问题驱动型管理，一种是流程驱动型管理。问题驱动型管理着眼于问题，每天关注最新的问题是什么，然后解决问题。流程驱动型管理着眼于流程，关注事情的进展是否符合流程规范，是否在有序的规章制度下行事，看起来像监工。
老实说，这两种都不是高效的管理方法。对于技术管理而言，更高效的管理方式是目标型管理。
目标驱动的管理者关注的是目标，公司的目标是什么？部门的目标是什么？团队的目标是什么？我的目标是什么？我和我的团队做这些事情的价值和意义是什么？不断问自己：我如何做才能为公司，为客户创造价值？
目标驱动的管理者并不特别关注问题，他更关注解决方案。当系统出现故障的时候，他不会关注是谁导致的 bug，他更关注谁可以解决这个 bug。当项目进展缓慢，他并不关注是谁导致了拖延，他更关注我们如何做才能赶上进度。他不问问题为什么出现，因为他知道，所有的问题最后都是人的问题，而纠结于人的问题，只能导致人和人的扯皮。
目标驱动的管理者其实并不是不关注问题，他只是不用问题进行管理，不让团队纠结于问题之中，而是去着眼于未来和解决方案本身。管理者自身其实对问题非常清楚，但是他把问题转化为目标，引导团队前行。
OKR 这个词最近两年在互联网企业很风靡，OKR 就是 Object 目标与 Key Result 关键结果。通过对团队和个人制定有挑战性的目标和可量化的结果标准进行管理。可以说是目标驱动管理的一种落地实践方案。
通常的做法是在一个 OKR 周期开始的时候，每个团队和个人制定自己的OKR：我目标是什么，达成目标后产生的关键结果是什么。所有的 OKR 都需要公开，通过阅读自己合作伙伴和上级部门的 OKR，了解自己的目标在组织中的作用，自己工作的结果对组织的价值，从而了解自己在组织中的位置，使自己的工作成为组织战略的一部分。
在工作过程中，根据目标不断调整自己的工作方式，期间需要定期进行 review：到目前为止，我产出的成果有哪些，距离我们的目标是更近了还是更远了，我们还需要做哪些工作才能达成我们的结果。
需要注意的是，OKR 并不是用来考核的，不应该以目标是否达成作为考核的依据，否则每个人都倾向给自己制定最简单的结果和目标。OKR 是一种管理手段，通过对目标的制定和对结果的审核，将团队和员工的奋斗目标和公司的战略目标统一起来，使每个人都能理解自己工作的目标是什么，在整个公司战略中的地位是什么，使个人更加成为公司整体的一部分。
管理学作为一个学科已经出现了上百年的时间，它有自己的专业工具和方法，有自己的客观规律。仅仅技术做得好并不能保证可以好管理，想转管理的同学应该专门学习一下管理学的基础知识，而不是仅仅看了两篇管理文章，觉得自己技术不错还擅长沟通就转管理了。
工作中的交往和沟通，都有哪些小技巧呢？
保持交际和赞美
很多程序员不喜欢交际，觉得浪费时间。事实上，保持适当的交际，可能会帮你节约很多时间。一方面，良好的交际关系可以营造一种更愉快的工作氛围，自己和其他同事可以保持更好的工作状态；另一方面，处理某些问题的时候，比如，需要指出某个人工作失误的时候，良好的关系可以缓冲这类指责带来的负面影响。相反，如果你们平时见面的时候就形同路人，这个时候，他更有可能认为你是对他个人的否定，而不是对工作本身的意见。
而且，保持适当的交际并不需要花费多少时间，仅仅是简单的寒暄，聊聊天气，就可以拉近两个人的距离。如果寒暄的时候，对方正好有个不错的机会想要找人合作，也许还会给你带来更加巨大的收益。
除了简单的寒暄，赞美是一种更加高效的交际方法。曾经有人在网上调查，有什么技能是可以很快学到而终身受用，出乎意料地，排在最前面的答案不是驾驶、游泳、烹饪这些很硬的技能，而是一项很软的技能：赞美他人。
赞美不是奉承，不是泛泛地说一些：你好棒，你真厉害。赞美是对对方做得好的事情，明确表达你的称赞。称赞的是对方的行为，比如对小孩子说：你摔倒了没有哭，而且自己爬起来，好棒。对同事说：谢谢你昨天晚上加班，我们今天可以按期发布项目。对方通过你的话能感受到真诚，得到正向的激励，而不是敷衍和世故。
就我们目前的环境而言，赞美太少了而不是太多了，尝试多去赞美别人，你会得到意想不到的收获。此外，赞美和批评并不冲突，你可以对一个人既赞美又批评，只要你明确指出赞美和批评的具体事情，对方就可以更加明白你的标准和边界，后面的合作也会更加的顺利。
平衡力量和温暖
职场中什么样的领导最受欢迎，答案是，同时拥有力量和温暖的人。所谓的力量是指能够达成目标的能力，包括技术能力、整合资源的能力、决策力、意志力等各种能力，通过这些能力，能够完成工作目标和任务。人们愿意和有力量的人合作，追随有力量的人，因为这样获得成功的可能性就越大。
而温暖是指拥有让他人产生熟悉感和归属感的能力。表明上看，这种能力是一种共情能力，可以理解他人的喜怒哀乐，进而产生熟悉和归属的感觉。事实上，这是一种构建共同的目标和价值观的能力。
每个人的喜乐并不相同，如果是被动地和其他人共情，是无法深度地整合一个团队的所有人的。而通过构建共同的目标和价值观，让大家产生归属感，进而营造出一种温暖的团队氛围。
如果一个人光有力量而没有温暖，那么和他合作的人可能会嫉妒他，或者对他感到恐惧。而一个人光有温暖没有力量，大家只会觉得他很萌。同时拥有力量和温暖的人，会让他人感到钦佩。而既没有力量有没有温暖的人，大家会蔑视他。
力量和温暖是既一种内在的属性，也可以通过一些外在的行为表现。一个占据更大空间的人会给人力量感，所以不要含胸驼背，把自己缩在一起；另外，主动碰触别人和适当认错也是一种力量的体现。表达对他人的理解以及分享一些相同的经历则会传递温暖的感觉。
学会聆听和提问
在工作沟通的过程中，有时候直接提出自己的观点或者方案，并不能得到其他人的赞同和支持，因为其他人可能并不了解你的问题和场景，没有思考过你的问题，所以对你的观点和方案不置可否，不积极参与。这种情况下，可以通过一些提问的方式，将对方拉到你的思考上下文中，让对方通过自己的思考得出你想要表达的观点和方案，这种情况下再去推动事情的发展就容易多了。
如果你是一个管理者，你团队中某个员工工作不认真，工作效率低，是谁的问题？是公司的问题吗？是你的问题吗？是员工自己的问题吗？如果是员工自己的问题，你该如何提醒他问题的存在，并进而帮助他提高工作效率？
这个问题其实并不简单，员工工作态度不好、工作效率低，可能有企业文化的问题，可能有领导风格的问题（也就是你的问题），可能有项目阶段性挫折的问题。假设这里你的判断是员工自己的问题，因为团队其他人都没有态度问题，那么你该如何帮助他纠正问题？
直接指出问题也许不是一个好主意，因为可能会引发员工的对立情绪：你对我有意见。你不妨可以在和员工交流的时候问一些问题，以提醒他问题的存在：如果你给自己近期的工作成果打分，你会打几分？你觉得其他同事对你近期的工作成果打分，会打几分？如果你自己是用户或者老板，你是否对自己的产出满意？
通常情况下，如果真的是员工自己的问题，那么通过回答这几个问题，他会意识到问题的存在，并想要主动去改变状况。这要比你直接指出他的问题或者批评他效果要更好一些。
如果他已经意识到问题，那么你还可以更进一步提问：你希望我做些什么，可以帮助到你？你下一步有什么打算，可以改进目前的状况，让你自己基本满意？你觉得完成这些改进大概需要多长时间？两周？好，那么我们两周以后再聊一次。
彼得·德鲁克曾经说过，最好的管理学书籍是小说。因为管理就是将每个人的主观能动性发挥出来，为组织创造价值，但是人性是复杂的，任何刻板的管理教条都会遇到人性的阻力，进而演化成组织前进的阻碍。而洞悉人性，善于利用人性的特点，把相关各方的利益统一起来，事情会自然前进。
有些同学纠结将来走管理路线还是技术路线，其实这两者之间的鸿沟并没有想象得那么大，不管是做好技术还是做好管理，都需要有很强的社会实践能力，都需要理解人性，利用人性，特别是理解和利用好自己的人性。