作为一个IT人，我们势必都会有技术焦虑，如何脱离油腻的技术生活，让自己有一个清晰的规划，今天就和大家简单聊聊我的想法。
有一天走在路上，脑袋里突然冒出一个词：三十而立，可我的诗依旧还在远方。
三十岁左右，是一个让人焦虑的年纪，而抬头看看，全世界都在焦虑，所以本文我将先对焦虑做减法，再来看看技术焦虑的解法。
技术焦虑的由来
对于焦虑，美国著名心理学家罗洛?梅在他的代表作《焦虑的意义》这样形容：
如果你在马路上，看到一辆疾驶的汽车迎面而来时，我们会感到恐惧，心跳加速，快速横穿马路到达安全地带。
而当我们处于朝不同方向疾驶的汽车流，被困在马路中央时，我们心跳加剧却又无所适从，心里产生一种深深的空洞感，这就是焦虑。
简单来说，感觉到威胁、找不到突破口，内心空洞，这就是焦虑。技术生活何尝不是如此？
我简单问了几个朋友，他们对于技术焦虑的看法如下，我简单做了标注：
怕自己学到的不是有用的，或者说会很快被淘汰的技术，又或者是不值得花费大量时间学习的技术。—找不到突破口
年龄大了，职业发展是个焦虑点。—感觉到威胁，内心空洞
刚毕业时想学各种各样的新技术并进行实践，有段时间突然静下来发现几乎一无所成，只是知道一些名词和方案，如何落地推进都没真正实践。—找不到突破口，内心空洞
33岁的人了，还是丢不下技术。—感受到威胁，内心空洞
一直有个担忧，看到大家分享了很多技术方案，但这众多的技术方案也容易让一些同学迷失自我，不知道该从哪入手，如何选择。—找不到突破口
目前没有一个清晰的技术规划，很容易在繁华技术方案中迷失自我。都知道适合自己的是最好的，适合自己未来2~3年规划的是最佳，但实际上还是东一榔头西一棒槌。—内心空洞
如果一定要给这三点一个更通俗的解释，可以归纳为焦虑的三个阶段：认知、认怂、认命。
有时发现，我们很多人更愿意去说去想，而不是去做。那怎么解？下面从问题入手，来看看对策。
“感觉到威胁”的解法
要有一个清晰的规划
凡事预则立，不预则废，制定计划是给自己的一个心理暗示，给自己一个阶段性目标，然后把它做分解，拆分成为自己能够实现的一些任务。
规划做多久？短则一周，多则两年。我们都是心智成熟的人了，就不用再灌什么鸡汤了。
去新公司面试时，一般也会问一下你的职业规划，但我觉得很多人都没想明白，我们做了计划都很难保证达成目标，但如果没有计划，结果更可想而知。
就好比数据库中执行SQL都需要有执行计划，执行计划也有很多的性能差别，比如下面的3个表关联，就有这么多的执行路径可供选择。
计划制定了，还要有一个规划和章法，哪些是优先的，哪些可以排后。
如果你毕业有五年了，会明显发现有规划和无规划的身边同学差别还是蛮大的。
所以有些同学一边刷着段子和电影，一边感慨世事不公、怀才不遇，你缺的是一个规划并付诸实施。
我和技术焦虑的故事
在《我也可以是流浪诗人》中有几段话，很有意思，摘录一些分享给大家：
做你没做过的事情，叫做成长
做你不愿意做的事情，叫做改变
做你不敢做的事情，叫做突破
我觉得很受用，自己似曾想过但没想通的问题，好像有了一些答案。
联系一下我自身，我希望找到一个能够施展拳脚的舞台，有考虑大厂，毕竟有光环效应。
不需要从0开始，如果以10分来估算，直接可以从7、8分到达9分，而如果是一个新的公司，那么很有可能就是从3分甚至从0分开始。
我已经厌倦了大厂光环效应，也厌倦了只说不做的浮躁，如果有时做事总是隔靴搔痒，我就会有一种感觉，所谓的技术焦虑和公司的关系不大，而是自己在职业发展的道路上存在困惑和问题。
我在给DBAplus社群的MVP获奖感言这样写道：“所谓迷茫就是懒，多做点实事就有目标和方向”，那么问题来了，该做哪些事情，该怎么做，一系列的3W问题，先画个图说明一下：
我之前从事的工作中Oracle方面较多，但因为工作还是有不少的机会来巩固MySQL方向，所以从技术栈上来说，数据库方向也算是站稳脚跟了，这可以说是成长。
但从一个整体的角度来说，我只是做了其中的一小部分，下面是两个大圆圈，分别代表数据库技术和开发技术。
数据库技术中目前的工作中能够直接拿过来复用的就是一些规范和架构设计的东西，而且这里面还有很多对我来说是新的思考方向和挑战。
MySQL纯技术栈的内容其实算是常规，如果目前的工作业务量还远未达到瓶颈点，性能优化的部分少一些，那么我们首要巩固的就是开发自动化平台。
新问题来了，数据库开发方向目前很清晰的一个点就是自动化运维，确切的说，是DB自动化运维平台，说是重构也好、重建也好，不是完全从零开始，但基本是从零开始的节奏。
要做这个事情，得有人来带路，大家都不知道怎么走，站在原地讨论planA、planB，问题肯定是解决不了的。
得有人迈出来，大家都不会，你就得冲在前面，大家没考虑的问题，你考虑到了；考虑的问题，你已经心中有数了，这事情就可以干了，这就是改变。
我做事喜欢结果导向，喜欢快速迭代，能10分钟搞定，绝对不愿意花15分钟。
但是技术行当，还得耐得住寂寞，因为很多事情10分钟搞不定，可能分钟，0分钟也搞不定。
但这不代表我们真搞不定，需要花一些时间，花一些额外的代价来补课。水到渠成的时候，自己也得到了成长，这就是突破。
把握核心竞争力
对很多同学来说，做技术的核心竞争力，除了丰富的业务经验（这个需要时间的积累），技术层面的积累也是需要一个体系的。
比如一个工作10多年的老司机和刚工作的新手，处理一个简单问题的时候，大家的表现都差不多。
很可能新手精力更充沛，做得更快，但一旦有了一些紧急的情况时，新手就会手足无措，这就是经验的价值。
经验的价值在现在的大环境下空间也在不断压榨，以前的独门秘籍和攻略随着知识积累和痛点的积累，都会逐步解决。
所以要去做更有难度和价值的事情，这些都是经验的积累和铺垫，时间是个好东西，它会不断证明你有多幼稚。
我眼中的工程师模型是这样的，简单三个特征：鹰眼（眼光犀利），狮心（内心强大），绣花手（做事认真细致）。
还有一个方向就是技术积累，在学习计算机的时候，我们知道：程序=算法+数据结构，但这一点在如今的时代，大家好像都忽略了。
我举一个例子，编译原理想必大家在大学都学过，但包括我还有很多同学，应该都在大学完美地绕过了这个学习的痛点，有很多人在想，学习编译原理有什么用，这里答案我都给你找好了。
来自知乎的一个不错的解答，关于编译原理我一直最喜欢类比的就是人体解剖。
在欧洲教会还不允许做尸体解剖时就有两类人在一起偷偷摸摸搞人体解剖：
一类是医生，从外科手术的角度来说应该比较容易理解，不解剖根本不可能知道如何做外科手术。
还有一类则是画家，他们只是为了可以更好地在描绘皮肤时体现肌肉的质感，就愿意冒着被教会处罚的危险来参与人体解剖。
而且即使是现在，所有的现代绘画的教育虽然不会再像医生那样实际操作解剖，但肌肉层的解剖图仍然是必修课。
在我看来，完全不懂编译原理的程序员，就好像是完全没有学过人体解剖图的画家一样。
当然不会说一定就无法成功，不过如果有更好的基础可以提高成功的几率，在知道底层的情况下，对上层的描绘会更加写实，更加生动。
抛开比喻，从现实的方面来说，编译原理学过之后的益处（不考虑最后都没有入门的情况）包括：
可以更加容易地理解在一个语言中哪些写法是等价的，哪些是有差异的。
可以更加客观地比较不同语言的差异。
更不容易被某个特定语言的宣扬者忽悠。
学习新的语言时，效率也会更高。
从语言a转换到语言b是一个通用的需求，学好编译原理处理此类需求时会更加游刃有余。
另外还有一点，就是一直有人说不用重复造轮子，所以不需要学习编译原理这样的课程。
我想说的是，学编译原理不是让你去造轮子（大多数人的实力，学了也造不出轮子），而是要让你知道现在一共有多少种轮子可以选择，它们的特性如何。
好比F1比赛，其实现在所有的车队可选的轮胎都是一样的，但不同车队根据自己车的情况和战术等，做出的选择会截然不同。如果你对轮胎的理解只是它可以转，那么你根本无法把它的能力发挥到极限。
大学里面几门非常核心的课程，比如操作系统原理、数据结构、计算机组成原理、算法，这些在你工作的一些年头可能不会排上用场。
但等到了一定的阶段之后，这些就是你思维的沉淀，计算机技术就是在前仆后继的贡献中不断积累起来的，沉淀下来的很多理论和问题处理方法，光想肯定是想不出来的，我们得抓住几个点或者面深入下去。
有些同学说现在的大数据学起来好难，深度学习也很难，因为理论层次上升了一个台阶，会明显感觉到压力。
技术短板理论
很多年前大家都会提到一个短板理论，把技术做得很纯粹的同学会有一个很明显的天花板。
很多做技术的同学会在一定的年龄之后纠结是做技术还是做管理，会有一个技术线和管理线。
如果可以，我还是建议以技术为主线做一些管理工作，不要偏离一线，让能听见炮声的人来指挥这句话还是有道理的，技术圈的人比较执拧，基本都是以技术服人，纯靠管理很难推进。
三十年河东，三十年河西，技术不断的发展，解决了很多痛点，这些年来短板理论也受到了挑战，在这种需求之下，不温不火的算法工程师这些年来真是大红大紫，不乏一些百万年薪的高级职位。
但如果细细看下面的图，你会发现只是某一方面够强，需要付出更多。换句话说，要突破短板瓶颈，你得在某一方面已经非常强大，要不就很容易被鸡汤。
换工作这件事情
三十岁后，人生逆袭的天花板开始收窄；其他赛道也会收紧闭合，很多时候我们只看得到自己眼前的那条。
技术圈内也有不少朋友，现在大都成了行业内的中流砥柱，会时不时有招人需求，我也会帮忙推荐一些朋友。
每每想起招聘需求，很多时候的JD都是他们得自己根据一些需要来临时补充。说简单一些，那就是技术过硬，人要靠谱。
技术过硬这一点无可置疑，但我也有一些不同的意见。从我的感受来看，现在的公司面试已有了非常大的变化，早期的面试可能还有笔试、若干流程，还有些公司有一些辩论会之类的，说白了是一些辅助——加分。
现在的很多公司对待新人也不会有一个相对平滑的培训周期、逐步的角色替换过程，有些加急的场景中，可能今天入职，这周或者下一周就直接上手。
所以招人都是要直接上来就能用的，都不愿意去培训新人。换做另外一个极端，那就是很多新人还经不起培养就离职了，对公司来说更加得不偿失，所以这是一个伪命题，重重矛盾但又相对合理。
在这一点上，除了薪资，求职者更需要明白公司的文化（比如加班文化）是否适合你。
Businessisbusiness，人靠不靠谱还是很难面试出来的，我们只能根据聊天来判断他的性格，通过一些细节来看他是否诚实，通过几分钟几十分钟确实是很难的，这些都是偏主观的判断了。
市场行情都会变化，看到别人很滋润，不心动是假的，所以焦虑也会时不时冒出来，让人上火。
不管外面是金三银四，对于自己，你得清楚自己的一个基本规划，向钱看or向前看，都要看。
但是不要轻易迷失，千万不要因为逃避而离职，那么问题可能就是一种复制和延续而不是解决，哪个公司都有大大小小的问题，我们工作的本质就是要不断解决问题。
份内份外的事情
什么是份内的事情？就是你的本职工作。什么是份外的事情？一种是把本职工作做得更好，或者是协调团队产生更大的价值。
份外的事情最大的特点就是你做了没人喝彩，不做也没人指责你，所以事情说小了是份内的，说大了是份外的。
以至于我们在工作里面做事情会分得很清楚，有了流程控制，至少出问题不会甩锅甩到我这里，要不就怪流程不完善。
但对于个人来说，份外的事情变成份内，是一种成长，比如你只会数据库，去尝试了解一些系统层面、存储层面、内核层面的东西，也不是坏事。
在这个基础上去深入理解业务，能够让自己的眼界更加宽广，考虑问题的角度更加全面，而不是一些孤立的点，还是需要用一个整体的眼光来看待分析和解决。
所以我们有时候叫全栈，有时候叫做转型。当然从技术角度来说，技术问题都不是问题，但是实际解决的时候，会有一些出入，很多问题到最后发现已经完全偏离了原来的方向，就是我们看待问题的角度不对。
业内份外的事情变为份内，Devops就算一个比较典型的，原本风光无限的DBA需要掌握一些其他技能：系统运维、系统开发等，敏捷运维在这个时候提出来不是凭空想出来的。
很多重复性的工作需要得到简化，很多复杂的工作若替代不了的，可能要么直接被废弃，要不推翻重来。
这个过程有点类似于行业洗牌，能够坚持在最后的，始终是那些拥抱变化的人。
份内、份外的事情都是解决问题，解决了问题大家相安无事，其乐融融；解决不好，也是能够把伤害和影响降到最低的一把标尺。
哪些事情我是本着人情来做的，哪些事情不能因公徇私，可能就是这么个理吧。
如果你觉得目前很舒服，不妨做些你不愿意做的事情，做些改变，做些你不敢做的事情，来突破一下你自己。因为机会不会等着你，也不会问你准备好了没。
能坚持下来的都是少数
有很多人向我取经，说职业生涯如何规划，技术方向如何选择，坚持了一段时间之后我们就失去了联系。
因为我知道，做一件事情，能坚持下来的都是少数。你去面试，说我很专注，但这一点很难证明，如果扪心自问，这些年来自己坚持了哪些事情，好与不好，每个人心里都会有一杆秤来衡量。
上面这个图怎么理解呢？它是知乎一个有名的游戏，即个人每个人手里有1块钱，大家随机交换，看最后每个人手里剩下多少钱。
经过真实的模拟，发现了一套理论：如果通过SQL来模拟，也是分分钟搞定的，可以看到，绝大多数人都是原地踏步，只有极少数的人能够走出这个圈子来。
左边的图是0人的样本，次测试之后，手里剩下0块，1块的占绝大多数，基本是70%的比例，而能够突破的人（有2块，3块）是少数（15%），卓越的人更少（5%）。
右边的图是允许你来透支，样本是人，得到结果和左边是相似的。不知大家看到这个图，内心是怎样的感受，我个人觉得这些数字给我上了生动的一课。
工作生活都是如此，我们身边有很多锦上添花的人，但雪中送炭的很少，做一件事情，要达到专注，不能钻牛角尖，按照既定的目标来实现，方为上策。
“找不到突破口”的解法
理清技术方向和脉络
技术圈的更新是极其快的，基本上不到半年就会有一些工具和方案出来。
如果让一个开发工程师写一下自己接触过的技术，估计能写满一页A4纸。有了动力和方向，面对纷繁复杂的技术和方案，该怎么选择？
在混乱之中，我们要理清下面的几个问题：
你了解自己的行业吗，比如数据库行业，技术的发展趋势怎么样？
你