程序猿生存定律这系列的文件夹在这里:程序猿生存定律--文件夹

喜欢从头瞄的。能够移步。

-------------------------------------------------------------------------------

一个程序猿在考虑增值时无法回避的一个根本问题是究竟是做技术还是做管理。当然也有些职位会介于两者之间比方架构师。但我们临时不去做细分,而是用简单的二分法。

这样的基本方向上的选择对兴许非常多细节上的取舍有关键影响,所以在考虑其它之前,最好先回答一下这个问题。

这就和修炼时要选择少林、武当、华山还是魔教一样,一旦选择,基本上是回不了头。

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

技术与管理的关键差异

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

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

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

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

管理者往往须要处理很多与人相关的事情。这导致要处理的事情是碎片化的,假设坚持编码,那么每天的打断往往会大幅减少写代码的效能。大家都知道编码是须要专注的。

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

我们非常难让这些事情依照自己的节奏发生。假设管理人员做编程,终于这些都会变成一种对编程工作的随机性干扰。

所以一般来讲非常难把它们非常好的与编码结合在一起。

想象一下。一个管理人员负责某个项目中影响关键路径的某个模块。接下来上面所列的意外发生了。那这个管理者怎么办?

唱歌的时候常说到Key或者调门这个词。

相同是《花心》这首歌,周华健的用的Key和原本的冲绳民谣《花》的就不同,这导致两首歌听起来区别就非常大,全然不一个感觉。或许能够说管理也是一种技术。但管理和设计编码这样的技术的Key不一样。做技术须要面对的是程序,程序是讲道理的,Stack Overflow时它一定会崩溃;而做管理时须要考虑技术因素,但更须要面对的是各种人。人则仅仅在一定程度上讲道理,所以管理不仅仅是一种技术。因此基本上能够觉得管理和技术时全然不同的两个方向。

假设大家细心观察周围,就会发现,做技术(编码)的往往能够转去做管理,但做管理的再转回做技术(编码)就难了。这意味着技术背景对做管理往是非常有帮助的,而管理背景对做技术则差点儿没用。

了解到这样的差异后,要想做出自己的那份选择,还须要考虑三件事情:一是既定环境下技术路径究竟有多长,也就是说做技术有前途么;一是个人的性格适不适合做管理工作。一是做管理工作可能会有什么负面影响。这三点将在接下来的三个小节中分别进行探讨。

技术路径长短对前途的影响

程序猿往往自嘲自己是“码农”,不知道这词是那里出来的,但听起来“码农”和“农民工”已经有点近似了。

而“农民工”往往是收入低,工作时间长的代名词。这就折射出了一个非常尴尬的事实,在非常多公司中。单纯从收入的角度来看管理职位是要高于纯粹的技术岗位的。

这并不是是一个绝对规则,前文就以前提到早在20年前。微软的超级程序猿就能够拥有比管理人员更高的工资,能够拥有多辆保时捷。但在技术路径短的公司里,管理人员收入偏高这事情却具有必定性。

当一个公司的核心技术并没有创生多大价值,而是须要靠人力规模、商业模式等来支撑业务的时候。那么我们能够称之为技术路径短的公司。想象一下,假设一家公司专门承接本地化工作。那么或许也会须要程序猿编制某些工具,但对程序猿而言技术路径无疑是短的。

假设临时把眼光从程序的世界移开。那么事情就能够看得更清楚。

在盖楼的时候,仅仅要达到主要的质量,一个人每天砌200块砖,固然比砌100块要好的多。但相对于大楼而言,多砌100块砖,所多带来的价值有限。再进一步由于砌每块砖的价值是固定的,同一时候一个人每天所能砌的砖也是有限度的,这就会导致砌砖工人。无论多么努力,其收入水平必定会被限制到某一个较低的水平。仅仅要他的工作还仅仅是砌砖。这样的限度是由这一工作的内涵所决定的,倒不是谁遭到了鄙视。

再类比到软件行业里,单纯的在既定接口下实现已定义的业务逻辑就是技术路径比較短的工作,是体力密集型的;而分析业务逻辑,控制总体架构或者去研究TTS的算法则是智力密集型的,技术路径较长。

在选择方向时关键要避免的是选择了技术方向,但身处的现实中技术方向却路径较短,或者喜欢管理但跑到了纯粹技术流的公司里,这样的选择其内部所蕴含的矛盾会给当事人的人生造成极大的困扰。比方说开发小型信息管理系统时。其所须要的技术含量并不高。公司的主营假设是这个。单纯的做技术可能会直接影响收入。这是一个须要考虑的非常现实的事情。

什么样的程序猿适合转管理

《黑客帝国》的动画片中有一集叫做“Matriculated”,在这一集里有个机器人被逮住后,人类通过各种场景让他相信自己是个人类。计划看似成功了,但实际却不是。这个动画的启发意义在于。先天带来的非常多东西。比方性格等实在非常难改变,很多其它时候选择顺应自己的天性比选择对抗更加明智。

从先天性格来看,确实有的人天生适合做管理多一点,有的人天生适合做技术多一点。

比方说:

有的程序猿天生有点被动,不喜欢主动学习非常多东西,不喜欢与人沟通。但对工作所直接关联的领域研究较深。做事情兢兢业业,一丝不苟。

有的程序猿非常聪明,理解东西非常快,但不愿意搭理别人,总感觉别人水平比較差,脾气也比較暴躁。

有的程序猿精力充沛。对技术狂热。但并不仅局限于技术本身,有大局观,有理想,能坚持。

单从性格而论前两者都不太适合做管理工作的,一旦做了管理工作,接触各种性格的人,easy造成人际关系紧张,反倒对自己形成一定的压力。极端情形下就会精神失常。

单纯的由于收入而选择管理工作,并不总是明智的。你可能无法适应,反倒导致事业出现起伏---不要低估这点的影响。现实中非常多的人由于这样的错位而使人生走入低谷,甚至生病。

在大五模型里用五个因素来考察人格特质:

外倾性(extroversion):

外倾者者倾向于喜欢群居。善于社交和自我决断。内倾者则比較内向。胆小害羞,安静少语。

随和性(agreeableness):

高随和性的人是合作的,热情的和信赖他人的,低随和性的人是冷淡的,敌对的和不受欢迎的。

责任心(conscientiousness):

高责任心的人是负责的,有条不紊的。值得信赖的,持之以恒的。低责任心的人则easy精力分散。缺乏规划性,且不可信赖。

情绪稳定性(emotional stability):

积极的情绪稳定性者倾向于平和,自信;而消极情绪稳定性者(神经质的人)倾向于紧张,焦虑。失望和缺乏安全感。

经验开放性(Openness to experience):

开放性高的人富有创造性,凡事好奇,具有艺术的敏感性;开放性低的人则保守对熟悉的事物感到舒适和满足。

总的来看,外倾性和经验开放性好的人更适合走上管理岗位。

千万不要忽视这样的错位的力量。金山的求伯君先生就直承自己不擅长做管理。他觉得人的一生之中最关键的是对自己能够有所了解。不是说自己什么都能干,是万能的。在雷军走后的4年里,做CEO有些力不从心,快50岁的他精神压力太大。多次想退休,请雷军出山。终于求伯君先生在不到50岁的时候退出江湖,不知道是不是和这个有关。

当然非常多人可能远走不到求伯君先生的高度。但终究相似,能够打个比方形容错位的中层管理者。上司和下属员工像两块板子。管理这门功夫没练好的话。中层管理者就被搓球了:上司说,你做的这叫什么事儿,脑子大大的坏了。下属说:你瞎答应什么,这事儿怎么做,我不干。要干你自己干,爱咋咋地。

管理这功夫练好了。情形就变了:上司尊重你的意见。下属把你视为旗帜。

一处天堂,一处地狱,核心区别事实上不大,根本还在天生的人格特质。待管理人群的特质也非常有影响,但这是运气所管理的范畴。

是不是适合做管理者的简明推断方法

假设说团队里两个兄弟吵起来来了,你愿不愿意去调解?

假如有一个人脾气非常坏你愿不愿意和他沟通,即使你不喜欢?

假如有一个人问题非常多,你愿不愿意面对面批评他?

假如有一个人屡教不改,你愿不愿意採取直接的惩处措施,那怕关系紧张?

这个列表还能够增长。一旦做管理工作。这类须要抛开个人视角,而从组织的视角去看待问题并行动的地方非常多。

假设对这类问题的回答是否定的,那么最好是不要往管理的方向上走。

上面这几个问题,纯走技术道路的还能够作壁上观。但假设是发生在自己团队里,管理者却保持逃避的态度,那么管理者就失职了。

由于人的世界非常复杂,所以期望坏的事情一件也不发生,那是不现实的。我个人感觉管理者面对这类事情的几率是100%,区别是遇到多少件,而不是遇不遇得到。

事实上故事到这里还没完。假设往深了考察,就会发现,即使一个人愿意去搞定吵架中的两个人,那还有你怎么去搞定,搞不搞得定的问题。

捣糨糊、各打五十大板这类简单粗暴的方法往往仅仅能有效于一时,等价于埋下定时炸弹。长线来看不是什么高明方法。但把这个展开就须要另外一本书,这里就不进行展开了。

管理工作的负效应

从日常非常多人发表的言论来看,管理工作似乎被无限美化了,非常多人都觉得管理工作似乎是一条彻底金光大道。但这并不全然正确。为了让事情回归本来面目。这里说一点管理方所可能带来的负效应。

同纯技术工作相比,管理工作(特别是中层管理)的可流动性可能会非常低,形象来讲非常多公司并不会愿意请外来的中层管理者来管理已有的员工,而更愿意请技术上有专长的人来解决详细的问题。

这是由管理工作的几个特质所决定的:

管理工作和人打交道比較多。所以对人员的特质有非常强的依赖性。假设一个团队的人都非常像机器人,那么在不同公司间管理技能是全然通用的---仅仅要有PMP。CMMI这类东西就够了。

但关键问题是人员的特性是多样的,这导致管理人员和被管理人员须要较多的磨合和适应。

形象点讲就是。假设无法搞定特定人群,你考5个PMP证书,该无论用还是无论用。

同一时候长时间在管理岗位的话。即使是做技术出身,技术能力也会退化,沟通技能、与上级的信任程度反倒会提高。而这些东西。到一家新公司后,一定会被归零,,其价值并不明显。反倒不如擅长算法。擅长某类业务的技术人员可流动性好。

这也就意味着。管理人员往往与公司的利益绑定的更紧。尤其是中层管理人员。达到一定年纪后(比方:40岁),非常可能会失去流动的可能性,一旦所处的公司出现故障,那就可能会面临非常尴尬的局面---直接讲就是,假设你选择了管理方向,却缺乏对应的人脉,35岁之后基本不具备可流动性,换工作会非常难,至少比纯技术的高端人员难。

这点的一个旁证是各个初创期公司的人员构成。假设你用心观察就会发现对于初创期的公司而言,它须要创始人把握方向和寻找资金,也须要project师来完毕详细事务,但不太须要中层管理人员。比方:Pinterest以前公开了自己的数据。在2010年是2个创始人。1个project师;2011是3个project师;2012年是6个project师;2013年是40个project师。

这样的情况下,仅仅有到2013年后中层管理人员才有存在价值,而一般情形而言这样的情况并不会社招,而是会从现有人员中选拔。

这终于导致纯管理人员的可流动性并没有想的那么好。

当然什么事情都有例外,假设你是成功运作几个产品的产品经理,那么也可不在流动性上受到限制。由于那些产品就是你最好的名片,他们使你在江湖里有了一席之地。

小结

考虑上述三个方面,大多时候能够判明自己是应该做技术还是做管理。比方说:假设一个人日常非常easy和人产生冲突。但脑子非常好使。也能静下心来钻研技术。这样的情形大致上应该努力找一家技术路径长的公司做技术。否则可能会人际关系紧张。而与此相反。一个人假设技术能做的还不错,也愿意与人沟通,同一时候已经身处一家技术路径不是非常长的公司,并不太能够换工作,那么就非常可能须要尽早转向管理方向。

总之。别太为了点钱过度难为自己。走不远的话,终于还是吃亏。

------------------------------------------------------------------------------

关于我自己的各种信息。在左边栏可找到,想了解下写这书的人是不是骗子和大忽悠的能够瞄。

最后希望感兴趣的支持V众投,感觉上这应该是国内最靠谱的生活购物等的问答社区了吧,都是朋友给朋友做的答案,同一时候实行一人一号。一人一票制度,想找什么答案关注公众号:vzhongtou(左側有二维码)即可了。

版权声明:本文博客原创文章,博客,未经同意,不得转载。

法猿生存计划--左边的管理,技术正确相关推荐

  1. 法猿生存计划-在大选前,该公司希望做一些事情:分类

    程序猿生存定律这系列的文件夹在这里:程序猿生存定律--文件夹 喜欢从头瞄的,能够移步. -------------------------------------------------------- ...

  2. PERT网络分析法(计划评估和审查技术,Program Evaluation and Review Technique)

    PERT网络分析法 PERT网络分析法(计划评估和审查技术,Program Evaluation and Review Technique) 目录 [隐藏] 1 什么是PERT网络分析? 2 PERT ...

  3. 程序猿生存定律-六个程序猿的故事(2)

    程序猿生存定律这系列的文件夹在这里:程序猿生存定律--文件夹 喜欢从头瞄的,能够移步. -------------------------------------------------------- ...

  4. 程序猿生存定律--表达背后的力量(1)

    程序猿生存定律这系列的文件夹在这里:程序猿生存定律--文件夹 喜欢从头瞄的,能够移步. -------------------------------------------------------- ...

  5. 程序猿的十年—新猿农计划

    目录 引言 实习 技术 软件 设计 产品 管理 改变 创新 社会 文化 持续 探索 回顾 分享 引言 新猿农计划,讲述的本人作为普通农村家庭大学毕业在IT行业中奔波磨炼的历程:从职场小白到职场老鸟的经 ...

  6. 红帽计划收购API管理领导者3scale

    2016年7月5日,世界领先的开源解决方案供应商红帽公司日前宣布,公司已经签署一项关于收购应用编程接口 (API) 管理技术的领先提供商3scale的最终协议.通过将3scale加入到现有产品组合中, ...

  7. 笔记-项目质量管理-编制质量管理计划的工具与技术

    制定项目质量计划是识别和确定必要的作业过程.配置所需的人力和物力资源,以确保达到预期质量目标所进行的周密考虑和统筹安排的过程. 项目经理在编制项目质量计划时,希望通过相应的方法来明确质量标准及达到标准 ...

  8. 深度 | 面向云原生数据湖的元数据管理技术解析

    简介: 作者:沐远.明惠 背景 数据湖当前在国内外是比较热的方案,MarketsandMarkets市场调研显示预计数据湖市场规模在2024年会从2019年的79亿美金增长到201亿美金.一些企业已经 ...

  9. Linux内存管理:一个故事看懂CPU内存管理技术

    目录 8086 32位时代 虚拟内存 分页交换 现在 往期热门回顾 推荐阅读 还记得我吗,我是阿Q,CPU一号车间的那个阿Q. 今天忙里偷闲,来到厂里地址翻译部门转转,负责这项工作的小黑正忙得满头大汗 ...

最新文章

  1. python ui bs_Guibs的Python学习_列表
  2. php比较函数代码,php字符串比较函数
  3. 查拉斯图拉的“没落”
  4. 下了Bandit,看了一个礼拜
  5. Windows环境安装Tomcat
  6. aspx隐藏前台控件div_javascript总结--div
  7. VS集成Qt开发入门(简易时间显示)
  8. SpringCloud与SpringConfig分布式配置中心
  9. 我的.NET开发环境设置
  10. 小车启动预热是原地预热,还是慢慢开动预热,哪种方式比较好?
  11. Web Service工作原理及实例
  12. Tomcat 7.X安装教程(简单易懂)
  13. VSCode 常用编程字体
  14. 解决macOS Big Sur升级后部分java应用无法打开的问题JavaVM: Failed to load JVM: libserver.dylib
  15. 联想7400打印机如何与手机连到一起_2020年打印机推荐选购,看这篇就够了
  16. Chrome浏览器更新失败
  17. 我对技术的态度是什么样的?
  18. 使用EasyExcel实现excel导出,支持百万大数据量导出-----超简单
  19. Qt-源码部分编译-C++
  20. android实时监控屏幕代码,Android 屏幕切换监听的实例代码

热门文章

  1. cesium 设置时间_Cesium之地形制作与合并
  2. 计算机基础知识易错,事业单位考试计算机基础知识易错试题.doc
  3. 怎样快速学习html5,如何快速学习HTML5?带你了解HTML5学什么?
  4. python出现套接字创建不成功_python套接字协议不支持 - python
  5. 并行机调度问题matlab,顺序依赖并行机调度问题介绍
  6. java 判断网络类型_Android 网络类型判断(2g、3g、wifi)及IP地址获取
  7. IC基础知识(1)集成电路(IC)简介
  8. 【 MATLAB 】ndgrid 和 meshgrid 对比理解以及应用
  9. Linux学习 - 目录的权限操作
  10. SpringMVC传递multiple类型select后台Controller的接收方法