我看好多人都在讨论这个“二流”的问题，我接触过不少人，自己也琢磨了好久，发现确实有一些思维定势，一直在拖后腿，让人跑不快。
只看眼前，不想未来
我以前有个同事，技术挺不错的，写代码又快又但是他一直就盯着自己手头上那点事。公司让他做什么，他就老老实实地做完，从来不想着这个东西以后能干嘛或者自己能不能改进一下。
有一次我们项目要升级一个老旧的服务，需要引入新的框架。我当时就琢磨着，既然要换，干脆把整个 CI/CD 流程也优化一下，自动化跑起来，以后省事。我把这个想法跟他说，他听完就摆摆手：“太麻烦了，我们先把代码跑起来再说，那个以后再说。”
结果？我们那个服务部署完之后，每次改动都要手动操作好多步骤，测试环境和生产环境部署流程都不统一，出了问题手忙脚乱。他倒是把代码快速写完了，但后续维护和扩展的成本比别人高了好几倍。这就是典型的只顾眼前的任务完成，不去思考这个任务背后更大的价值和未来的效率。
路径依赖，拒绝改变
还有一种情况，是特别依赖自己熟悉的那个“套路”。我认识一个做前端的朋友，他对某个老旧的 JavaScript 框架简直爱得死去活来。新框架出来的时候，他看都不看一眼，觉得“没必要学，我这个用得好好的，能完成所有需求。”
那时候，整个行业都在往组件化、工程化的方向发展，效率和性能提升了一大截。他还在用老方法，维护一个巨型代码块。每次遇到新需求，他都要想办法把新功能硬塞进那个老框架的体系里，搞得代码又臭又长，调试也费劲。
我当时劝他：“试试新的工具，能提升效率。”他回答我的话是：“我这个方法是最稳妥的，我用了很多年了，换了出问题怎么办？”他不是学不会，他是不愿意从零开始去适应一个新的流程和思维方式。固执地守着旧有的成功经验，害怕跳出舒适区。这种路径依赖，让他在技术更新换代快的领域里，很快就变成了被甩在后面的人。
只做执行者，不做设计者
我以前带过一个实习生，小伙子干活非常卖力，给他的任务都能高质量完成。但是，如果我不给他明确的步骤，让他自己去规划一个稍微复杂点的任务，他就抓瞎了。
比如，让他去研究一个第三方库，我的期望是他能不仅看懂怎么用，还能理解这个库的设计思路，为什么这么实现，有没有潜在的风险。但他交上来的报告永远是：如何安装，如何调用 API，仅此而已。
我问他：“如果这个库以后停止维护了，我们该怎么办？”他愣住了。他从来没有想过“为什么”和“如果”。他的思维停留在“我被告知要做什么”，而不是“我们为什么要做这个，以及最好的做法是什么”。
真正厉害的人，拿到一个需求，是拆解、质疑、重构，然后再去执行。他们会问：
- 这个需求是不是伪需求？
- 有没有更简单、更健壮的实现方式？
- 这个方案未来扩展性怎么样？
如果一个人永远只是个优秀的执行者，只会按照既定的路线图走，那么他的上限很快就会被摸到。只有开始思考设计、权衡利弊、规划路线，才能从“二流”往上爬。
封闭自我，不接受反馈
一点，也是我见过最致命的一点，就是听不进去别人的话。有些人能力一般，脾气倒是大得很。你给他提意见，他不是思考你的建议是否有价值，而是直接进入防卫模式。
我记得有一次代码评审，我指出一个同事的代码逻辑耦合太严重，未来会很难维护。我花了好长时间解释，给他画了图。他当时嘴上说“，知道了”，但实际上，第二天他还是把代码提交上去了，一点没改。
后来我单独找他聊，他很生气地说：“我觉得我这个没问题，你就是太吹毛求疵了。”他把所有的批评都看作是对他个人的否定，而不是对工作的改进建议。封闭的思维，让他停止了从外部吸收养分、修正自己的机会。
你看，这些限制人的思维方式，总结起来就是：缺乏长期主义的眼光、害怕走出熟悉的道路、不愿意从执行者升级为设计者、以及拒绝外部世界的修正。只要这些思维定势不打破，光靠努力和时间堆砌，是很难突破到更高的层次的。
还没有评论，来说两句吧...