今天不忙，随便聊点。
前几天有人问我，如果想转行IT行业，该学什么技术比较好。我脑海中涌现各种各样的回答，话都到嘴边了突然噎住了。
我突然意识到一件事情：**技术从来不是护城河**。
很奇怪，这句话突然出现在我脑子里，把其他的话全压了下去，反反复复地回荡着。我细细咀嚼这句话，一拍大腿，这他喵的说的真对。
我们总认为高门槛的技术能带来终身的保障，因为高门槛会减少竞争者。这话，对，也不对。
高门槛的技术的确能淘汰掉很大一批的竞争者，但只要学习它有利可图，那么蜂拥而上的人就不会少，而人都挤进这个赛道里了，**门槛再高总会有一批人能达到这个门槛**。
就好比我们都知道清华北大是最好的大学，从这出去后能拿很高的年薪，那么每年数百万考生会拼命往这挤，从而把分数线一年年拉高。
编程行业也是如此，人人都知道做程序员工资高，人人都想来当程序员。每年挤进这个行业的不光是数量庞大的应届生，还有各类转行来的“同事”们，互联网寒冬怎么来的，不就是公司效益不行人又多，只好降本增效了。
当然，掌握吃透一项技术肯定比没吃透要好得多，但想要靠一项技术吃一辈子，很难。
你要不断学习，不断进步，跟着高速更新换代的编程技术走。**当你选择了程序员这条路，就意味着你走上了一个没有终点的学习旅途**。
但当我浏览那些技术论坛时，**有一点很让我在意**：大家交流的更多是技术层面的硬能力。比如一文讲解xx技术，什么问题该如何解决，很少人（并不是没有，少只是相对于讲解那些技术知识的人来说）会注意到软技能的学习。
**软技能是指个人的性格特质、社交能力、沟通技巧和个人习惯等非技术性的能力**。这些技能通常不容易被量化，在生活和工作中似乎也没硬技能出成果快。
可这不代表它并不重要，软技能就好比教育、吃进去的饭或者读过的书，在当下，在学习的此时此刻，你会感觉日子还是一模一样，它没给你带来任何显著的变化。
但当未来的某一刻，就好像是吃过的饭早已融进你的骨与肉，让你成为了你，又好像是某段经历的触动让你共情了读过的书，你突然将学过的软技能应用起来，到那时候，闭环才真正完成。
## **心力匮乏**
Up主【硬核的HeyMatt】提出了一个很有意思的概念：心力匮乏。很多时候我们清楚自己需要学习，需要前进，但做不到。**不是不想上进，也不是缺少天赋，而是大脑根本无法集中在那个频道上**。
这种情况往往跟金钱的短缺或是消耗的无意义时间（比如通勤时间）过长有关。脑流量被琐碎的杂事搅乱得零七碎八，半点风吹草动就足以让心情波动。
每天浑浑噩噩晕头转向，无法抓住任何一个有价值的念头，即使下班和通勤路上有时间，但脑子就像装了水一样处于恍惚阶段，根本没办法做复杂的事情，哪怕只是坐下来读几分钟的书。
心情惆怅，头脑发胀，太多信息流闪来闪去，没有办法有一个良好的心境，也没办法拥有有效的专注力。
“不管你的天赋有多强，不管你有多努力，不管你的心态有多好，不管你有多自信，一旦你陷入金钱、认知和价值观的短缺，那必然会导致心力的匮乏，而人生也很大概率会慢慢枯萎，这不以人的意志为转移。”
**警惕心力匮乏，或者说内耗。**
最好的办法其实是从年轻时起就从认知、价值观和财富三个维度入手来避免陷入“心力匮乏”，但这种构建很困难，那么我在这教大家一个很有用的技巧：**保持愤怒**。
是的，保持住你的愤怒。当你陷入迷茫、绝望的浑浑噩噩中，保持住你的愤怒。强烈的情绪是挣脱无意义的最佳良药。
## **向上管理（managing up）**
向上管理是出现在软技能文章中最多的话题。而在大部分人（包括曾经的我）的下意识印象里，这词往往要跟拍领导马屁或是讨好迎合划上等号。
管理？老板（包括那些你可能需要汇报的对象）不需要管理，他们要的只是员工听从他们的管理。管理是向下的，下属才需要被管理。
向上管理不过是给阿谀奉承一层好听的遮羞布。
但经过一些事后，我对此的想法改变了。**向上管理的本质跟向下管理一样，都是沟通协作**，只不过向上管理是跟你的上司或高级管理人员进行有效沟通，进而实现最佳的工作结果和职业发展。
广义上的向上管理涵盖了上下级间的所有事务，诸如“如何与不称职的上级相处”，但这里就不展开讲述这类的职场危机化解指南，而讲讲向上管理通用的方法论。
### **沟通的意愿**
向上管理的目的是为了赢取更多的职场资源，而最基础的一点是沟通的意愿。
我身边就有不少朋友喜欢秉持着“酒香不怕巷子深”的态度，觉得只要把工作做好，结果和成绩自然会证明一切。他们嘴巴闭得堪比珍珠蚌，可如今的市场千变万化，谁都无法预测下一刻的需求是该怎么样的。
拒绝沟通，只会有一个下场：你不了解工作的全貌，甚至无法判断当前任务的优先级。
将无关紧要的需求加紧做，而真正迫切的需求却延迟后推。
不要害怕嘴拙，先有沟通的意愿，你才能了解工作，了解老板，了解客户。
### **了解你接手的业务**
程序员的工作绝对不只是写代码，还包括解决问题，选择技术，和汇报。而这些都取决于你对问题和提问者的理解。你需要明白方案针对的业务问题和汇报对象的需求，才能对阵下药。工程师必须了解业务，**因为业务是目标，技术是达成目标的手段**。
## **知识的诅咒（Curse of knowledge）**
知识的诅咒是一种**认知偏差**，指的是当一个人对某一主题了解太深时，他/她往往会忽略其他人对该主题知之甚少或一无所知。这种偏差在很多领域都有出现，越是知识壁垒深厚的行业越是明显。
IT行业自然不会例外，内行和外行两方的信息差足够大到对牛弹琴。比如在与客户或项目经理沟通时，程序员可能会忽视对方对项目需求的理解，将自己的想法和理解强加给对方，导致沟通困难。
### **如何避免知识的诅咒？**
很简单，尽量用普通名词代替专有名词，用简单、易懂的语言解释复杂概念，同时换位思考，学会倾听他人的观点和需求。
## **关于Masutaa**
Masutaa是个互联网从业者自由协作交流平台，链接行业内TOP10%人才！目前平台上已经有将近400名互联网尖端人才，其中近70%的从业者从业年限超3年。加入Masutaa，加入自由生活！
有疑问加站长微信联系（非本文作者））
