技术修炼之道：

德雷福斯模型：所有专业人员都需要经历 5 个成长阶段，不管是医生还是律师，或者是软件开发，任何专业技能的从业者都需要经历新手、高级新手、胜任者、精通者、专家 5 个阶段。如下

 

  • 新手：通常一个人进入专业的技能领域，即使在学校已经系统学习过这个专业的相关知识，但依然无法独立完成工作，必须在有经验的同事指导下，学习相关的技能。这里主要学习的是有关工作的规则和套路。比如用什么工具、什么框架，如何开发程序，如何开会、写周报，如何和同事合作，业务领域的名词术语是什么意思等等这些各种各样和工作有关的大小事情
  • 高级新手：是新手的自然延续，他不需要别人指导工作，也不需要学习工作的规则和套路，因为高级新手已经在新手阶段掌握了这些套路，他可以熟练应用这些规则套路完成他的工作。但是高级新手的能力也仅限于此，他不明白这些规则是如何制定出来的，为什么使用这个框架开发而不是另一个框架，也不明白这个框架是如何开发出来的。一旦需要解决的问题和过往的问题有很大不同，以前的规则套路无法解决这些新问题的时候，高级新手就抓瞎了，不知道该怎么办
  • 胜任者：少部分新手和高级新手会在工作中学习、领悟规则背后的原理，当需要解决的问题变化，或者行业出现技术革新时，能够尝试学习新技术，解决新问题。胜任者工作的一个显著特点是，做事具有主动性。他们在遇到新问题时，会积极寻求新的解决方案去解决问题，而不是像高级新手那样，要么束手无策，要么还是用老办法解决新问题，使问题更加恶化。胜任者能够解决新问题，但他们通常只会见招拆招，局限于解决问题本身，而缺乏反思精神以及全局思维
  • 精通者：拥有反思精神和全局思维，即使没有新问题也能够进行自我突破、寻求新的出路的人，通过主动学习进行提升，主动进行大量的阅读和培训，而不是仅仅依靠工作中的经验和实践。他们在完成一个工作后会反思：哪些地方可以改进，下次怎么做会更好。拥有自我改进能力
  • 专家：把过往的经验都融汇贯通，然后形成一种直觉，他们直觉地知道事情应该怎么做，然后用最直接、最简单的方法把问题解决。专家通常也是他所在领域的权威，精通者和胜任者会学习、研究专家是如何解决问题的，然后把这种解决方案形成套路，成为行业做事的规则

如何在工作中成长

  1. 用于承担责任：如果你只是去遵循别人的指令，按别人的规则去做事情，你永远不会知道事物的真相是什么。只有你对结果负责的时候，在压力之下，你才会看透事物的本质，才会抓住技术的核心和关键，才能够让你去学好技术，用好技术，在团队中承担核心的技术职责和产生自己的技术影响，并巩固自己的技术地位
  2. 在实践中保持技能：不断超越自我，挑战自我的工作。也就是说，每一次在完成一个工作以后，下一次的工作都要比上一次的工作难度再增加一点点，不断地让自己去挑战更高难度的工作，从而拥有更高的技术能力和技术认知。多实战、多思考、多总结
  3. 关注问题场景：善于根据问题场景发现解决方法的那个人，如果你关注场景，根据场景去寻找解决办法，也许你会发现解决问题的办法可能会非常简单，也许并不需要多么高深的工具和方法就能够解决。基于场景寻找解决方案

技术等级

 

 

 二八原则，80% 的工程师处在这个金字塔最底层，全世界绝大多数的代码出自这一层的工程师之手

  • 团队影响者：剩下的 20% 技术人员中的 80%，也就是总数为 16% 的工程师，他们是项目架构师、技术经理、技术骨干，他们撑起了项目的技术核心，在项目范围内决定着各种技术方向，核心的代码由他们开发，出了重要的问题也要找他们去解决。这样的人，在一个 10 人团队中，大约有一两人
  • 公司影响者：大约占总数的 3.2%，他们决定整个公司的技术方向，用 Java 还是用 PHP？用 MySQL 还是 SQLServer？微服务用 Dubbo 还是 Spring Cloud？在一个有 300 名技术人员的公司，这样的人大约有 10 个。他们通常是公司的技术元老，在公司的技术团队中拥有较大知名度的技术牛人
  • 全国影响者：通常来自知名的 IT 互联网公司，传播最新技术动向的人
  • 全球影响者：跨越国界传播技术动向，在这个技术影响力体系里面，越往高，背景越重要。你是谁不重要，你代表谁更重要
  • 关键开创者：开发了一些关键性的技术产品的人，比如一些广为使用的 JSON 解析器、单元测试框架、分布式缓存系统
  • 领域开创者：开创了一个领域，比如 Spring，构建了一个完整的 Java web 开发技术栈
  • 行业开创者：Hadoop 成就了大数据行业，Linux 引领了操作系统行业，Linus、Doug Cutting 这些人就是软件技术领域的王者

构建技术影响力

  1. 承担责任：重大的技术决策可能会带来重大的技术风险，要有勇气承担风险，并因此赢得他人的尊重
  2. 帮助他人：团队成员遇到技术问题的时候，即使不是自己的工作范围，也可以帮助他们去解决问题，一方面建立自己的技术影响力，另一方面，通过解决问题获得更快的技术成长和领悟

 

真正的问题

小故事

北欧有一个度假胜地，是欧洲人民夏天避暑度假的好去处，去度假胜地需要经过一个长长的隧道，隧道的工程师为了保证隧道的安全使用，在隧道入口处立了一块牌子，写着：请打开车灯。游客们开着汽车，打开车灯，穿过隧道，到达度假胜地，愉快地去玩耍了。而等他们要回去的时候，有些人却发现车子无法启动——他们忘记关闭车灯，汽车电池耗尽了。小镇的警察们只好开着自己的警车四处为游客们充电，疲惫不堪。而沮丧的游客们则在回去以后四处抱怨，分享他们糟糕的旅游经验，导致小镇旅游业大受影响，镇长压力山大。于是人们找到隧道的工程师，要求他在隧道的尽头再立一块牌子，写上：请关闭车灯。工程师照做了以后，却发现麻烦来了：夜晚穿过隧道的游客看到牌子，虽然非常疑惑，但还是按照指示关闭了车灯，结果却发生了车祸，麻烦更大了。于是工程师不得不写上：如果是白天，请关闭车灯。结果有的游客没看到隧道入口的牌子，却看到了隧道出口的牌子，同样疑惑。为了解决新问题，工程师不得不在牌子上继续写下去⋯⋯

这个场景和软件工程师们日常的工作场景是不是很相似？总有客户、老板、产品经理过来跟你说，这里需要这样一个按钮，那里需要这样一个功能。你照做了以后，发现带来了更多的麻烦，为此，你不得不在代码里不断地写 if/else。你不是在解决问题，而是在制造问题

  • 不要把方案当做问题的定义，而忽略了真正要解决的问题是什么

  • 不需要解决别人的问题，只需要提醒他问题的存在
  • 鱼是最后一个看到水的，身处问题之中的人往往并不觉得有问题

 

 

如何解决问题

  1. 如果某人能够解决问题，但他自己却感受不到我那题，那么就让他感受一下
  2. 用人的最高境界是用上司
  3. 要批评而不是责难，对事不对人（直言有讳）
  4. 以赞成的方式表示反对，反对一个技术方案的时候，他先是表示赞成，然后从设计、价值几个方面快速说几个比较好的点。接着，将话题转换：“但是，我还有几个小小的疑问和建议
  5. 如果想解决一个大家都不关注的我那题，那么试试让问题变得更糟（亡羊补牢）
  6. 如果不填老师想要的答案，你就是个傻瓜