码路指南：别错过人生中学习的黄金时期

Myth丶恋晨 2022-08-06 13:11 131阅读 0赞

#### 转自：http://www.nowamagic.net/librarys/veda/detail/2665 ####

#### 错过人生中的好时机 ####

没毕业的程序员或者刚毕业的程序员往往感觉空余时间比较充沛，还很苦恼不知道如何打发时间，但实际上一个人一生中可以用于充电的时间远比想的少。一旦错过时机，往往悔之莫及。

对于大多数人而言，人生就像个模板，小处还有偏差，大处却基本相同。

*  20~30岁这个阶段可以讲是黄金时期，这个阶段里，家庭负担较小，可以自由支配的时间较多。当然撞到了很特别的、需要疯狂加班的公司只能另算。
 *  30岁之后因为娃娃出生等，家庭上的时间开销增加，个人可支配时间变少。其中很大一部分人还有很大可能会面对电视剧里常说的婆媳矛盾，让你每天心绪不宁。
 *  40岁之后，家庭琐事会进一步增加，典型的上有老下有小。实在运气不好的自己也会生点病---颈椎病、腰间盘突出、胃病大概可以入选程序员的三大职业病。
 *  50岁之后，时间上会再次解脱，但可惜的是自己也老了，时机不在。

如果把人生按照年龄画一条抛物线的话，40岁左右一个人可以达到的人生的顶点，未来再突破的几率则变小。从历史人物来看，大器晚成的不是没有，但真的很少。

用心观察就会发现，招聘启示里经常会注明年龄要在35周岁以下或者40周岁以下，除非是招聘高层。这反过来意味着如果没有到高层，人生会在40之前定型，之后有下滑危险（如遭遇不景气、公司倒闭等）。对程序员而言，这种风险尤其的大，因为很可能你辛苦掌握的知识体系被更迭掉了。

学习本身无疑的是需要顺应这种自然规律的。

很多人很大的一个错误在于，在[黄金时期][Link 1]，没做什么积累，就顾得享受生活了，而一旦意识到积累的必要性时，却又受困于诸多琐事而欲振乏力，最终人生高度有限，并迅速走低。这就是现代程序员版的“少壮不努力，老大徒伤悲”。

基本上讲，35岁以前要把需要花大量时间，比较硬的技能，学习曲线陡的技能掌握，具备工作所需要的所有主要技能，而35岁之后则主要关注知识的更新和某些软技能。

学习时添水战术效率真的很差，每次点一根火柴烧水，一亿年水也烧不开一壶。同时，比较硬的技能（比如：Donald Knuth的《计算机程序设计艺术》)往往是需要大块时间投入的，但年纪越大时间越呈现为碎片化，越难搞定硬的知识 —— 先天就容易造就添水战术。比较软的技能，则可以用碎片时间来学习，比如：提高PPT的制作水平，提高表达能力。

如果能够安排好自己的时间和软硬知识的关系，那么就可以在特定基础上做积累，小步前进，使自己的价值越来越高。从这个角度看，年轻绝对是一种债务，大多数人必须在他没完全结束前，还掉所欠的东西。

那么具体来讲那些东西是比较硬的，要在35岁前搞定呢？这因目标而异，但下面这些项目应该具有非常高的通用性：

*  精通一门最常用的语言
 *  了解一个最常用平台的基本机制，比如：内存管理、线程机制等
 *  UML图和面向对象分析设计方法
 *  设计原则，如：职责单一等
 *  设计模式
 *  《代码大全》里讲的一切
 *  精读一个知名的，但有点规模的程序。这点上要感谢开源项目给我们提供了这么多优秀程序。但要谨防好高骛远，动辄挑战Linux内核，精读是关键。
 *  累积一定的代码量，比如：独立的完整做过一个数万代码行的东西。这里的关键是完全自己打造，一定不要拷贝粘贴。
 *  掌握基本算法和数据结构（可以不自己写，但至少要知道其复杂度和区别）
 *  养成一种清晰的编码风格
 *  有自己的专业（金融、高并发网站，图像处理，TTS等）

学习英语的时机和必要性

总的来看，程序员学习英语是一项投资回报率相对比较好的投入。从目标上来看，程序员未必一定要口语流利，但最低要达到阅读英文资料没有障碍的程度。这里面有一个微妙的事情，一旦英语阅读问题较大，查找问题会习惯用百度，这天然会限制一个人的视野。不是说百度自身有多不好，而是说英语的世界里有着更多更精彩的内容。

不管喜欢不喜欢，我们必须承认一种现实，在IT的世界里英语是一种世界语，一方面是由于美国公司的强大，一方面则是由于开源选择了英语。这最终导致IT世界里的新动向、解决问题的小技巧、网站的架构等等都要到英语的世界里去找。在StackOverlow很容易找到各种小问题的答案，在Quora则很容易找到各种网站的架构。

从学习时机来看，这件事情特别应该在大学里面搞定，如果不行至少也要在毕业1~2年内达到阅读无障碍的程度，当然希望加入外企还需要额外的付出。从学习方法来看，学习外语真没什么特别的窍门，坚持并投入时间即可。

#### 停止知识更新 ####

对程序员的增值而言，人生里最大的陷阱也许是为安全的假象所欺骗而彻底的放松自己。这种状况在生存环境比较恶劣的情形下不太会发生，但在垄断企业或某一领域中绝对领先的企业里则容易滋生。发现自己是否停止[知识更新][Link 2]了并不困难，比如：一年一本书没看，一年一点新知识没接触，一年中工作负荷基本不满等都可以成为一种信号。

这真的是温水煮青蛙，一旦到了三十几岁，并在这种环境中呆习惯了，那么再想跳出来，基本没可能。唯一能做的事情是，祈祷公司不要挂掉，公司也不要来场运动，进行人员的大换血。孔夫子说：日当三省吾身，这是很有必要的，至于认识危险后能否做点什么，那就是事在人为了。

1. 技术人员的知识更新

接触一个新的岗位后，大致要经历一个学习并逐渐胜任的过程，这个时间段里大多数人的学习热情是很高的。一旦基本胜任之后，事情就有了变化。

很大一部分人可能会感觉，反正工作也就用到这么些知识，学习其他的也用不上，因此开始把自己封闭起来，不太看书，不太看技术新闻。

这其实很危险，因为这种做法等于把自己绑死在当前这份工作上。而任何一个产品都有自己的生命周期，一旦一个产品的生命周期结束时，碰巧其所用的技术也已经过时，那么当事人就会很尴尬。因为产品可以结束，生活却还得继续。

这里面一个非常经典的例子是MFC。微软的这款产品的历史非常悠久，从1992年发布到2012年几近存在了20年时间。随着90后程序员的逐渐出现，马上这款技术就要变得比程序员的年纪还要大了。

即使到今天，很多桌面应用仍然是基于MFC开发的，这可以通过查看程序包的dll依赖来很容易的进行验证。MFC是一个很大的池子，有深度、有历史。想把MFC的类继承关系、消息机制、框架结构、RTTI、序列化都搞清楚还是要很花一点时间的。

现在我们假设一款庞大的企业应用是基于MFC开发的，一个程序员也通过几年的努力了解了MFC，了解了应用本身，并可以负担起Bug修正，新功能追加等任务了。

接下来这个程序员似乎没什么好学的了。因为MFC的更新几乎已经停滞，因此对MFC的学习几乎不需要花太多的时间了。现有代码也理清楚了，也不需要再花很多时间学习了。现有程序也比较好的满足了企业的需求，推倒重来的可能性几乎没有。

那这个时候这个程序员不需要学习了么？答案一定是否定的。这里面蕴藏着一个天大的矛盾。

从企业的角度看，一定是需要一个团队来维持这个程序的开发的。但从个人的角度看，如果把所有的青春都耗费在老技术上，那么一旦老技术退出历史舞台，个人该何去何从？

还是上面的例子，假设说一个人持续投入在这类开发上，当他45岁的时候，当前产品生命周期结束，世界变的只有移动开发和云端开发，那么只擅长MFC的他该何去何从？

如果真的如此，这个人就被逼到了死角里，人生很可能产生巨大滑落。所以一定不能认为所学足够而停止技能的更新与学习。

从具体应对措施来看，一是要参照知识的地图，横向扩展知识的广度，比如不只要盯着代码，也要了解业务；不只关注开发也关注一点估算；二是提升可流动性比较好的东西的掌握程度，比如：面向对象分析与设计，这样跨越到其他技术时就能够比较平缓的进行过渡。三是要争取轮换岗位，争取多种实践机会。

2. 管理者的知识更新

到现在为止大部分人认同，管理者是需要懂技术的。从逻辑上看“懂”基本上是不瞎指挥的前提，所以这可以称为中国版的“现场主义”，估计争议不大。

那关键问题就是究竟要“懂”到什么程度？

如果说两个人，一个选择了管理方向，一个选了技术方向。接下来要求管理方向上的人技术水平要和技术方向的一样，那么除非这个人特别天才，否则不太可能。正像前面所说，这是由于这两个方向的“Key”不同所造成的。

如果把目标设定为确保最终产品的成功，同时假设管理者有更高的决策权，那么管理者必须在下面这些方面有技术感觉。

从做产品来看，要想成功，有两个关键维度需要同时进行把握，一是产品的概念完整性的把握；一是用合适的手段去实现这个产品。

前一个话题很老，《人月神话》就有提及，但实践中却总是被人忘记。好的产品必须贯彻某一种统一意志，iPhone、微信又重新验证了这一个老的原则。 机械拼凑的产品虽然融合了很多人的想法，但往往是平庸的，并且在项目执行过程中，往往是出错的根源。很像是虽然有法律，但每个人有自己的理解，各行其是这样一个状态。这种概念完整性是管理者第一个需要有所把握的事情，其次就是解决如何去构建产品这个问题。为达成这一目标在下面这几个方面上，管理者要有自己的理解，至少要有自己的原则：

下面简单列举几个比较关键的考量，这和前面论及的如何往博的方向发展有点重叠：

*  使用现有产品还是自己开发
 *  比如：那些模块适合自己搞定而那些购入就可以了。购入的时候要遵循怎么样的标准去选择。
 *  使用那种平台技术
 *  比如：是使用微软的技术，还是开源的技术。
 *  现行架构是否可以达成产品目标
 *  比如：在硬件加软件可以同时支撑的并发数目。
 *  代码可维护性如何约束
 *  这要求必须熟练掌握一些原则性的东西，比如：什么信息隐藏、正交分解、抽象是否充分等。以及一些无歧义指标，比如：圈复杂度，单元测试的收益平衡。
 *  那些环节必须固化为流程，那些一定要团队自由决定
 *  比如文档化要到什么程度才合适，不同阶段间什么是必须的输入输出。
 *   ... ...

假设说有人不这么认为，而是在做了管理后，表现出足够的惰性，不再持续更新自己的知识体系了，那么会发生什么事情？

这时候会很可能会管理倒置。即管理者是名义上的上级，但基本失去对现场的把握，所有的决策完全依赖于下属。得力下属不在，各种决定就只能靠瞎蒙，最终变成只会沟通的管理者---即使被食人族吃了也不会有人注意到，因为存在价值已经被无限稀释，变成了一个象征性的符号。也可能会和下属爆发激烈冲突。因为这类管理者没有自己的立场，上面有任务只能下压。结果同实际情况偏离万里，不具有可实现性，这类管理者无法对自己的上司陈述，也就只能向下转移压力。

不管是那种，一旦到这种地步，其实是趋于失败，只能祈祷食人族不要来。

为什么中层管理者也要坚持知识更新？

在IT行业流传着一个很有名的关于食人族的笑话，这个笑话说的是：

两个食人族的人应聘进了某家大公司，公司人事主管知道这两个这伙每天都要吃人，于是警告他们：“如果你们胆敢在公司吃一个人，你们就会立即被炒掉！”两个食人族唯唯喏喏地答应，表示绝不会在公司吃人。两个月过去了，公司平安无事。

突然有一天，公司发现负责打扫公司卫生的清洁工不见了。于是人事主管非常气愤，找来两个食人族怒斥，并当场炒掉了他们。出了公司大门，一个食人族马上对另一个抱怨起来：“我一直警告你不要吃有在做事的人，你就是不听！我们两个月来每天吃一个经理，没人发现。你看现在吃了清洁工，他们马上就发现了！你真是个猪！”

这个笑话嘲讽的是某些大公司大企业病发作，人浮于事。大企业病的成因很难一下子说的清楚，但结果却比较明显，一定会导致较多人成为中层管理者。如果说成功的企业天然有感染大企业病的趋势，那无疑的中层管理者也天然有着膨胀趋势。从个人角度看，成为被食人魔吃掉也没有人在意的经历并非是什么好事，因为这意味着存在价值减弱，也不需要什么知识更新。一旦面临裁员这类事情，这个人很可能已经失去了面对残酷竞争的能力。

[Link 1]: http://www.nowamagic.net/librarys/veda/tag/%E9%BB%84%E9%87%91%E6%97%B6%E6%9C%9F
[Link 2]: http://www.nowamagic.net/librarys/veda/tag/%E7%9F%A5%E8%AF%86%E6%9B%B4%E6%96%B0