软件技术人员的瓶颈,为 35 岁之后做准备

2022/04/20 16:18
阅读数 1.4W
AI总结

本文经授权转载自:https://zhuanlan.zhihu.com/p/498762187,作者:姚勇

我介绍下对他人有用的信息。我靠技术创业上岸。技术是我的能力基础。但取得的技术结果和商业结果,有着更广泛复杂的元素。比如运气至少占60% 。

我在文章最后会介绍自己在技术探索路上,起到里程碑作用的几本读物。

对软件人才可借鉴的经验:

软件解决问题,需要三层:

1理论知识 算法,数据结构,微机原理,操作系统,线性代数,离散数学,软件工程,以及与你工作相关领域最新的科学研究理论知识
2技术 某种计算机语言熟练掌握使用经验丰富,或者某个领域钻研深入,类似图形,数据库,网络服务器,AI等等
3工程 有限时间满足需求解决问题能力,与人合作开发的能力

第1层代表了你能够达到的上限。也就是今后技术发展的最高点。 第3层代表你的下限,决定了你35之后混得最差的底线。

第1层,理论知识

知识掌握越多,越新,越有可能扩展你的技术能力,和工程能力。 也就是掌握技术比别人好,工程问题你办法比别人多。比如对算法和数据结构掌握牢固,对操作系统掌握深入,当你要做尽可能压榨性能和内存的软件,你就可以从底层功能来解决问题。至少使用一些快速的底层工具比较顺利。比如内存管理,速度优化等。宏观上,对计算机体系理解越深刻,对软件质量管理理解越到位,你带领团队能做的软件规模和质量就会超过其他公司。你就成为某个公司的不可或缺的人。工资自然就比别人多。

绝大多数程序员的天花板就是底层知识不行。现在软件中间件和工具库太发达。一直满足用傻瓜工具和代码库,挣口饭吃。这种码农和那些工地搬砖的是差不多的人。35岁之后必然被淘汰。这一层决定了你以后最好的收入会在哪里。过去我喜欢看自己领域国外最新的论文。我发现和我有同样喜好的人,后来发展的都很好,钱也多,买房也不愁。不是说看论文就能买房了。。。只不过这个样本也许有点借鉴意义。说明对理论的持续补充,会增大你视野,尤其是解决问题的视野

到了后期做技术管理,依靠的依然是底层知识+大量经验。

理论知识就是得拼命看书,看论文。还得能融会贯通。

第2层比较单纯。绝大多数年轻软件人员都在这一层。并且以数量掌握这一层技能为荣。某个语言,某个工具使用,某个图形技术。 但实际上,有了第一层的理论知识,这一层就是一个砸时间去理解,记忆和熟练使用攒经验。小学生也毫无障碍。不太建议只拼这一层能力。虽然这一层是必须的基础。

第3层,解决问题的能力。

有两个要素与解决问题能力相关。第一个要素是工程能力。 这种能力是在前两层基础上建立的。比如我虽然瞎自学了好几年计算机。但毕竟有热情,比别人先耗费了大量的时间(几千小时),自然多积累了一些知识和技术。第二个要素是“对问题难度极限的感受”

1)工程能力

拿自己举个例子:我过去小学用机器码编程。这种比汇编还底层的指令编程,直接操作计算机的硬件。比如直接操作屏幕buffer,键盘输入。条件判断指令需要自己计算偏移量。由于机器指令编程难度极大。没有任何debug工具。所有程序逻辑必须完全在纸面全部验证完成。出了问题只能想各种效率极低的方法去检测。所以更加锻炼了我用计算机指令解决问题的能力。 等于一直绑着一堆沙袋练习跳远。 同时间接地,我熟悉了微机原理,软件与硬件的关系,还有汇编语言。这种熟悉对于后来做C++开发高性能图形引擎,有极大帮助。别人碰到难复现bug束手无策,很多时候看汇编和寄存器情况就能大致猜出个1成到2成。

2)“对问题难度极限的感受”

我发现对一个程序员最大的阻碍,就是一种对解决问题极限难度的感受。 他决定了你最差的情况。或者收入。这个很有可能和性格有关。半天生。 当碰到一个问题,如果经过一段时间努力,你觉着太难了自己无法搞定,自然就放弃了。或者更深层的心理是:我已经挺牛逼的我技术也行,会得也多。这问题都什么玩意儿啊,要么就是老板给我的活有问题不是活人能做的,要么就压根是别人的问题。 这两种想法决定了你这个人混得最差的程度在哪里。

“能力被动型“

有些人天生就对问题跃跃欲试喜欢挑战和新。 有些人一切以“我当前所掌握技术和能力为标准“来判断事情难度。 我管这类人叫“能力被动型员工“。被动型人水平也有高有低。较高水平的这类人很可能在之前某个人生阶段(比如聪明,大学被逼,年轻心态开放情况下)习得的知识和技术。但因为是被动型,非发展性人格,所以到了30之后会逐步走下坡路。

合格技术管理者和员工针对一个技术问题的沟通中,很容易发现“能力被动型员工”。这时候管理者心里会默默给你一个标签。以后只会选择你能力之内的工作给你。合理的使用你,只让你辛苦,不让你那么痛苦。由于你一直困在“当前这一秒我会的东西是最高难度“,也接触不到更多更新更难的事情。接触了也无心无力奋争解决。 能力也不会提高。 所以你和一个原地拉磨的驴子很像。体力耗光,也就卸磨杀驴了。

技术人都有发展自身能力和技术的倾向。主观上,如果你不是做一天和尚撞天钟,你肯定不认可自己是能力被动型。 但有种学习的障碍,自己被自己知道的东西困住了。你认为的极限真的就是你自己的极限,和这个技术问题的极限吗?据我十几年的观察,多数情况下并不是。 另外,工程实际是解决问题,不是用完美或者自认为满意的方法解决问题。这需要特别灵活的头脑。工程思维,和钻研理论与技术,用的是不同的思路。这种思维转换对很多技术人员有困难。久而久之,自己被自己耽误了。丧失了很多机会去突破自己的极限。

这种思维习惯不限于技术人员。一切靠一项技能吃饭的人,都会存在。如果这类人目光还短,只盯着眼前鸡毛蒜皮的小利,想不到5年到15年以后自己长期利益。那下场就更惨。这个和看工资待遇不矛盾。你既要看现在的待遇,也要看当前其他公司的更好待遇机会。更要去想5年或者15年以后的工资待遇。

技术管理

对技术人员,35岁之后合适的路之一,是技术管理。年轻人永远会进入这个行业。但软件行业,是个工程行业。也就是需要一群人在一段时间共同完成一个任务的事情。所以一个稍大的项目,总需要一棵树一样的管理体系。每个节点都需要一个管理角色。当然这个角色本身也有可能是具体技术人员。

软件管理大致分两块,一块是软件开发与质量管理。 一块是软件人才管理。 办公室政治,拉踩竞争对手,拍好老板,争取资源,甩锅,这些也都是必备技能。不要忽视。至少做到不被绊倒。不去害人可以,但也不能被别人害了。 技术管理最大的好处是,组织需要你做出结果。软件按功能可以跑。 这个事比政治管理要单纯一些。

软件开发管理与软件质量管理,是技术管理人员很重要的能力。 真感兴趣去搜索“软件工程“,”软件开发管理“,”软件质量管理“等关键字。 我就不多说了。你只要知道35岁这些关键字对你还房贷,养孩子很重要就是了。

人才管理就是组建团队,培养,分配工作,动态调整团队,调整每个人工作,以便让工程最大化顺利进行。问题最小化。预防问题发生。成本、工期与质量死亡三角控制等等。高科技人才管理自成一套体系。

管理也有科学理论。管理学之类,社会心理学,动机心理学等。记着多找书学习。别和那些野生管理者一样无知。最后就只能靠政治手腕,那种人一旦被斗下来,就成了傻逼。

劳心者治人,劳力者治于人;治于人者食人,治人者食于人。天下之通义也。你35岁被公司裁,或者你裁掉别人的时候,记着谢谢我。

对我技术生涯起到里程碑作用的读物 - 程序员生存救命书系列

我从事工作需要C/C++/C# ,OOA/OOD/OOP,软件架构等。后来技术管理也需要软件工程管理,质量管理,复杂度评估之类ISO/IEC25010/CMM 体系涉及到的东西。 这是个人经验。不一定适合多数人。做个参考。在我那个时代(2010以前),万不得已不要看国内的书。最好是翻译不错的国外经典书籍(台湾也行)。2022的当下我不了解。

书籍非常关键。软件技术基本都靠自学。 如果个人能力不足以自学精通,参加商业收费培训,更需要书籍指引。找到靠谱培训其实效率更高。问题就是很容易碰到二把刀教出三把刀。建议一定要参考教师自己过去从业经验,不要看广告吹嘘,只用看培训师亲自参与主力开发过的软件的规模大小。代码行数。软件的结果如何。

1 个人建议如果工作需要C/C++, 汇编语言一定要学。微机原理一定要学。

我记着自己小学时候是拿着一本Z80 指令集手册自学。后来家里买了学习机,换成APPLEII 说明书,后面也有很厚的指令集说明。通过学习芯片级的指令和功能,熟悉了微机原理,汇编等。使用更高级语言比如JAVA ,C#,GO ,PHP,JS的人,熟悉计算机底层指令运行原理,对于编程和调试也有好处。这个好处是,只要你写代码,脑子里都会一直有个宏观的电脑关键资源观念,就是内存和CPU都是有限的,最险恶的bug也都会最终体现到内存出错上。哪怕有GC,对object instance使用糊涂,也会导致那些极度难复现很偶发崩溃bug的出现。

2 合格coder必须掌握。 《数据结构与算法》 。这就是搬砖的基础。

3 OOP程序员生存救命书系列,C++的是《C++ primer》《C++ 语言编程》(C++之父写的)太重要了。其他语言的也一定要看国外语言发明者或者相关红宝书。

4 性能程序员生存救命书系列。程序都牵扯性能, 《Effect C++》或者effect系列太重要了。 另外所有领域,UI,逻辑,数据库,图形等等,都牵扯速度和内存的优化。针对CPU和GPU以及内存,或者IO设备优化能力越强。薪水也会越高。当然,那种代码可读性shit一样,没法与人合作的,单说。。。

5 特定平台编程救命系列。 《操作系统》,《windows核心编程》,或者经典的其他OS《xxx操作系统核心编程》系列。。。开源系统上工作,最好能找os代码解读类的图书,研究一下和自己工作相关的底层代码机理。

5 OOP码农和软工救命系列。到这里你已经是软件工程师了。。《设计模式》必看。 因为大型复杂软件工程,是由一群智力不同的程序员合作开发。你想拿更多工资,就得能够搞定更大规模的软件。这就需要你管理和协同更多人工作。要协同就得让智力不同的人一起在统一思路下发挥自己能力。设计模式就是给普罗大众智力正常的OOP程序员们统一思路用的。这也是进阶架构师必经之路。大型软件可扩展性维护性等非功能性需求都指望这个了。 过度OOD属于水平不行的。不是OOD和《设计模式》本身的问题。

5 lead programmer和tech leader救命系列。 《软件架构设计》。或者类似的国外经典书籍。 当你负责的事大到一定程度,或者5个程序以上team干活栽坑时,这类书就能救命。也是你往更高架构师,tech director进阶必经之路。

6 tech manager救命系列。 《软件工程》 。 ISO/IEC25010 。CMM 规范。 如果哪个稍具规模公司技术管理者不熟悉ISO 25010 和CMM, 建议CEO直接找他聊聊。或者开掉。在我而言不重视非功能需求,和软件成熟度的技术管理者做的产品,必然垃圾。他的技术团队必然垃圾。他的公司技术人才培训和发展,必然垃圾。重视了况且也可能垃圾,不重视就必然垃圾。
至少tech manager要根据自己公司情况,把前面提到的相关信息,放入自己开发流程中。保障软件质量和团队能力发展。

7 架构师救命系列。 《软件需求分析》或者OOA相关书籍。 不具备基础软件需求分析能力的人,千万不要制定软件功能。甭管你是CEO还是CTO 。。。 除了耽误时间人力和钱,什么作用也没有。需求分析也包括功能和非功能两大类。 to c 和to b 软件是一样的。都需要细致周详的需求分析。哪怕是迭代式。

8 tech director救命系列。 找敏捷开发的书参考一下。我那个时代的极限编程之类不合时宜。但敏捷开发思路目前已经很成熟了。 野生tech director往往在工程方法论上都是用自己过去当码农的经验,胡拍脑袋。让自己训练有素必须加强敏捷软工方法论实践。

以上书籍不一定全。但也不需要齐全。你需要注意的就是把自己所工作领域的三个层次都打扎实。35岁之后才不慌。 想从coder一路升到tech director。 那些是至少要掌握的。要求已经很低了。 我在38岁之前的编程能力和精力,不觉着比25的差。虽然每个人的脑力不同。但从国外看,40多依然从事技术工作或者技术管理工作,是个很正常的事。尤其是技术管理,格外需要具备海量开发经验同时又有软工管理经验的人。

还有点信息在这里:https://www.zhihu.com/question/304624564/answer/2328694728

展开阅读全文
加载中
点击加入讨论🔥(10) 发布并加入讨论🔥
10 评论
72 收藏
3
分享
AI总结
返回顶部
顶部