我是码农出身，工作十年，从初级程序员（半年）→ 项目主力（一年）→ 初级技术管理（一年）→ 中级技术管理（两年）→ 部门管理（两年）→ 高层管理（三年）→ 职业经理人，一条路走过来，关于升职，有一些自己的心得可以分享。

　　1. Love Coding 热爱编程

　　大四开始找工作的时候，我正在上一门可视化编程的课，大概就是用VC编写出可以绘图、简单动画和播放多媒体文件等各种操作的程序。基于这门课，我编写了贪吃蛇、俄罗斯方块等各种游戏。另外的一段编程经历是大二时候的Java大作业，编了一个很弱的图片管理器。

　　实际上，这些程序都非常弱智，那时候的我算法极差，代码规范性极差，甚至于对SDK或库函数的掌握也极差，是个地地道道的菜鸟，但这并不妨碍我喜欢编程。我发现，当我坐在电脑前敲代码，或者对着千疮百孔的程序不断调试，打断点，加入调试代码，单步执行查看内存变化的时候，我是乐在其中的，甚至于忘了时间。所以，面临工作方向选择的时候，我毫不犹豫选了coding。

　　于是，当07年我在缺少指导，对Linux不甚了解，对路由器也一知半解的情况下，开始开发国内厂商的第一代11N路由器的时候，倾注了大量的精力阅读《LDD3》，搞定交换芯片驱动；大段大段的啃Linux Kernel源码，搞定netfilter/iptables；阅读《UNIX环境高级编程》，搞定各种同步互斥进程线程；阅读网上的各种技术博客，包括把竞争对手的GPL代码Down下来仔细阅读……一年里加班无数，五一、十一也都是在加班中度过，一年下来基本上搞定了领导交给我的艰难任务。然后又用一两个月的时间，把产品上市后爆出来的各种Bug一一解决，最终赢回了市场口碑。

　　如果没有这种热爱，你就无法在日复一日的coding中保持专注，更不用说脱颖而出。

　　任何成功背后，都有不为人知的苦闷和寂寞。程序员的苦逼之处，就在于别人高谈阔论指点江山的时候，别人推杯换盏觥筹交错的时候，别人出差南北纵横内外的时候，别人利用工作之便撩汉泡妞的时候，你只有面对屏幕，把键盘敲的啪啪啪。如果你忍受不了这种寂寞，体会不到其中的乐趣，请尽早换行。程序猿的高潮，来自于屏幕上排版良好的指令，按照你的意志精确执行，并且分毫不差。

　　2. Know yourself 贵有自知之明，了解自己

　　自知之明这个词，说的容易，做起来特别难。但又特别重要。

　　以前我团队里有个小伙，非常非常内向，话没说几句就脸红，后来程序员不干了要去做展会，学跟人打交道，说是要挑战自己。我不知道他后来怎么样，估计结果不太好。人的性格在十几岁的时候基本就定性了，二十几岁的人再想彻底改变自己，极难，有这个毅力，估计什么都能做好了。

　　扯远了。这一条最想说的是，弄清楚你到底适不适合干程序猿这一行，我多年的经验总结下来，优秀的程序员都有如下的性格特质（或部分）：细心严谨、细节强迫症、完美主义、做事情有条理、耐得住寂寞、喜欢跟机器跟代码打交道（相比跟人打交道）、口才一般不佳、容易偏激或钻牛角尖、人情世故方面稍显笨拙。与之相对的是销售：口才极佳滔滔不绝、擅长跟人打交道、为人处世圆滑、八面玲珑、说话虚虚实实、为达目的不择手段。所以，适合什么样的职业方向是有章可循的。

　　仔细想想自己是什么样的人，结合上一条，知道自己有没有一颗热爱 coding的心，你就能知道自己到底适不适合这一行。

　　自知之明还体现在，干这一行的过程中，详细了解自己的各项技能的长短，扬长补短。程序员不是简单会敲代码就行，构思、设计、编码、测试、调试，往往编码只占很小的比例。而且程序猿这一行范围又极广，底层驱动、操作系统、协议栈、前端、服务器、APP、数据库、大数据、分布式、系统集成......怎么选择，怎样能够发挥优势，真的应该好好想想。

　　在职业生涯规划里面，知己知彼是非常非常重要的。知己，即是了解自我的个性、特点、优劣势、需求；知彼，即是了解行业、企业、团队、职位的情况和要求。

　　3. Be reliable 可靠，说到做到，做好本职

　　作为程序员，最基本要求是：代码可读性好、功能正常没有明显bug。

　　但我见过太多这行里的毛头小伙，数字常量到处埋，函数命名用拼音，if else 十层八层嵌套，匈牙利命名法和Linux命名法混杂，代码像挤在一张皱了的纸上，零注释或写完代码补注释，异常处理缺失，还有基本功能一用就崩溃，还辩解说，在我那里是好的呀。遇到这一类人，通常我在心里先给打个D等（ABCD），日后恐难以翻身。

　　还有稍微进阶一点的毛病，说这个功能包我身上没问题，又或者一周之内绝对给你搞定，领导你放心。但最后拿出来的代码不是错漏百出，就是规定时间内根本完不成，而且到deadline前你询问他的时候，他才告诉你搞不定……项目组里有这样的人，要么得配一个给他擦屁股的，要么得配一个项目助理时刻监督他，换一句话说，他的贡献值其实为负。

　　程序猿要想进阶，其实什么设计模式、架构、高深算法、莫测技术都不重要，这些都只是术，或者说套路。最核心的应该是，把简单的任务完成好，之后再完成更难一点的任务，这样你就慢慢进阶了。为了自己的承诺和项目组整体的进度，有的时候，你需要在保证质量的基础上，拼命加班，不负所托。

　　再补充一点，可靠并不是说绝不出错，是人都会犯错。但你不能重复犯错，相同的错误出现两次，会严重影响别人对你的信心。

　　4. Work hardest 以绝大多数程序猿的努力程度，还轮不到拼天赋

　　这一点可能会有争议，也许会有很多程序员跳出来说，老子996都不止，一周工作80个小时都有了。并不否认，很多行业里的程序员，互联网尤甚，加班是很夸张的。

　　但我想表达的是，你要做你们团队里最努力的那个人，别人工作80个小时，你就工作90个小时。你以为所有爬上去的人都是领导亲戚或是被潜规则？别傻了，如果大家资质差不多，一定是最努力的那个人首先得到机会。领导又不傻，马群里挑一匹跑的最快挑的最重的来带头，肯定会有示范效应，也容易服众。当然，健康是自己的，如何保持足够的休息和锻炼是你必须认真考虑的问题，不是你领导考虑的问题。

　　对我来说加班最夸张的一段时间是八点半上班，除去午休一个半小时，晚上十一点下班，差不多持续一个月。我从来都不认同不眠不休的持续高强度加班，所谓的弹性工作制其实是最坑人的，每天工作到夜里一两点然后第二天十点十一点去上班？有意义吗？十二点准时睡觉，第二天八九点准时去上班，想挂掉都没那么容易。这一点很感激前东家死板的考勤制度。

　　另外，在我的职业生涯里，从来都是提倡快乐工作快乐生活，我所带的部门，篮球、羽毛球健身水平都是公司顶尖。最忙的时候我一样一周打球两三次。可现实中不用加班一有空依然打游戏、看片、呆坐电脑前熬夜的程序员不在少数。不要为自己不健康和颓废的作息找借口。

　　真正牛逼的人，懂得人生是马拉松而不是百米冲刺的道理。

　　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. Understan d your products an d users 理解你的产品和用户

　　很多程序员，痴迷于修炼技术，常常会在一个简单功能模块里面运用某某高深的算法和莫测的技术，纯粹为了炫技，而不去考虑是否过度优化，是否用户并不需要这么复杂的功能，是否投入产出比并不合理。无视用户、产品和市场规律的思考方式，就是纯技术化思维。

　　典型的一个案例是，（可能是处女座程序员），所有的Bug都必须解完才可以发布版本，不管是不是犄角旮旯或耗时很久的。我在工作的第二年，我的领导跟我说了一个概念“Time to market”，让我意识到，你最关注的问题，或许并不是用户最关注的问题。你要做的，是应该快速把产品发布，再去倾听用户的呼声，可能100万用户里，都不会有人关注你花了几周时间死磕的问题，但他们会爆出更多更重要更迫切的问题。

　　你要时刻关注你的产品，关注你的用户，从电商的网评，从售后的热线，从论坛的帖子，从行业外的朋友，获取他们对于你产品的第一手的评价。一个好的程序猿，也应该是一个好的产品经理。否则你就是一个缺乏大脑的泥瓦匠，而不是一个建筑师。

　　作为一个程序员的leader，你是要代表团队去跟产品经理撕逼的，如果你不懂产品，那么你的团队也就完了。

　　10. Have good communication skills 良好沟通

　　做一个牛逼的程序员，其实可以不用怎么讲话，用牛逼的代码和运行结果去碾压别人即可。但如果你想做程序员的leader，还继续保持这么高冷的姿态可不行。沟通无疑是管理的基础，一个程序员想升职，想做管理，必然需要证明自己拥有不错的沟通能力。跟高层领导要资源，跟产品经理撕逼，跟测试部门搞好关系，跟设计开开玩笑，不会沟通显然是不行的，最好是亦庄亦谐，荤素兼备。

　　这里不展开讲如何拥有良好的沟通技巧。只说几点：

　　沟通的意愿最重要，只要你愿意主动沟通，事情总会向好的方面发展；

　　沟通要真诚，不要套路；

　　口才不行，你可以多用写，写还有个好处就是留有证据。

　　11. Take responsibility 承担责任

　　常在河边走，哪有不湿鞋。代码写多了，挖坑是必然的，面对爆出来的Bug，面对领导的责备，没什么好说的，自己惹的祸，自己clean up。

　　放更长远来看，谁都会出错，不管你是程序员，还是程序员的leader，甚至是高管，总会被爆出问题。这时候是各种借口推诿，还是大大方方承认，并且用最快的速度处理干净？我认为正确的处理方式是后者，这不单单是能力问题，更多的是人品问题。

　　当你有朝一日当了leader，你手下犯了事，你也得大大方方站出来“我把关不严，责任我担”，绝不是把手下推出去了事（放你身上可能是小事，放他身上可能就得开除了），回过头再关起门内部处理。只有这样，你的手下才会服你，才会有人为你拼命干活。

　　最后，做不好管理就做纯技术，做资深专家、技术大拿也挺好，不要强扭。