1024节到了,教你如何正确的夸奖程序员

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接: https://blog.csdn.net/ly724368245/article/details/102728023

今天,为程序员点赞!

今天是 10 月 24 日,也就是“1024 程序员节”。
在这里插入图片描述
作为一个前非著名程序员,在我还在写代码的那段日子里,这个节日似乎还没有那么受重视。

毕竟是属于程序员的节日,还是得让他们开心一下,说不定心情好,今天会少怼你一些,最好是少写几个 BUG。其实也不是黑技术小哥小姐姐们,我当年写代码时也一样写 BUG,照样淡定脸并且自信地说:“这不是 BUG,这是一个功能”。

到公司后,如果你要开早会,结束后和程序员闲聊时可以用上一招。如果要开评审会,开会前也可以用上几招,确保会上不被喷得太惨。

好了,以下几条不保证有效,但可能会让你更了解身边的程序员。

你写代码真快,而且测试通过率很高
写代码的人分两种:一种是慢工出细活的,每段代码都反复琢磨、仔细检查后才能安心提交,但出活儿慢;还有一种是飞速写代码的,龙飞凤舞般在键盘上狂砸,最后抬手那一下回车,就能彰显他们自信的骄傲。

最后 Run 一下出结果那一刻,如果是 0 error,0 issue,那种感觉是很美妙的。

所以,写代码快、不出 BUG、测试省心、产品放心的程序员,可遇不可求。

你的注释写得真漂亮,跟你的代码一样!
写代码不写注释,这是大部分程序员的毛病,包括早年的我。

为什么呢?

因为注释不会被运行啊,注释没有生产力啊,注释是给人看的而不是给机器运行的。

所以宁愿花时间写代码,也不肯花时间写注释,只有码闲时,才有空写写注释当做打发时间了,也算给后来接坑的程序员积点德。

所以,能把注释写好的程序员,一定是一个既负责、又活儿好、而且有爱心的人。

这个 BUG 他搞了半天,被你两分钟搞定了!
解 BUG 就像一场侦探游戏,厉害的人能抽丝剥茧、逻辑细腻、直指真相,破解出满意的答案。

而一般的程序员,解 BUG 就像打地鼠游戏,这边按下去,那边又弹起来,最后拿一块大板子全部按下,结果机器爆了。

大师级的程序员总是不动声色站在新手背后,观察一番后,单手删掉几行代码,然后补充几个逻辑,BUG 就迎刃而解,然后拂袖而去。

这种人,我们可以称之为程序员中的扫地僧。所以,能解别人不能解之 BUG,才是大师。

这种大需求你都接住了,架构能力果然不一般
架构能力就是那种平时感知不到,但关键时刻扮演千斤顶的角色。

尤其是在面对一些调整比较大的产品需求时,有的甚至涉及到大部分系统重构。

如果此时架构给力,以插件或者组件式来实现变更,不仅程序员省力,产品经理也少了很多压力。

这种能力的施展,就是早期系统架构阶段,那些真正厉害的程序员使了葵花点穴手,在要害部位提前埋好了伏笔。

关键时刻一旦来临,他们的功力就体现得淋漓尽致。

所以,一个能应付各种 SB 需求的程序员,都是骨灰级的大师。

你是程序员中最具有产品思维的人!
每一个优秀的程序员,都有一颗产品经理的心。

观察一下现在互联网圈里的大佬就知道,很多都是程序员出身,马化腾、雷军、扎克伯格等比比皆是。

“码而优则产”,这些自带技能的人,伴随着一颗不安分的心和一个要改变世界的梦想,成就了自己的传奇。

程序员做产品有天然优势,逻辑思维强,分析问题和解决问题的能力一流。

如果让他们武装上沟通表达、设计审美、商业思维,那就是下一个优秀的产品经理。

很多人问我为什么要从技术转产品,我不是代码写得不好才做产品的,我只是换了一种方式去传承代码精神。

所以,一个具备产品思维的程序员,未来一定是光明的,如果你遇到了,好好和他做朋友,说不定未来你们能成为事业伙伴。

猜你喜欢

转载自blog.csdn.net/ly724368245/article/details/102728023