职业生涯这些年，我曾犯过的三个认知错误

在我的记忆里，从我刚懂事的时候起，父母就时常在我的耳边唠叨，总是些人生哲理、 处世方法之类的大道理，有时甚至还会逼我去做一些事让我厌恶的事情，不明事理的我总是敷衍了事。当时的我认为父母多此一举，始终觉得他们所描述的场景永远都不可能发生在自己身上。

随着时间的推移，这些唠叨犹如细胞分裂，逐渐演化成了我那自以为是的态度，狂妄自大的性格，以及保业守成的洞察力。直到有一天，我在职场中遭受了沉重打击，回到家中得我在妈妈的面前流下了混浊的泪水，到这一刻我才明白，他们当年所描述的场景原来离真实世界是这样的接近。

图 1. 通常我们认为的职业成长线路

图 2. 我的职业成长之路跌宕起伏

记得《精进》里有一段话，大致是说在这个世界上，有许多短平快、付出马上就有回报的立竿见影的事，也有许多的是需要长期投入、靠矢志不渝的坚持才有大成的事。而对于后者，往往先入为主的认知偏差，会使得我们在判断上产生错误，最终让你的长期投入失去价值，职业成长也会变得跌宕不堪，即使你拥有再高的智商恐怕也难以幸免。

我从业 18 年，从 2000 年至今一共 18 年，整个过程并不是一帆风顺，甚至还有一些波折，而引起这些波折的原因却是我的那些认知错误。今天我想跟大家聊一聊，我曾犯过的几个认知错误。

演讲只是一项装逼的技能

2017 年，在北京 QCon 收获明星讲师后，有不少朋友问我，“王老师，您的演讲很有特点，不仅激情昂扬，而且充满情怀，不过有一点觉得奇怪，您从业 17 年，怎么从来没见你在历届 QCon 有过分享？这是你的 QCon 首秀吗？”

是的，这不仅是我的 QCon 首秀，而且还是我以公开方式进行演讲的首秀。

在此之前，在我的认知世界里，一名优秀的程序员只需要具备对需求快速理解的能力、服务复用性的能力、系统规划与抽象的能力、良好的文档习惯，外加写出一手既漂亮，又具有艺术气息的代码，谁只要能做到以上几点，那这哥们就可以上天了。什么？演讲与分享的能力？只有不懂技术的才去装逼呢，你让那些站在台上的哥们来解决下我们的 BUG 试试，他能行吗？

我不否认演讲是一种能力，但它没啥用，充其量只能算一项装逼的技能罢了。

这当然是一个很荒谬的论断，因为一场演讲，尤其对于技术演讲来说，它是一种综合能力的体现，如果光能说会道，夸夸其谈，而内容上缺乏实战的总结与经验，架构上又缺乏广度、深度与高度，其结果必定会落一个满嘴跑火车，吹牛吹上天的臭名，搞不好还有被封杀的可能。反之，一场精彩的技术演讲，不仅能让你收获众多粉丝，扩大交际圈，提升公司与个人的知名度，还能试图通过把自己的快乐与经验分享给他人的方式，换取对情感和归属的需要。

当了解到这些之后，我的认知发生了变化，趁着年轻，抓紧时间，所以我做出了改变。

先从学会总结开始，毕竟干咱们这行是很容易被淘汰，很容易落伍的职业，比如某某新技术这两年很红火，具有领先性，学会了就能安身立命，但没落起来也很快。因此，除了给自己设定学习目标之外，养成良好的总结习惯也是极其重要的，比如每次完成一个项目，完成一段代码，都应当有目的的跟踪该程序的应用状况和用户反馈，随时总结，找到自己的不足，虚心向他人请教，这样做，不仅能给将来的演讲累计素材，也能起到抵制自己的拖延症，逼迫自己成长的目的。

再从积极响应学起，只要有主办方邀请你去参加技术大会，无论心态再乏，身体再累，也不论是在哪个省，哪个市，认真对待，不仅要经过公司内部试讲，还要虚心请教身边有经验的大佬们，抱着 “演讲虐我千百遍，我待演讲如初恋” 的心态迎接每一场演讲。

所以我觉得，想要实现一个目标，就要付之于行动，要么平淡一生，要么发奋图强，在两者之间做出选择。

不会写代码，你还有脸叫资深工程师？

2004 年，在东方购物的时候，团队里有一名资深工程师，不仅行业经验丰富，而且还时常跟我们说一些技术圈的八卦新闻。当时的我，脑海中充满着 java 与 C++的各种关键词，感觉他的一切都是那样的新奇，口中的新名词更是让我感到新鲜，与他的每一次交流都能让我回味许久。

两个月后，随着第一代电商系统的顺利上线，整个团队进入了难得的休整期，开始陆续对之前的代码进行调整。

我的任务是对订单系统中的数据类方法进行注释加固，也许是为了表现，原本三天的工作量，我通过通宵的方式，硬是在第二天上班之前完成了，而那名资深工程师，不仅没被分配任何任务，而且还神龙见首不见尾，几乎每天都见不到人影。

某天上午，我早早地来到公司，看他已在座位上，便问他。

我：“你每天不在公司，跑哪去了？”

他：“去供应商哪谈第二代系统的系统集成方案去了呀”

我：“第二代系统集成方案？第二代系统不还在规划吗？”

他：“对呀，就是因为在规划，所以才去谈系统集成方案呀。这中间牵涉许多成本与报价的事，挺麻烦的。”

我：“没明白，系统集成？服务器不早就买好了吗？还集成啥？”

他：“我跟你说不明白，你好好地写你的代码就行了。”

我：“那你怎么不写代码？你会写代码吗？你不是资深工程师吗？”

他：“我不会写代码，我的职责是系统集成与运维的范畴，在这块，我的段位应该算资深吧。”

“你就吹吧你，不会写代码，你还有脸叫资深工程师？”

这次交流，实在可以用不欢而散来形容，还差一点吵起来。

不过这也不奇怪，当时的我没经历过团队协同工作模式，对专业技术分岗完全无法理解，在我的认知世界里，搞技术的都应该能写出一手既漂亮，又具有艺术气息的代码，连代码都不会写算哪门子工程师？不是走后门进来的，就是个十足的骗子。

这其实是一种认知偏差，因为术业有专攻是正常的事情，就像有些数据库大神，对编程语言不一定精通，但却对某个商业数据库特别精通，别人解决不了的难题，只要到他手上立马药到病除。这样的人，别说号称什么资深工程师，就算称其为一代宗师也不算过分。

管理不就是指挥员工做事吗？

在我职业生涯的程序员阶段，无论在哪家公司，我总对自己的老大有着相同的鄙夷：

就知道指手画脚，你懂什么？满嘴的仁义道德，满肚子的大道理，你懂技术吗？管理谁不会？不就是指挥员工做事吗？咱们俩换换，我肯定比你强！

因为心中存有这样的认知，所以在工作中总会对上司提出的各项目标进行挑战，长此以往，不仅遭人恨，而且还会被人贴上低情商的标签。可我自己并不这么认为，总觉得怀才不遇，是他们不识人才罢了，只有不断的跳槽，也许才会偶遇明君。

也许是机缘巧合，我在职业生涯的中前期就管上了团队，可结果却差强人意。

比如，为了充分了解下属的工作内容，我曾要求部门小伙伴在写的每封电子邮件中都要抄送给自己，然后每周定期开会对他们邮件中的沟通风格屡加批评，还要求他们按照我的方式加以改进。几个月后，好几位小伙伴受不了压迫，向我的上级投诉，而且实际证明在这种被监控下的员工在实际工作中表现更差了。

再比如，我从不组织技术架构的讨论，也不提供职业规划与发展的建议。为什么呢？因为我觉得我是老大，需要跟你们讨论啥？给你设计好，你照做就行，如果不会，就干掉你，招个会的。至于职业发展的那些事，你自己不去想明白，还要我替你想？我是你爸吗？

还比如，动不动就指天画地的给下属画饼，问题是平时从不为他们考虑，就把人家当工具使唤，在 90 后当道的今天，人家会吃你这套吗？

直到那一天，我在管理中遭受了沉重打击，我才意识到这种认知是错误的，于是我开始反思自己，如何才能成为一名优秀的技术管理者呢？

简单说，应发自内心的去尊重你团队中的每一名成员，努力的去发现他们身上的优点，帮助他们找到最适合自己的职业发展道路，创造机会让他感受到自身的价值，管理的职责绝不是指挥员工做事，而是对整体的战略目标执行结果负责，控制整体，让每个人各司其职，在自己的位置上发挥出最大的效益。

说到这，想起对音乐指挥家的一则评价：

一场精彩的音乐会，只有指挥才有一份总谱，整个乐曲大到结构和声、小到每一个细节的强弱音色，全部牢牢地印在他的脑子里。而乐手们人手一本乐谱，但每个人的乐谱都是不一样的，只有自己乐器的分谱，相互合作，才能演奏出动人的旋律。