三十而立，作为程序员的我，该转型吗？技术or管理-CFANZ编程社区

一个程序员在考虑增值时无法回避的一个根本问题是到底是做技术还是做管理(架构师除外)。这种基本方向上的选择对后续很多细节上的取舍有关键影响，所以在考虑其他之前，最好先回答一下这个问题。这就和修炼时要选择少林、武当、华山还是魔教一样，一旦选择，基本上是回不了头。

当然选择管理不意味着不需要掌握编程技能，毕竟当下大多公司还是信奉“宰相拔于州郡，将军起于行伍”的。但当技术达到一定水平后，管理还是技术这种方向性的选择将对下一步做什么有比较大的影响。在考虑那个方向前，则要先弄清楚管理和技术的关键差异。

技术与管理的关键差异

到了30几岁后，转为管理人员的程序员经常会调侃自己的技术能力：当年解决这种有时出、有时不出的Bug时，我常常在其前后都加几条调试输出，这招很管用很可能立刻就把它搞定了。结果多年后维护这代码的人困惑了，还来问我，这句为啥不能去掉，看着也没用啊，其实我也不知道，只能说运气和人品在程序里也是很有影响力的。

这是管理人员的一种真实写照，大家都知道，一旦走上管理岗位，那就和ppt越走越近，和代码越走越远了。虽然他仍然要跟踪最新技术的动向，但他很可能已经无法深究很多技术细节了。

据说微软这样的公司推崇一个人要想走上管理岗位，那要先把自己的代码用远少于别人的时间写好，省下来的时间才用来做管理工作。这很好，也不是完全不可能，但大多时候很难，需要很强大的天分，大多数人是做不到的。

要原因是管理和技术所要处理的问题有根本上的差异。

管理者往往需要处理许多与人相关的事情，这导致要处理的事情是碎片化的，如果坚持编码，那么每天的打断往往会大幅降低写代码的效能，大家都知道编码是需要专注的。

管理工作总是需要面对大量的琐碎工作的，比如：老板对项目不满要赶紧去说明，免得发酵成大问题;人力缺了要赶紧协调，一是要能要到人，关键还得能要到合适的人;工具缺了，要赶紧购买;兄弟们有情绪了，要赶紧安抚;PPQA了有抱怨了，要赶紧改正。如果工作进一步泛化，还要涉及到预算、评估、职业路径规划等。

我们很难让这些事情按照自己的节奏发生，如果管理人员做编程，最终这些都会变成一种对编程工作的随机性干扰。所以一般来讲很难把它们很好的与编码结合在一起。想象一下，一个管理人员负责某个项目中影响关键路径的某个模块，接下来上面所列的意外发生了，那这个管理者怎么办?

也许可以说管理也是一种技术，但管理和设计编码这种技术的Key不一样。做技术需要面对的是程序，程序是讲道理的，StackOverflow时它一定会崩溃;而做管理时需要考虑技术因素，但更需要面对的是各种人，人则只在一定程度上讲道理，所以管理不只是一种技术。因此基本上可以认为管理和技术时完全不同的两个方向。

如果大家细心观察周围，就会发现，做技术(编码)的往往可以转去做管理，但做管理的再转回做技术(编码)就难了。这意味着技术背景对做管理往是很有帮助的，而管理背景对做技术则几乎没用。