我是码农出身,工作十年,从初级程序员(半年)→ 项目主力(一年)→ 初级技术管理(一年)→ 中级技术管理(两年)→ 部门管理(两年)→ 高层管理(三年)→ 职业经理人,一条路走过来,关于升职,有一些自己的心得可以分享。
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. Understand your products and users 理解你的产品和用户
很多程序员,痴迷于修炼技术,常常会在一个简单功能模块里面运用某某高深的算法和莫测的技术,纯粹为了炫技,而不去考虑是否过度优化,是否用户并不需要这么复杂的功能,是否投入产出比并不合理。无视用户、产品和市场规律的思考方式,就是纯技术化思维。
典型的一个案例是,(可能是处女座程序员),所有的Bug都必须解完才可以发布版本,不管是不是犄角旮旯或耗时很久的。我在工作的第二年,我的领导跟我说了一个概念“Time to market”,让我意识到,你最关注的问题,或许并不是用户最关注的问题。你要做的,是应该快速把产品发布,再去倾听用户的呼声,可能100万用户里,都不会有人关注你花了几周时间死磕的问题,但他们会爆出更多更重要更迫切的问题。
你要时刻关注你的产品,关注你的用户,从电商的网评,从售后的热线,从论坛的帖子,从行业外的朋友,获取他们对于你产品的第一手的评价。一个好的程序猿,也应该是一个好的产品经理。否则你就是一个缺乏大脑的泥瓦匠,而不是一个建筑师。
作为一个程序员的leader,你是要代表团队去跟产品经理撕逼的,如果你不懂产品,那么你的团队也就完了。
10. Have good communication skills 良好沟通
做一个牛逼的程序员,其实可以不用怎么讲话,用牛逼的代码和运行结果去碾压别人即可。但如果你想做程序员的leader,还继续保持这么高冷的姿态可不行。沟通无疑是管理的基础,一个程序员想升职,想做管理,必然需要证明自己拥有不错的沟通能力。跟高层领导要资源,跟产品经理撕逼,跟测试部门搞好关系,跟设计开开玩笑,不会沟通显然是不行的,最好是亦庄亦谐,荤素兼备。
这里不展开讲如何拥有良好的沟通技巧。只说几点:
沟通的意愿最重要,只要你愿意主动沟通,事情总会向好的方面发展;
沟通要真诚,不要套路;
口才不行,你可以多用写,写还有个好处就是留有证据。
11. Take responsibility 承担责任
常在河边走,哪有不湿鞋。代码写多了,挖坑是必然的,面对爆出来的Bug,面对领导的责备,没什么好说的,自己惹的祸,自己clean up。
放更长远来看,谁都会出错,不管你是程序员,还是程序员的leader,甚至是高管,总会被爆出问题。这时候是各种借口推诿,还是大大方方承认,并且用最快的速度处理干净?我认为正确的处理方式是后者,这不单单是能力问题,更多的是人品问题。
当你有朝一日当了leader,你手下犯了事,你也得大大方方站出来“我把关不严,责任我担”,绝不是把手下推出去了事(放你身上可能是小事,放他身上可能就得开除了),回过头再关起门内部处理。只有这样,你的手下才会服你,才会有人为你拼命干活。
最后,做不好管理就做纯技术,做资深专家、技术大拿也挺好,不要强扭。
优秀人才不缺工作机会,只缺适合自己的好机会。但是他们往往没有精力从海量机会中找到最适合的那个。
100offer 会对平台上的人才和企业进行严格筛选,让「最好的人才」和「最好的公司」相遇。