专栏名称: 伯乐在线
关注职业资讯;学习各类职业感悟、心得和经验分享,扩大职业视野;体会求职、工作和创业的历程 - 就在JobBole.com 伯乐在线
目录
相关文章推荐
程序员的那些事  ·  西部数据突然宣布:退出 SSD 市场! ·  3 天前  
码农翻身  ·  再这么搞下去,程序员失业是迟早的事! ·  昨天  
OSC开源社区  ·  字节跳动开源跨平台UI框架Lynx:一套代码 ... ·  2 天前  
OSC开源社区  ·  OWL:Manus通用智能体的完全开源复刻、 ... ·  4 天前  
51好读  ›  专栏  ›  伯乐在线

写给非技术人员评估技术同事的参考

伯乐在线  · 公众号  · 程序员  · 2019-12-31 21:03

正文

(给 伯乐在线 加星标,看经典文章

原文:顾露(@顾露-Gu_Lu)

http://gulu-dev.com/post/2015-11-05-tips-for-non-programmers

先说两句

这个易燃易爆的话题,其实俺是不敢写的。在工程师队伍里滥竽充数了几年,俺觉得自己还没被清理和淘汰出去,已经谢天谢地了——不赶紧回去提高姿势水平,居然还在这里装大尾巴狼,大言不惭地讨论如何评估程序员,其心可诛啊。

那为何俺还要冒码农之大不讳,在这里妄议是非,大放厥词呢?是因为俺发现,在日常工作中,对于一些非技术向的小伙伴们,由于对工程师文化了解并不多,要么难以寻找到合适的技术伙伴,要么在工作中与工程师难以保持稳定的沟通节奏,对于这些小伙伴,俺愿意把俺知道的分享出来,肤浅也好,片面也罢,总之是多了一点参考,希望能有所帮助。

1. 对技术的分析和判断力

技术没有先进与落后之分,只有适用与不适用。如果你经常听某个程序员对你说 “xxx 很先进,比 yyy 好多了,应该用 xxx 就不会有这些问题了”,“xxx 非常强力,BAT (此处可换为任何一个公司名) 的 yyy 项目以前用的是 zzz,现在都改用 xxx 了” 那么就要对他的判断力打个问号了。

下面是一些包含更多价值的例子,

  • “xxx 虽然在 aaa 方面不太好,但比 yyy 更适合我们的项目,因为我们眼下更需要 bbb 和 ccc,将来如果在 aaa 方面出了问题,我们可以做这样的调整:1… 2… 3…”

  • “我们之所以不用常规方案 xxx,而是用更激进一点的 yyy,是因为我们的项目在 aaa 和 bbb 等方面没有那么强的约束,虽然损失一些 ccc,但是可以获得更高的 ddd 和 eee”


如果你发现一个程序员,行走都把某个特定的平台/工具/技能/编程语言挂在嘴边,“xxx 就是好啊就是好”,你就会知道他不仅有选择上的局限性,也会在技术判断中不可避免的因为已有的积累产生偏见,正所谓“手里握着锤子的时候,满世界长得都像钉子”,一般这种程序员,俺称之为“信徒式程序员”。

2. 对待预估任务时间的态度

诚实是一个重要的品质。相比起对他人的诚实,对自己的诚实就更难了。

举个例子,你答应了两个礼拜后交付一个版本,可是因为某些原因,一个礼拜过去之后,你发现自己还需要两个礼拜,这时你会如何选择呢?

诚实的态度是,承认自己的时间预估是不准确的,要么砍掉一部分计划,按期交付,要么保证功能的完整性和质量,延期交付。如果一方面拍胸脯保证能按时交货,另一方面罔顾负荷与节奏,过度地挤压,就是不诚实的表现。这样短期内能获得更好的 KPI,但工程质量,团队士气都会受到打击,长远看得不偿失。诚实余额不足的协调者,惯用这种伎俩,通过各种手段,汲取和消耗组织的能量来为自己的 KPI 充电。更糟的是,这会使组织对团队的能力做出有偏差的判断,进一步放大问题,以致走上一条不归路。

正确地预估任务时间,是一项需要经年累积才能有一点点成长和收获的技能。任何一项任务,有经验的开发者给出的不是一个拍脑袋的日期,而是包含以下诸要素的整体判断:

  • 完成核心功能需要的时间预估

  • 完成次级功能和周边工具链的时间预估

  • 系统集成,稳定化,性能优化的时间预估

  • 预留的缓冲周期


有经验的程序员对计划中的弹性点保持敏感,计划会随着实际进展不断调整,不会刻板地拘泥于原计划。他们的计划会尽量做到诚实且忠实地反映实际的进展情况。如果突发情况造成了计划外的影响,能及时地去做出调整,并向需要的人更新状态。

3. 为自己的工作建立明确的边界

所谓“明确的边界”,就是能尽早地建立明确的头脑模型,尽早摸清楚 (在你负责的领域内) 什么必须做,什么可以做,什么不能做,什么做不了。

有明确的边界会带来很多显性和隐性的好处。最重要的好处是,大家的需求关系明确化、协议化,不再依赖私下的潜规则,会节省后续大量的沟通成本。其次,愿意为自己的工作范围建立明确的边界的程序员,对边界内的代码质量通常会有强烈的责任感和主人翁意识,他们会比其他人敏感和熟悉得多,在他们的地盘上,他们能彻底的说了算。相关系统内如果出了问题,让其他人来可能要修两三天,换他来可能凭着对相关代码的熟悉度闭着眼睛就说出几个可能的问题点。

充满各种潜规则的系统非常脆弱,如果你发现一个程序员总在焦头烂额地处理沟通事务,往往就意味着隐患已经浮现出来了。缺乏边界意识的程序员,往往伴随着对代码较低的责任心。他们不把自己工作的代码看做是“自己的”,自然也就不会尽心尽力地去好好维护。

有种流行的说法是,应该通过某种形式的“轮换”,把程序员打造成“可轮换的”螺丝钉和多面手,以降低人员流失带来的风险。也许这一方式对其他行业会很有效,但至少在游戏行业,我发现,被这样轮换的程序员,这样来过几次之后,确实是对彼此的系统更熟悉了没错,但他们变得不再像之前那样“精心地”照料自己原本负责的那片代码。因为被 n 个人按自己的思路修理过之后,他们已经失去了“对那片代码的爱”,他们逐渐慢慢地从“园丁”变成了“游客”。随着时间的推移,没有人对这个模块内部的所有可能状态了如指掌,曾经被精心照顾的花园慢慢地变成了废弃的垃圾场。每个人改到这里都是无奈地捂着鼻子赶紧弄完了事,只要不要弄出新的问题就谢天谢地。这种腐化通常是加速而且不可逆的,从工程角度来讲,这往往预示着这一堆代码的废弃。更残酷的是,程序员们纷纷发现在这个项目里无法积累真正的领域相关经验,成为专家,还有什么比天天围着一辆二手车的不同部位反复修理又得不到成长更糟糕的事呢?他们唯一合情合理的选择,就是拂袖而去,或是准备以温和一点的方式拂袖而去。

程序员对代码的爱是一个项目里最稀缺的资源之一,不要忽略它,更不要粗暴地碾碎它,要通过创造稳定的环境和氛围去创造它,培育它,这样的代码库才能成为肥沃的土壤,带来源源不断的回报;否则就会变成一个摇摇欲坠、四处冒烟的,靠巧合来得以运行的庞然大物。

4. 对“异端”的相容度

「托利得定理:测验一个人的智力是否属于上乘,只看脑子里能否同时容纳两种相反的思想而无碍于其处世行事。」

这句话有三层递进的意思:

  1. 具有包容性。能够理解矛盾各方的情势,对盲点敏感,不容易被蒙蔽。

  2. 具有批判性思维。能用理性和逻辑等工具去分析问题,形成自己的判断,不盲从。







请到「今天看啥」查看全文