转载

最让程序员崩溃的7件事

file

1)中断 & 开会

“中断” 可以说是程序员生产力的头号杀手,因为被打断之后很难回到之前的地方,需要重新梳理思路,很有可能半小时就过去了。
被打断的次数越多,挫败感就越强,生产力也低,bug就越多,一连串的恶性反应。
如果在早上就被打断,那么这一天很可能就出不了什么活儿了。
开会呢?开会就是“有计划的打断”。

2)琐碎型管理

这类管理者是开发团队的绊脚石,他喜欢有点儿破事儿就开个会,有点问题就去骚扰你。
不仅如此,他对团队成员缺乏信任,总喜欢和你抠细节。
程序员碰到这种管理者就倒霉了,常常会被打断,所以,此类团队中的程序员跳槽率是很高的。

3)含糊不清

例如收到一个bug “这个功能不好使,赶快改好!”,相信谁看到这么模糊的描述都会一脸懵。
比如产品需求文档中一个功能描述不清,你按照自己的理解开发了,后来产品经理过来了,说你开发的不对,应该这样……,靠!还得重新开发。
比如你正在奋力敲代码,悄悄的,经理来到了你的身边,告诉你做一个xxx功能,然后就走了,不管你理没理解,也不告诉你这个任务的优先级,就像一阵风一样。

4)海鸥型管理

你遇没遇到过这个类型的领导:平时啥也不管,但会偶尔蹦出来指手画脚挑毛病,“你这么做是错误的”、“你这个做的太烂了” ……
就像一只海鸥,偶尔冲下来把东西搞乱。

5)抢功

很多团队都会有这类的小人,他特别会在领导那儿表现自己,把你干了半个月的成果说成是他的功劳。
这种人让团队成员非常寒心。

6)需求蠕动

举个例子:
版本1(实现之前):这个功能是“显示这个位置的地图”。
版本2(在版本1即将开发完成的时候):功能变为“显示这个位置的3D地图”。
版本3(在版本2几乎开发完的时候):功能变为“显示这个位置的3D地图,并且用户可以飞过去”。
你XX的,不带这么折磨人的。

7)压缩工时

有的经理看似很民主:
“这个功能你需要开发多长时间?”
“3天吧”
“项目时间很紧张,辛苦点1天半做完吧”
“1天半真搞不定”
“那就2天吧”
“好吧”
他成功压价,还认为他尊重了你的想法,是你自己定的完成时间。

小结

这几个问题都是非常普遍的,你遇到过哪些?欢迎吐槽。

文章来源

正文到此结束