Foreword
程序员总会遇到这样的问题，走技术道路还是管理道路？以前也有亲戚或者爸妈同事的孩子（计算机出身）想问问我以后的路要怎么走，以我个人经历来谈一谈
技术成长
少年时代
接触程序比较早，属于是初三、高一的时候就已经在写程序了，只是那会是玩按键精灵，VB语法，大漠插件，那会觉得会一个语言好厉害，C++好牛，C、C++、VB都学了，写点我自己想要的自动化程序已经是没啥难度的了。
- VB实现的复杂脚本已经是大几千行代码了，业务也很复杂
在那个年代，搜索引擎还是很好用的，想要啥就能搜到啥，没有那么多废话。但是在外挂这个偏门领域，想要再进一步有点困难了，当年感觉Windows的Hook简直就是天神下凡，有啥你想要，但是现有的库或者接口做不到的，Hook都可以做到，各种奇巧淫记。但是这东西只是偏门，而且用起来恶心，很多东西没有明文说明，都是摸索出来的经验，现在想想那会还真是糊里糊涂的在写代码，拿着一堆没搞明白干啥用的东西，底层逻辑也不清晰的就糊上去了。
至于当时的面向对象、面向过程，对象是没搞明白，但是过程可太熟悉了，做了无数个过程代码，多少算是锻炼了年少时的逻辑思维能力吧。当年的计算机二级，辅导过各种大学生，想来也挺搞笑的，初中生辅导大学生。
高中时第一次知道了物联网，感觉这个概念可太牛了，那会大概是10、11年，那会估计物联网专业的都不知道他们的物联网能干啥，那会我已经自己想通了电视、冰箱、洗衣机等等家电联网的逻辑，想想那会可真是领先了一大批人。
学生时代
大学专业也毫不犹豫的选了和计算机相关的专业，以我当时的自信吊打一下大二大三应该也不是问题，计算机的课大部分不上我也知道咋回事，课本都自己看，自己学了。老师讲的不一定有用，但是我自己看过的内容后来都被我用上了，很多我能发现或者意识到的问题，都是基于过往的积累，如果当时没有看过，工作的时候就完全不会想起来这个内容
但是也有一个方面发现落后了别人好多，校内的算法比赛，第一次看到题懵逼了，这是啥？后来比完看到差距以后，才明白别人从高中就开始在信息竞赛里天天训练的脑子还是真牛，自此以后再也没参加过算法相关比赛了。
刚开始还记得初心是做物联网，买了些开发板，学习了嵌入式相关的知识，学完以后觉得可牛逼了，没啥智能家居我做不出来了，那会也确实如此，很多智能家居的东西还是非常简单的，看一眼就知道用啥模块可以实现了，但是对于整个物联网生态还缺少体系化的思考，也没意识到这个东西后续是个万亿级别的市场，在当年还是非常有机会的。
后来参加电赛，接触到四旋翼，从那会开始就走偏了，忘记了物联网的初心，去搞飞机相关的内容了，当年四旋翼也没多少人搞，很多东西都没有，那会也不太会翻墙，少了一整个Google和GitHub，那会已经可以组起来一个较大的嵌入式工程了，软硬都了解，想做啥基本都可以做了。
同时也走了一些弯路，当时弄了一些Window phone的C#开发，后续这个东西停了，就废了，Web那会还不认识Spring，傻傻的拿Html写前端，真的有点坑到当年的队友了。
学生时代技术已经十分发散了，C为主，C#、C++为辅，后来又自学了python，基本上主力语言都摸了一遍，不看语法，大部分语言都能直接看懂了，接触过的技术栈也非常杂：嵌入式、.NetFramework、MFC、HTML、Windows Phone、Unity3D、Latex
好在那会补全了我的一些知识体系，至少从底层、编译、操作系统、应用、UI，由下到上这么一系列东西让我体验过了一遍。大三后期又上了很多软件工程的课（当年上的时候已经被淘汰了），但是作为一个工程学，他的核心思想竟然后续都被我吸收了，这是我没想到的，也没想到这个简单的工程思想竟然在实际工作中遇不到有人会，真的挺离谱的，软件工程也成为了我后续发展的主要考虑对象
工作时代
等到了工作时，算是对我自己的专业知识、以前漏掉的一些知识内容重新查漏补缺，再次巩固我自己的专业度，深究每一段代码的含义，彻底拿下一方面的技术。在这个基础上，又往其他方向扩展了一下，算法方面，多年没有深究，再次接触，系统学习了一些算法知识（本质上是数学，图论），捡起来以前离散数学，发现很多问题迎刃而解了，有了更优的解，解了很多实际中的问题。
在唱衰互联网的时候，又学习了一下Springboot整个前后端相关的知识内容，又做了一个实际项目，对于整个网络端业务体系，算是有了一个深入了解，后续再做联网相关内容的时候就能考虑的更完善了，不再对我是黑盒了。
- 现在想想，这部分内容如果是学生时代学习的，物联网的概念说不定就能串起来了
到这里基本上我算是从底层到上层，整条数据链路都打通了，技术栈相对完整了，所有内容我一个人都能做了
总结
纯语言、纯某个技术栈，有上限吗？有，也没有，要挖深，可以无限往下弄，但是工作、业务真的需要吗？普通人有可能涉及物理或者数学的理论基础吗？不行的，多数情况下，你所做的业务能完成工程化就已经非常好了，足以吊打很多野路子了。
当纯技术我发现没有更多突破的时候，我开始转向技术的周边，比如整个编译架构，CI/CD，比如整个工程从需求到落地需要经历的每一个环节是不是还能做得更好，自动化，工程迭代能否用更少的人力，更小的改动，达成更大的目的？整体架构对于业务支撑是否拥有足够的包容度和扩展性，能否轻松改几行代码或者复制粘贴几个文件就能达成一个新硬件支持？我开始深究从第一行代码到业务覆盖，是否能给出一套方法论或者工程指导，让我或者其他人达成一个高效的迭代开发体系。这些想法我都先用在了我自己的代码、工程中，我自己验证每一步是否可行，是否高效，当我验证完，就把这一套推广给其他人了，大家使用一套类似的方法论，甚至可以对此进行二次优化，逐步做得更好。
从技术转向工程，算是完成了第一次转型。
技术？管理？
然而每个人的精力是有限的，我总不能什么都管，有了工程体系，我就可以考虑逐步把手上的技术交给其他人去做，只要工程体系没有大问题，那么随着需求迭代开发就没问题。
手上技术拿的越多，技术越广，最后都要面临把一个个单项技术分出去，分的越多，最后手上剩下的越少？就约专注？好像也不是。刚开始是不断捡起，但是随着东西越来越多，开始学会放下，学会交付给别人，否则一定是分身乏术的。而随着手上的东西越来越少，也就有时间去思考超过技术、工程本身的东西，从更高的角度去看问题，去审视每个人所在的位置，每次遇到的问题根源是什么，此时开始偏向管理，工程转向管理，第二次转型。
纯技术工作对于我已经没有挑战了，转型管理也是必然，管理本质上还是为了业务和人员服务，如何让大家更好的工作、业务更好的开展罢了。
当然并不是每个人都要这么做，每个技术都有各自所在业务的深度，有的技术是需要不断突破，不断创新的，这种持续做技术完全没问题。而有的技术，当你做到一定程度，可以拿下整个技术栈的时候，你是选择躺平了呢，还是继续寻找突破点？因人而异吧
技术与产品
技术本身与业务是不分家的，如果纯纯只做技术，不了解业务，只能说你技术肯定做的不行，好的技术一定是非常了解业务的。当技术搞定时，此时还有一个角度可以玩，那就是去做业务：产品经理，这种类型的产品拥有无与伦比的优势，天生了解技术细节，能跳出技术本身，看到业务的矛盾点和方向，可以让产品发展得更好，让需求少反复几次，让技术实现少走弯路。
我在做管理的同时就发现了，很多问题可能不是技术的问题，不是工程的问题，他可能是产品的问题，整个产品的定义或者细节中漏了一些东西，甚至产品本身就是定义不全的，而这些东西对于落地非常关键，一旦被模糊了，那么就会导致落地时有问题，在落地阶段反复修改之前的功能或者定义，与之对应的，我又做了第三次转型，同时兼管产品，确保产品实现的效果是我想要的，每个细节都有具体的定义，不再模糊放过问题，这些都会导致后期再进行维护时带来很多其他问题
以前觉得别人说代码设计，要瞻前顾后，写个类，写那么多冗余、抽象的东西，毫无意义。但是今天当你站在实际业务前，看到业务里各种前后兼容的丑陋设计时，就会感觉到，前期留下的冗余代码在此时是多么的细节，但是这种能力不是每个人在当时都能看到，都能做到的，只能说在后期一次次重构的时候会多想一想业务，把代码平台本身的扩展性设计得更大，代码包容性更强，那么业务的变动都在代码考虑之内就毫无难度。
经验教训
对业务不够了解，不应该去做重构或者是创新，这样的玩法只会浪费时间，凭空做了很多没有价值的创新和重构，特别是新人刚加入项目。
做协议，必须对上下层都懂，否则只会以偏概全，最后做出来的结果别人不愿意用，最后不了了之
培养一个资深测试，特别是对于业务无比了解的测试，价值远大于一个产品和技术
不要让拿不下业务的产品进行需求开发，只会把产品带偏
超过半小时的会议，会议内容一定过于发散了，要尽量缩短会议时间，快速沟通矛盾点，没问题的地方直接跳过，不要废话
方法论
以自己当前的经验，总结一套方法论，其实就是对于业务开发的方法论，希望新人也好，还是有经验的人也好，可以从这里学习，知道自己在什么位置，应该做什么，有经验的人可以帮助完善这一整套体系。
- 不一定是方法论，也可以是模板，或者什么其他名词，总而言之可以让大家按部就班的完成一整套新产品的设计和实现
以目前我的角度来看，无论大、小公司都有一套自己的方法论，这套方法论被反复在内部的产品上验证，它可能不是100%会成功，但是成功的概率是远大于一帮乌合之众的凑到一起做出来的。
从我的角度，不一定要模仿谁的方法论，每个公司或者项目都可以走出自己的路，很多东西是要结合当下的情况来定的，很多别人的经验没办法直接搬过来用，更多的是借鉴学习别人的解决问题或者矛盾的方式方法，并不是抛弃自己来时路，抛弃自己曾经用过的方法。
Summary
一些粗浅的想法