我介绍下对他人有用的信息。我靠技术创业上岸。技术是我的能力基础。但取得的技术结果和商业结果，有着更广泛复杂的元素。比如运气至少占60% 。
我在文章最后会介绍自己在技术探索路上，起到里程碑作用的几本读物。
对软件人才可借鉴的经验：
软件解决问题，需要三层：
| 1 理论知识 | 算法，数据结构，微机原理，操作系统，线性代数，离散数学，软件工程，以及与你工作相关领域最新的科学研究理论知识 |
| 2 技术 | 某种计算机语言熟练掌握使用经验丰富，或者某个领域钻研深入，类似图形，数据库，网络服务器，AI等等 |
| 3 工程 | 有限时间满足需求解决问题能力，与人合作开发的能力 |
第1层代表了你能够达到的上限。也就是今后技术发展的最高点。 第3层代表你的下限，决定了你35之后混得最差的底线。
知识掌握越多，越新，越有可能扩展你的技术能力，和工程能力。 也就是掌握技术比别人好，工程问题你办法比别人多。比如对算法和数据结构掌握牢固，对操作系统掌握深入，当你要做尽可能压榨性能和内存的软件，你就可以从底层功能来解决问题。至少使用一些快速的底层工具比较顺利。比如内存管理，速度优化等。宏观上，对计算机体系理解越深刻，对软件质量管理理解越到位，你带领团队能做的软件规模和质量就会超过其他公司。你就成为某个公司的不可或缺的人。工资自然就比别人多。
绝大多数程序员的天花板就是底层知识不行。现在软件中间件和工具库太发达。一直满足用傻瓜工具和代码库，挣口饭吃。这种码农和那些工地搬砖的是差不多的人。35岁之后必然被淘汰。这一层决定了你以后最好的收入会在哪里。过去我喜欢看自己领域国外最新的论文。我发现和我有同样喜好的人，后来发展的都很好，钱也多，买房也不愁。不是说看论文就能买房了。。。只不过这个样本也许有点借鉴意义。说明对理论的持续补充，会增大你视野，尤其是解决问题的视野
到了后期做技术管理，依靠的依然是底层知识+大量经验。
理论知识就是得拼命看书，看论文。还得能融会贯通。
第2层比较单纯。绝大多数年轻软件人员都在这一层。并且以数量掌握这一层技能为荣。某个语言，某个工具使用，某个图形技术。 但实际上，有了第一层的理论知识，这一层就是一个砸时间去理解，记忆和熟练使用攒经验。小学生也毫无障碍。不太建议只拼这一层能力。虽然这一层是必须的基础。
有两个要素与解决问题能力相关。第一个要素是工程能力。 这种能力是在前两层基础上建立的。比如我虽然瞎自学了好几年计算机。但毕竟有热情，比别人先耗费了大量的时间（几千小时），自然多积累了一些知识和技术。第二个要素是“对问题难度极限的感受”
拿自己举个例子：我过去小学用机器码编程。这种比汇编还底层的指令编程，直接操作计算机的硬件。比如直接操作屏幕buffer，键盘输入。条件判断指令需要自己计算偏移量。由于机器指令编程难度极大。没有任何debug工具。所有程序逻辑必须完全在纸面全部验证完成。出了问题只能想各种效率极低的方法去检测。所以更加锻炼了我用计算机指令解决问题的能力。 等于一直绑着一堆沙袋练习跳远。 同时间接地，我熟悉了微机原理，软件与硬件的关系，还有汇编语言。这种熟悉对于后来做C++开发高性能图形引擎，有极大帮助。别人碰到难复现bug束手无策，很多时候看汇编和寄存器情况就能大致猜出个1成到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多依然从事技术工作或者技术管理工作，是个很正常的事。尤其是技术管理，格外需要具备海量开发经验同时又有软工管理经验的人。
from:https://zhuanlan.zhihu.com/p/498762187