Go homepage(回首页)
Upload pictures (上传图片)
Write articles (发文字帖)

The author:(作者)aaa
published in(发表于) 2013/12/24 6:44:12
Working hard OR being lazy， you’re kind of a programmer，

Working hard OR being lazy, you're kind of programmer-programmer-it news Working hard OR being lazy, you're kind of programmer

When a person at the time of completion of a physical work, you can easily assess whether he is trying to work. You can observe his physical movements, watch how much he sweats. You can also see the success of his work: the high brick walls in masonry, dug pits in the ground. Hard work recognised and awards are very basic instinct in human nature. This is one reason why people so obsessed with physical endurance sports activities. This instinct for physical hard work appreciated encountered when managing a bunch of technical creative employees, has become a headache. White collar worker would normally be viewed as efficiently and without trying to work.

Back in 2004, I was a junior programmer, working for a cable TV company, development finance and marketing systems in a large team. As with all large systems, this system is made up of lots of relatively independent modules, respectively, by some individuals or small teams. Analog TV and digital TV's financial and distribution system is almost completely independent, developed by two teams, respectively.

Analog TV Development Group decided in the early days of Microsoft Biztalk platform to develop their systems. By this company by a team of 4 guys and Microsoft jointly developed and is responsible for production environments run. They seem to really work very hard and hard. You can often see them late into the night or weekend work. Everyone put down the work at any time to solve formal problems cropped up in the environment, often at the same table people revolves around a young man speak his opinion to discuss what was wrong and how it should be amended. The working atmosphere is always in full swing, and everyone can see this-even just happened to glance at a glance, just speaking from the whole team, but each one of them working really, really hard.

Digital TV distribution system development team is completely different. Code is written by a guy, we'll call tadawei. I am a junior programmer, doing maintenance work in the team. At first, I understand his code is in great trouble. His code is not a long process, usually I will put together a lot of code, on the contrary, he has a large number of very small class in the code file is small, and only a few lines of code. Several colleagues have complained that David do overly complex code. But David patiently teaching me, advised me to read a few books on object-oriented programming. He told me of a design pattern, SOLID principles of programming, unit testing and so on. Soon, I began to understand the code to him, the more I studied his code and enjoy the elegant design of the program. The code placed in the production environment is very easy to use, stable operation of doing their work. These code changes are pretty straightforward and, therefore, some new features added to become easy. Unit testing ensures that the bulk of the bug are blocked to the outside of formal environments.

Results of these practices is that we look not at the very hard work. At 5:30 we work on time, never add any classes on weekends, we have never had a large group of people around a number of hours discussing how errors happen in a formal environment. To outsiders, we must have been assigned a relatively easy task. But the truth is that requirements are very similar, we're just better design and implementation of the system, has a better support system infrastructure, in particular unit testing.

Management claims to employees based on their performance pay. When talking to me when it comes to the boss, the boss said it was only to those who work really hard show fairly staff salary. Our team looks for the development of the company did not pay too much attention – those who gave up their evenings and weekends compared to the heroes.

This company is a rare laboratory, you can be good and bad software design, software design, the characteristics of a good team and a bad team doing a direct comparison of the characteristic effects. Most companies could not offer such opportunities. It's hard to say that these sweat, working late into the night and on weekends, the boys insist on rushing over fire-fighting front line is very, very complex systems in order to develop a real and showed great dedication, still is a failure. Unless you have the ability to provide both teams to compete and let them solve the same problem, but which companies are willing to do such a thing. Instead, how we look at those sitting in the corner, nine-to-five, looking like Internet read what programmers do all day? Is their capacity to write robust stable code? Or assign a job is easier than others? In the eyes of ordinary people, the former a boys team is trying to work, and the second is not. Hard work is commendable, lazy shame, isn't it?

My bet is that, seem to be working very hard on the surface usually is a sign of a failure. At high pressures, in an environment of constantly being interrupted, software development, typically do not do a good job. Work often is not a good way for a long time. Sometimes the best way to solve a problem is to stop thinking, going out for a walk, or, even better, a good night's sleep and subconscious mind to help you out. My favorite book is the 20th century United Kingdom mathematics leaders that G. H. Hardy wrote a Mathematician's Apology. In this book, Mr Hardy describes his ritual: work 4 hours this morning, afternoon watching cricket matches. He said that for more than four hours a day of intense mental work is meaningless, and inefficient.

For those executives, I want to say is that judging a person wants to look at the results, to develop software is good or not, rather than how they act is hard work. Very counter-intuitive, you'd better not sit in the middle of these programmers, so that you are not affected by index of traditional, instinctive judgment, so you can have a better awareness of their outputs. Telework is particularly effective in practice, you could just output usually judged them, and not easy watching their 8 hours sitting at their desks in front of the IDE crackling tapping the keyboard or "dedicated" around at someone else's table provides a "valid" proposal.

努力工作OR懒惰，你是一个什么样的程序员 - 程序员 - IT资讯
努力工作OR懒惰，你是一个什么样的程序员

当一个人在完成一件体力工作时，你很容易评估他是否在努力的工作。你可以观察他的物理动作，看他流了多少汗水。你还可以看到他工作的成功：砖墙在砌高，地面上挖的坑在变大。对努力工作的认可和褒奖是人性中非常基本的本能反应。这也正是为什么人们对体力耐力体育活动如此着迷的原因之一。这种对体力上的辛苦工作的本能的赏识，在遇到管理一群技术创造型的员工时，却成了一个麻烦问题。高效的脑力工作者通常会被看作并没有在努力的工作。

早在2004年，我还是一个初级程序员，工作在一家有线电视公司，在一个大型团队中开发财务和供销系统。跟所有的大型系统一样，这个系统由很多的相对独立的模块组成，分别由一些个人或小团队负责。其中模拟电视和数字电视的财务和供销系统几乎完全独立，分别由两个团队开发。

模拟电视开发组决定在早期的微软Biztalk平台上开发他们的系统。由这个公司的4个小伙和微软的一个团队共同开发，并负责产品环境的运行。他们看起来真的工作的十分辛苦和努力。你经常能看到他们加班到深夜或周末加班。每个人都会随时放下手中的活儿来解决正式环境中突现的问题，经常会在一张桌子前一群人围绕着一个小伙，各自说出自己的见解，讨论什么地方错了，应该如何修正。工作气氛永远是热火朝天，每个人都能看到这些——即使只是经过瞟一眼，不仅仅从整个团队讲，而是他们每个人都真的真的工作的很努力。

数字电视供销系统开发团队却是完全的不同。代码几乎是由一个家伙写的，我们就叫他大卫吧。我是一个初级程序员，在团队里做维护工作。起初我在理解他的代码时遇到了很大的麻烦。他的代码里没有很长的过程，通常我的代码会把很多操作放到一起，相反，他的代码里有大量的很小的类文件和只有几行代码的小方法。好几个同事都抱怨大卫把代码搞的过度复杂了。但大卫耐心教导我，建议我去读几本面向对象编程的书籍。他给我讲设计模式，SOLID编程原则，单元测试等知识。很快，我对他的代码开始有了理解，我越研究他的代码，越欣赏这些程序中优雅的设计。这些代码放到产品环境中非常好用，运行稳定的干着它们的工作。这些代码修改起来也相当简单，因此，一些新功能的增加变得轻松容易。单元测试保证了大部分的bug都阻挡到了正式环境之外。

这些做法产生的结果就是，我们看起来完全不是在十分努力的工作。我们5点半准时下班，周末从来没有加过班，我们从来没有发生过一大群人围绕着一个人数小时的讨论正式环境中的错误是怎么发生的场景。在外人看来，我们肯定是被分配了一件相对容易的任务。但事实上，需求都是十分相似的，我们只是更好的设计和实现了这个系统，有更好的支持系统基础架构，特别是单元测试。

管理部门宣称他们要根据员工的工作表现涨薪。当轮到老板跟我谈话时，老板说只给那些工作真的努力的员工涨工资才显的公平。而我们的团队看起来对公司发展的好坏并不太在意——跟那些放弃了自己的晚上和周末的英雄们相比。

这家公司是一个稀有的实验室，你可以将好的软件设计和坏的软件设计、好的团队特征和不好的团队特征的影响效果做一个直接的对比观察。大多数的公司里不可能提供这种比较的机会。你很难说这些挥汗如雨、工作到深夜和周末、坚持冲在灭火第一线的小伙们是为了开发一个真的非常非常复杂的系统而展示了伟大的付出，还是就是一次失败。除非你有能力提供两个团队来竞争，让他们解决同样的问题，可是哪个公司愿意做这样的事情呢。相反，如何看待那些坐在角落里，朝九晚五，看着像是整天上网读什么东西的程序员呢？是他们善于写出强健稳定的代码吗？还是分配的活儿比其他人容易？在常人的眼里，前一个团队的小伙们是在努力的工作，而第二个不是。努力工作值得赞扬，懒惰可耻，不是吗？

我敢断言，表面上看起来工作很努力通常会是一种失败的信号。在高压下，在一个不断被打搅的环境中，软件开发通常是不能干好的。长时间的工作往往不是一个好的方式。有时解决一个难题的最好的方法是停止思考，出去散散步，或更好的，去睡一个好觉，让潜意识帮你解决。我最喜欢的一本书就是20世纪英国数学界领军人物G. H. Hardy先生写的《A Mathematician’s Apology》。在这本书里，Hardy先生描述他的日常规律：上午4小时的工作，下午看板球比赛。他说一天超过四小时的高强度脑力劳动都是无意义的，也是无效率的。

对于那些管理者们，我想说的是，判断一个人要看结果，要看开发出的软件的好用与否，而不是看他们表现的是如何在努力的工作。很反直觉吧，你其实最好不要坐在这些程序员中间，这样能保证你不受传统的、本能上的评判指标的影响，这样你才能对他们的产出有更好的认识。远程工作是特别有效的一种做法，你只能通常他们的产出来评判他们，而不是省事的观察他们是否8小时都坐在办公桌前对着IDE噼里啪啦的敲着键盘或“热心的”围聚在另外一个人的桌前提供着“有效的”建议。

赞