程序员好升职务吗（程序员应该怎么升职）
程序员好升职务吗（程序员应该怎么升职）自知之明还体现在，干这一行的过程中，详细了解自己的各项技能的长短，扬长补短。程序猿不是简单会敲代码就行，构思、设计、编码、测试、调试，往往编码只占很小的比例。而且程序猿这一行范围又极广，底层驱动、操作系统、协议栈、前端、服务器、APP、数据库、大数据、分布式、系统集成。怎么选择，怎样能够发挥优势，真的应该好好想想。最想说的是，弄清楚你到底适不适合干程序猿这一行，我多年的经验总结下来，优秀的程序猿都有如下的性格特质（或部分）：细心严谨、细节强迫症、完美主义、做事情有条理、耐得住寂寞、喜欢跟机器跟代码打交道（相比跟人打交道）、口才一般不佳、容易偏激或钻牛角尖、人情世故方面稍显笨拙。任何成功背后，都有不为人知的苦闷和寂寞。程序猿的苦逼之处，就在于别人高谈阔论指点江山的时候，别人推杯换盏觥筹交错的时候，别人出差南北纵横内外的时候，别人利用工作之便撩妹泡妞啪啪啪的时候，你只有面对屏幕，把键盘敲的啪啪
一路从 初级程序猿（半年） - 项目主力（一年） - 初级技术管理（一年） - 中级技术管理（两年） - 部门管理（两年） - 高层管理（三年） - 职业经理人，一条路走过来，关于升职，有一些自己的心得可以分享。
大四开始找工作的时候，我正在上一门可视化编程的课，大概就是用VC编写出可以绘图、简单动画和播放多媒体文件等各种操作的程序。基于这门课，我编写了贪吃蛇、俄罗斯方块等各种游戏。另外的一段编程经历是大二时候的Java大作业，编了一个很弱的图片管理器。实际上，这些程序都非常弱智，那时候的我算法极差，代码规范性极差，甚至于对SDK或库函数的掌握也极差，是个地地道道的菜鸟，但这并不妨碍我喜欢编程。我发现，当我坐在电脑前敲代码，或者对着千疮百孔的程序不断调试，打断点，加入调试代码，单步执行查看内存变化的时候，我是乐在其中的，甚至于忘了时间。所以，面临工作方向选择的时候，我毫不犹豫选了coding。
于是，当07年我在缺少指导，对Linux不甚了解，对路由器也一知半解的情况下，开始开发国内厂商的第一代11N路由器的时候，倾注了大量的精力阅读《LDD3》，搞定交换芯片驱动；大段大段的啃Linux Kernel源码，搞定netfilter/iptables；阅读《UNIX环境高级编程》，搞定各种同步互斥进程线程；阅读网上的各种技术博客，包括把竞争对手的GPL代码Down下来仔细阅读。。。一年里加班无数，五一十一也都是在加班中度过，一年下来基本上搞定了领导交给我的艰难任务。然后又用一两个月的时间，把产品上市后爆出来的各种Bug一一解决，最终赢回了市场口碑。
如果没有这种热爱，你就无法在日复一日的coding中保持专注，更不用说脱颖而出。
任何成功背后，都有不为人知的苦闷和寂寞。程序猿的苦逼之处，就在于别人高谈阔论指点江山的时候，别人推杯换盏觥筹交错的时候，别人出差南北纵横内外的时候，别人利用工作之便撩妹泡妞啪啪啪的时候，你只有面对屏幕，把键盘敲的啪啪啪。如果你忍受不了这种寂寞，体会不到其中的乐趣，请尽早换行。程序猿的高潮，来自于屏幕上排版良好的指令，按照你的意志精确执行，并且分毫不差。
2. Know yourself 贵有自知之明，了解自己自知之明这个词，说的容易，做起来特别难。但又特别重要。
以前我团队里有个小伙，非常非常内向，话没说几句就脸红，后来程序猿不干了要去做展会，学跟人打交道，说是要挑战自己。我不知道他后来怎么样，估计结果不太好。人的性格在十几岁的时候基本就定性了，二十几岁的人再想彻底改变自己，极难，有这个毅力，估计什么都能做好了。
最想说的是，弄清楚你到底适不适合干程序猿这一行，我多年的经验总结下来，优秀的程序猿都有如下的性格特质（或部分）：细心严谨、细节强迫症、完美主义、做事情有条理、耐得住寂寞、喜欢跟机器跟代码打交道（相比跟人打交道）、口才一般不佳、容易偏激或钻牛角尖、人情世故方面稍显笨拙。
自知之明还体现在，干这一行的过程中，详细了解自己的各项技能的长短，扬长补短。程序猿不是简单会敲代码就行，构思、设计、编码、测试、调试，往往编码只占很小的比例。而且程序猿这一行范围又极广，底层驱动、操作系统、协议栈、前端、服务器、APP、数据库、大数据、分布式、系统集成。怎么选择，怎样能够发挥优势，真的应该好好想想。
职业生涯规划里面，知己知彼是非常非常重要的，知己，即是了解自我的个性、特点、优劣势、需求；知彼，即是了解行业、企业、团队、职位的情况和要求。
3. Be reliable 可靠，说到做到，做好本职作为程序猿，最基本要求是：代码可读性好、功能正常没有明显bug。
我见过太多这行里的毛头小伙，数字常量到处埋，函数命名用拼音，if else 十层八层嵌套，匈牙利命名法和Linux命名法混杂，代码像挤在一张皱了的纸上，零注释或写完代码补注释，异常处理缺失，还有基本功能一用就崩溃，还辩解说，在我那里是好的呀。遇到这一类人，通常我在心里先给打个D等（ABCD），日后恐难以翻身。
还有稍微进阶一点的毛病，说这个功能包我身上没问题，又或者一周之内绝对给你搞定，领导你放心。最后拿出来的代码不是错漏百出，就是规定时间根本完不成，而且到deadline前你询问他的时候才告诉你搞不定。。。项目组里有这样的人，要么得配一个给他擦屁股的，要么得配一个项目助理时刻监督他，换一句话说，他的贡献值其实为负。
程序猿要想进阶，其实什么设计模式、架构、高深算法、莫测技术都不重要，这些都只是术，或者说套路。最核心的应该是，把简单的任务完成好，之后再完成更难一点的任务，这样你就慢慢进阶了。为了自己的承诺和项目组整体的进度，有的时候，你需要在保证质量的基础上，拼命加班，不负所托。
再补充一点，可靠并不是说绝不出错，是人都会犯错。但你不能重复犯错，相同的错误出现两次，会严重影响别人对你的信心。
4. Work hardest 以绝大多数程序猿的努力程度，还轮不到拼天赋这一点可能会有争议，也会有很多程序猿跳出来说，老子996都不止，一周工作80个小时都有了。并不否认，很多行业里的程序猿，以互联网尤甚，加班是很夸张的。但我想表达的是，你要做你们团队里最努力的那个人，别人工作80个小时，你就工作90个小时。你以为所有爬上去的人都是领导亲戚或是被潜规则？别傻了，如果大家资质差不多，一定是最努力的那个人首先得到机会。领导又不傻，马群里挑一匹跑的最快挑的最重的来带头，肯定会有示范效应，也容易服众。当然，健康是自己的，如何保持足够的休息和锻炼是你必须认真考虑的问题，不是你领导考虑的问题。另外，如果真的资质相差太大，省点力气，排队等机会吧，不行就换行。程序猿这一行里，最牛逼和最平庸之间的生产效率之比大致是50：1。
5. Do the simple things right 再简单的事情都要做好，注重细节你review过的代码里最低级的错误是什么？我遇到很多很多，“==”写成“=”、三个参数只传了俩、“1 <= month && month <= 12” 写成“0 < month && month < 12”、不判断返回值就直接下一步调用，太多太多。
写邮件的时候，很多人直接把话都写在标题，内容为空；也有标题空着的，或者叫“经理你好”；或者邮件字体时大时小，一会黑一会蓝，看的人时刻有惊喜。
写文档的时候，busy写成 buzy，该换行分段偏不，该用流程图说明的偏要用文字，好不容易画个流程图，方框里一会是实体一会是操作，箭头各种乱指，你写得出来，别人可看不下去。
这类人，你是老板，你敢提拔他当主管？
再举一个正面的例子，我的团队里曾经缺乏一个项目助理，不得已选了一个程序猿小伙，让他兼职管管样机、发发通知，小伙没有怨言，除了自己的代码照常写的非常稳妥之外，兢兢业业做好这些小事。后来没多久他就当上了主管。一个有能力把小事做到极致的人，也必定有潜力把大事做好。
6. Be open-minded don't be defensive 心态开放，接受他人意见，别人批评建议的时候不要习惯性辩解和说不以前我的团队里有几个同一届毕业的优秀小伙，其中两人，就叫A和B吧。以编程水平、技术广度来衡量，A要更胜一筹，当然B也是杰出的程序猿。按理说，先得到晋升的应该是A，实际上，B很快就连升两级，再后来就带一个大型的团队了，而A始终是最基层的主管。
为什么？我举一些实际的例子。
作为年轻人，免不了有做的不足的地方，通常我都会面对面跟他们具体指出来，B通常会说：“收到，以后我一定注意”、“我不是很明白，能否给我一些具体事例，或者再给我解释一下。。。好的我明白了”、“我的理解是这样的不知道对不对。。。好的知道了”。然后在接下来的一个季度里，你很快就能看到他迅速改进，原来的弱项变成了他的强项。
而A呢？他会说“不是吧，我觉得不是这样的”、“这些道理虽然对，但是有点要求过高吧”，而往后，你所希望看到的变化还是没有发生，或者收效甚微。
当你的领导，愿意明确对你提出指导，不管是耐心的说教还是严厉的批评，你都应该抱着“有则改之无则加勉”的心态，即使要反驳，也要准备充分的理由和依据。面对领导的意见，要弄清楚其准确意图，然后实施针对性的改进措施。这就是团队里的游戏规则和生存之道。即使不是领导，是平级和下属，也应该采用类似的心态和应对方法。
7. Be logical. 有很好的条理，想事情做事情有逻辑很多程序猿，表达的时候通常是“我认为”、“我觉得”，或者说“听我的，只要这样这样，就能怎样怎样”但是一旦你追问其结论的依据，或者推导过程时，他又拿不出来。又或者，只知道埋头苦干，压根不管方向对错，轻重缓急。
程序猿是100%纯正的脑力工作者，但很多人却把自己变成体力工作者，自嘲自己身处劳动密集型产业，有的人甚至以日产出几千行代码为傲。这无疑是自废武功，自己把自己往“码农”的“农”字上推。定位问题，分析问题，解决问题，贯穿其中的都突出一个“逻辑”。无论是写设计文档、编写代码、测试，还是产品功能、用户需求、交互设计，概莫能外。先思考，谋定而后动，思考的过程，也就是找出因果关系，找出1234条论据以支持论点，找出step1 step2 step3 直至结果的推导步骤的过程。
当你有良好的条理性，有严谨的逻辑，也许凭直觉也能做出正确的判断。但时刻别忘了这一点。
8. Be thankful 懂得感恩什么是感恩？就是对指导、帮助、提携乃至批评过你的人的一种由衷的感激之情，懂得感恩的人都是善良的，善良且努力的人运气都不会太差（哈哈，仿烂鸡汤体）。只要你懂得感恩，甚至无需你做太多，只需要适时的表达，对方就能感受到你是孺子可教的，他就会觉得他的付出没有白费，而不是面对一个木头人或白眼狼。
同样还是上文的B童鞋，在我带过的几百人中间，他是最懂得感恩的一位。甚至于你在批评他的时候，他都会承认错误并感激你对他的指导。这样的人才，当他也拿出实实在在的业绩的时候，你怎能不提拔他？
而作为对比，有太多的人，你曾经无数次的帮助过他，无论工作上还是生活中，但从未听到他的一句感谢。这样的人，只能呵呵以对。
9. Think beyond technology 不要只会纯技术化思维10. Understand your products and users 理解你的产品和用户很多程序猿，痴迷于修炼技术，常常会在一个简单功能模块里面运用某某高深的算法和莫测的技术，纯粹为了炫技，而不去考虑是否过度优化，是否用户并不需要这么复杂的功能，是否投入产出比并不合理。无视用户、产品和市场规律的思考方式，就是纯技术化思维。
典型的一个案例是，（可能是处女座程序猿），所有的Bug都必须解完才可以发布版本，不管是不是犄角旮旯或耗时很久的。我在工作的第二年，我的领导跟我说了一个概念“Time to market”，让我意识到，你最关注的问题，或许并不是用户最关注的问题。你要做的，是应该快速把产品发布，再去倾听用户的呼声，可能100万用户里，都不会有人关注你花了几周时间死磕的问题，但他们会爆出更多更重要更迫切的问题。
你要时刻关注你的产品，关注你的用户，从电商的网评，从售后的热线，从论坛的帖子，从行业外的朋友，获取他们对于你产品的第一手的评价。一个好的程序猿，也应该是一个好的产品经理。否则你就是一个缺乏大脑的泥瓦匠，而不是一个建筑师。
作为一个程序猿的leader，你是要代表团队去跟产品经理撕逼的，如果你不懂产品，那么你的团队也就完了。
11. Have good communication skills 良好沟通做一个牛逼的程序猿，其实可以不用怎么讲话，用牛逼的代码和运行结果去碾压别人即可。但如果你想做程序猿的leader，还继续保持这么高冷的姿态可不行。沟通无疑是管理的基础，一个程序猿想升职，想做管理，必然需要证明自己拥有不错的沟通能力。跟高层领导要资源，跟产品经理撕逼，跟测试部门搞好关系，跟设计妹子开开玩笑，跟程序猿搞基，不会沟通显然是不行的，最好是亦庄亦谐，荤素兼备。
这里不展开讲如何拥有良好的沟通技巧。只说几点：1. 沟通的意愿最重要，只要你愿意主动沟通，事情总会向好的方面发展。2. 沟通要真诚，不要套路。3. 口才不行，你可以多用写，写还有个好处就是留有证据，方便以后撕逼。
12. Take responsibility 承担责任常在河边走，哪有不湿鞋。代码写多了，挖坑是必然的。面对爆出来的Bug，面对领导的责备，没什么好说的，自己惹的，自己clean up。
放更长远来看，谁都会出错，不管你是程序猿，还是程序猿的leader，甚至是高管，总会被爆出问题。这时候是各种借口推诿，还是大大方方承认，并且用最快的速度处理干净？我认为正确的处理方式是后者，这不单单是能力问题，更多的是人品问题。
当你有朝一日当了leader，你手下犯了事，你也得大大方方站出来“我把关不严，责任我担”，绝不是把手下推出去了事（放你身上可能是小事，放他身上可能就得开除了），回过头再关起门内部处理。只有这样，你的手下才会服你，才会有人为你拼命干活。
最后，做不好管理就做纯技术，做资深专家、技术大拿也挺好，不要强扭。
/* End */
