程序员工作中会遭遇的天花板

工作中不由你控制的一些地方
服务器君一共花费了149.830 ms进行了4次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

在我看来,程序员做的是开创性的工作。互联网的发展不但推动了技术的发展,而且带来了技术的普及。因此程序员不比以前,现在要找某方面的资料是很easy的事情了。看过大量的资料,各种新颖的技术方案和解决思路,不心动那是不可能的。OK,想用某某某框架,想用某某某技术,但是,因为各种原因,没办法应用到自己开发的项目中。这就是一个天花板。

在工作中往往有各种各样的天花板,比如绩效考核,项目进度,被打断的思路,技术架构。因为你不是做决定的那个人,所以你就有天花板。

绩效考核

很多公司都有绩效考核,在我看来绩效考核一个出发点很好,但是执行起来很扯淡的东西。从公司的角度来讲,保证每个员工都在努力工作是很必要的一件事情。绩效考核书面上讲是一个激励制度,我倒觉得更像是惩罚措施。绩效考核首要的问题是由谁来考核,在一个团队里不可能每个人都去考核一个人,也不会由普通员工之间进行考核,而是主管对普通员工进行考核。那就有可能滋生官僚主义,也会抑制主动性与创新力,增加犯错机会。如果,对员工的考核都由主管来进行,员工丝毫没有话语权,主管的人品就决定了团队的运作方式。如果主管不太能接受意见,那谁还敢提意见?一个团队了某人犯了错误,哪个主管敢给他背责任?因为也有更高的主管对小主管进行考核。团队之间完全没有了人情味,纯粹就是机器的运作方式。

在这种情况下,大家都加班,你敢不加班么?在这种情况下,主管听不进,你敢指出问题么?在这种情况下,你敢使用新技术,进行技术创新么?在这种情况下,你敢对现有代码进行重构么?要是敢,那出了问题你就得背负。所有反而不如踏踏实实地,就用现有的东西,出了问题,就是已有的问题,没有问题就是混日子。所以,绩效考核成了程序员的天花板,抑制了想象力与创作的热情。哪怕开发计划肯定也是瞄准最容易的,而不会去挑战什么了。

我认为,绩效考核用在无需创新的场合比较合适,在软件开发上,则面临如何去划分工作量,怎么客观得评估工作量,还有就是上面提到的一些问题。大家都知道,这个工作量是很难被确定的,因为需求的变更等原因,即使需求不变,开始时估计的工作量能按时完成的有几个?貌似很多书上都讲很多项目完成的周期在预计的1.5倍时间左右。

我认为只有一种情况可以使用绩效考核对程序员进行管理,那就是你不需要程序员进行思考,在软件设计阶段把所有的风险都规避了。比如瀑布模型开发,所有的东西都确定了,然后程序员只负责开发一个个方法,根本无需考虑算法问题,架构问题。程序员成了代码工人。估计这个程序员离离职也不远了。

项目进度

项目进度应该被强调。虽然项目进度也会对程序员的开发有一些抑制,但是不会太过明显。因为项目进度本身就是由他自己来确定的。项目进度虽然会抑制创新,但是会加强团队的整体感。假如甲开发的东西,是乙依赖的,那甲和乙肯定会保持沟通,并且,甲会对乙的进度负有一定的责任。如果甲是由责任感的话,只会让甲对团队有归属感。

但是如果本来是要一个月的开发任务,非要压缩到一周完成的,团队又会滋生新的问题了。一个是互相推诿,一个是团队不稳定(跳槽)。

被打断的思路

思路被打断是很恼火的事情,如果经常发生这样的情况,那是公司流程上有问题。只能从制度、流程上尽量规避这种事情。

技术架构

很多小公司其实并不存在这样的情况,因为技术架构就是由工程师直径决定的。在大一点的公司里,架构师设计的架构,就是程序员必须遵循的法则。比如,让你用Mysql你就不能用mongodb。有一些架构师设计出来的技术架构,还留有开发人员自己思考的空间,而有些架构师设计的技术架构,则完全抹杀开发人员的尝试。虽然技术架构保证了业务的稳定性,程序的规范性,可复用性,可维护性,可扩展性.....但对开发人员来讲,那种架构师好则自然不言而喻。

在团队管理中,要注重每个人,考虑每个人的发展,而不是抹杀掉他们的思考。总的来讲,团队里人才是最重要的。

本文地址:http://www.nowamagic.net/librarys/veda/detail/1737,欢迎访问原出处。

不打个分吗? 还木有人打分噢!

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/1737

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《UNIX编程艺术》 姜宏 (作者)

《UNIX编程艺术》主要介绍了Unix系统领域中的设计和开发哲学、思想文化体系、原则与经验,由公认的Unix编程大师、开源运动领袖人物之一Eric S. Raymond倾力多年写作而成。包括Unix设计者在内的多位领域专家也为本书贡献了宝贵的内容。《UNIX编程艺术》内容涉及社群文化、软件开发设计与实现,覆盖面广、内容深邃,完全展现了作者极其深厚的经验积累和领域智慧。

更多计算机宝库...