信息来源：阮一峰每周分享
文章来源：Learning programming is different from learning a programming language
Top 12 Things That Destroy Developer Productivity
A lot of articles address the role of tech leads and engineering managers. One common theme we often come across is how to increase a team’s productivity. But before you focus your energy trying to increase their productivity, you might first want to consider what’s destroying it, to have a sound base on which you can build. Unfortunately, even though Peopleware was published almost 30 years ago, we see lots of teams suffering from huge productivity loss in some (negatively) remarkable ways!
有很多涉及到技术主管和工程经理相关的文章,他们都讲到的一点就是怎么提高团队的生产力.但是在你集中精力来提高团队生产力之前,你要明白是什么降低了团队的生产力,以便我们能在以后建立起牢固的根基来保证团队的生产力.不幸的是即使Peopleware这本书已经发行了将近30年,我们仍然看到许多团队以明显(消极)的方式遭受着巨大的生产力损失的痛苦.
No one expects a programmer to get work done without access to a computer, but there are many companies that expect programmers to get work done without access to their mind. This is equally unrealistic.
没有人会期望一个编程人员在无法使用计算机的情况下完成工作,但是有很多公司却希望程序员在不了解公司意图的情况下完成工作,这同样很扯.
So let’s deep dive into our list of 12 things that prevent your developers from getting “into the zone” and being productive. I will try to prioritize this list from most to least impactful. Feel free to comment!
那么就让我们深入了解一下能够防止你的开发人员步入误区,并且变得高产的12件事吧,我会按对生产力影响从大到小的顺序罗列这12件事,你们可以随意评论.
If you’re wondering if all this is worth the investment, just consider the developer’s salaries. Even 10% more productivity is a LOT!
如果你在犹豫我说的这12件事值不值得投资,想一下你员工的工资,即使是10%的生产力提升也会给公司带来巨大利益.
1) Interruptions & Meetings
1) 各种打扰和会议
Interruptions are the top productivity killer for developers, in my mind. Developers can’t easily go back to where they were right before an interruption. They need to get into the mindset for development and then slowly trace back to where they left off. This can easily take more than 30 minutes. And the more interruptions, the more frustration, the less quality work, the more bugs – and it goes on.
在我看来,被打断思路对于开发人员来说是最有损生产力的因素,开发人员没有办法轻易地正确回到他们被打断之前的状态,他们必须再次进入之前的开发状态然后慢慢回到到他们被打断之前的思路中,而这很容易就能耽误他们30分钟的时间.而且被打断的次数越多,越让人感到挫败感,工作质量就会下降,bug也会越多,并且会一直这样下去.
“The more times you trip me up while I’m trying to get started – the longer between each time I’m going to try. If you fill my morning with interruptions – don’t be surprised when the day is unproductive.” A developer on Reddit
Reddit上的一个开发人员这样说:“我工作的时候被打断的次数越多,恢复到工作状态需要的时间就越长,如果你一上午都在打扰我,那么就不要怪我今天生产力抵消啦.”
What about meetings? The only difference between a meeting and an interruption is that a meeting is a planned interruption, which makes it even worse. Developers can’t progress on a task if they know that they will have an interruption while working on it. So if they have a meeting in one or two hours, they will not be able to progress on anything, as most engineering tasks take more time.
那么会议呢?会议与打断的唯一区别就是会议是有计划地打断,这就让会议给生产力带来更加严重的影响.开发人员在开发过程中如果知道自己将会参加一个会议时他们是没办法专心推进一项任务的,随后也将不会取得任何进展,然而大部分工程项目是需要花费大量时间的.
As Paul Graham wrote, “A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in.”
就如Paul Graham说的,“一个会议就能让整个下午分割成两个时间段,每个时间段都太段了,以至于你很难做好任何事情.”
How can this be avoided? This part is well documented; you have no excuse. Hold short status meetings at the very start of the day or just before lunch, for example, to avoid unnecessary interruptions.
怎么才能避免这些打扰呢?那就是好好记录一下,被打断后不要有任何辩解.比如,在每天刚开始的时候或者是在午饭前举办一个简短的status metting以避免工作中不必要的打扰.
2) Micro-management
2) 微观管理
Of the different types of managers, micro-managers might be the worst in terms of the developers’ productivity. Sure, micro-managers tend to have more meetings and unplanned interruptions. But it’s not only that. They show a lack of trust, and by doing so, you feel they constantly undermine your skills and your ability to get things done. Any motivation a developer had between interruptions will be just gone at that point. The impact goes beyond productivity. Micro-managers might be the first reason for developers to leave, or at the very least, to change teams.
在不同类型的管理者中,微观管理或许对团队生产力来说是最糟糕影响因素.可以肯定的是,微观管理趋向于开更多的会以及更多随意的打扰,但还不仅仅是这些.微观管理代表信任的缺失,通常也会表现出来,你会觉得他们经常低估你的技能和你完成工作的能力,开发者在两次被打扰之间的任何想要好好工作的动机都会因为上述原因瞬间消失不见,这带来的影响超过了员工的生产力.微观管理可能是导致开发者离开的首要因素,或者至少是改变团队的首要因素.
3) Vagueness
3) 需求模糊
There are many ways to illustrate vagueness. Bug reports like “It’s broken, fix it!” don’t have enough information for developers to work off of. By the way, having a bug report template can help in that case.
模糊有很多种,比如bug报告像这样,”程序崩了,赶紧修复它!”,这对开发人员老说根本没有足够的信息来debug,这种情况下有一个bug报告模板能带来不少帮助.
Or unclear specification on a feature, in which case developers will start implementing what feels right to them, before they have to start again from scratch once the manager better details the expected behavior.
或者对某个功能的规范不明确，在这种情况下，一旦管理员更好地详细说明了预期的行为，开发人员就能在他们不得不重新开始之前,开始实现对他们觉得对的事情。
Unclear prioritization also belongs in this category. The time that a developer spends wondering if they are working on the right task can so easily be avoided. And if ever they get a comment from the manager asking why they worked on this particular task (while priorities were not defined)…well, you get it – a lot of frustration…
优先级不明确也属于这个范畴.其实可以很容易地就避免开发人员花时间犹豫他们是否干了正确的事,如果开发人员得到经理的评论,问他们为什么他们要从事这项特殊的任务(然而事情的优先级是没有定义好的)…额, 你懂的,一吨挫败感.
4) Seagull Management
4) 海鸥管理
Have you ever heard of it? It happens when managers are totally uninvolved in the work, but… they just swoop down once in a while to shit all over everything. “This is wrong, and this, and this looks bad,” etc., before flying away again. I have to admit I loved the image, but unfortunately, this happens more often than we would like it to. This behavior is deeply frustrating to developers; they won’t be able to get back in the zone in the next few hours, and sometimes not even for days.
听说过Seagull Management(海鸥管理)吗?它通常发生在管理者完全不参与到实际的工作中，但是…,他们偶尔会突然参与进来把所有人都安排得任务满满，在他们离开前总会撂下这些话：”这个不对，这个也不对，这个看起来好像也有问题……”等等。我得承认我喜欢这种形象，但不幸的是，这种情况发生太多，让我们没法再喜欢它了。这种行为对开发人员造成了严重得困扰，他们再接下来的几个小时里都难以回到之前的思维状态下，有时情况会更糟，甚至是几天时间。
5) Credit Greediness
5) 贪功
Have you ever had a manager or other developer who took all the credit for the work you have done in the past weeks? Developers value competence above all. Taking the credit for someone else is taking the other’s competence for yourself and removing it from him or her. This is pretty high up on my list, as I feel it creates so much tension that it just destroys the whole developers’ productivity for quite a while.
你是否曾经有过这样的经理或者同事，他们把你几周辛苦工作取得的成果窃取走了？开发人员对能力相当地看重，窃取别人的成果就是把别人的能力和才敢伪装到自己身上。这在我所列的列表中占据很重要的地位，因为我觉得它产生了太多足以摧毁整个开发团队生产力的紧张氛围。
6) Environment – Noises, Motion, Workspace Design…
6) 环境 - 噪音、运动、办公产地的设计等等
This might seem strange to non-programmers, but the environment in which developers work has an important impact on their activities. For instance, having some white noise – loud AC, hearing cars and trucks roll by – helps them focus better. That’s why so many of us put headsets on! I actually just discovered RainyMood – really great 👍!
这对非编程人员老说可能有点奇怪，但是开发人员所处的环境对于他们的活力有很大影响。例如，一些白噪声 - loud AC，听一些汽车和卡车路过的声音能够帮助他们更集中精神。这就我们带耳机的原因！其实我刚发现了RainMood这个音乐，相当相当不错，👍!
Similarly, if the workspace is designed to have as much motion as possible, that won’t help them focus! Or having the desktop computer screens oriented in such a way that they are highly visible to the managers…well, that creates some extra stress and even more opportunities to be interrupted.
同样地，如果工作场所设计得很有运动感是没有办法帮助开发者集中注意力的。或者是让电脑屏幕朝向老板能够很容易看到的方向…额，这会给开发人员增加一些额外的压力和更多被打断的机会。
7) Scope Creepiness
7) 范围蔓延
Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This can occur when the scope of a project is not properly defined, documented, or controlled.
项目计划中的范围蔓延（也称焦点蔓延、需求蔓延、功能蔓延和厨房水槽综合征）指的是在项目中无法控制的改变。没能正确定义项目边界、编写项目文档或者正确管理项目都会导致项目蔓延的情况发生。
Scope creep turns relatively simple requests into horribly complex and time-consuming monsters! And most of the time it happens during development! For instance, for a simple feature:
Version 1 (before implementation): feature is “Show a map of the location”
Version 2 (when version 1 almost finished): feature is changed to “Show a 3D map of the location”
Version 3 (when version 2 almost finished): feature again changed to “Show a 3D map of the location that the user can fly through”
项目蔓延讲非常简单的请求变为异常复杂恐怖的“怪物”，比如，一个很简单的需求：
版本1（实时之前）：需求是 “显示位置的地图”
版本2（版本1快要完成时）：需求改变为 “显示位置的3D地图”
版本3（版本2快要完成时）：需求又改变了，变为“显示用户能够飞跃的区域的3D地图”
……
8) Product Definition Process
8) 产品决定过程
So this one might seem strange at first glance, but is actually pretty easy to understand. If a product team defines its team’s priorities without ever validating (through customer feedback or any other means) the interest of the corresponding features, and the developers see that most features are eventually just not used, they will feel that what they do is useless and will lose their motivation. We all want to feel impactful, and that may be even more important to developers!
这条乍一看可能有点奇怪，但其实很好理解。如果一个产品团队在尽管有用户反馈或者其他信息，且没有验证相应功能的兴趣点的情况下就指定好团队开发工作的优先级，团队里的成员心里也明白最终大多数功能时用不到的，这时候，团队成员就会感觉自己做这些都是没用的，就会失去动力。我们都希望自己能够由影响力，这对开发人员来说甚至更重要。
9) Lack of Consideration to Technical Debt
9) 对技术债务缺乏考虑
Technical debt is a deliberate decision to implement not-the-best solution or write not-the-best code to release software faster. Taking on some technical debt is inevitable and can increase speed in software development in the short run. However, in the long run, it contributes to system complexity, which slows the developers down. Non-programmers often underestimate the loss of productivity and are tempted to always move forward, and that becomes an issue.
技术债务是为了快速实现不是最好的方案或者写不是最优的代码来快速发布产品的一种故意的决定。从短期来看，为了提高软件开发的速度承担一些技术债务时必要的，但是长期来说，它会增加系统的复杂度，而复杂性的提升又会降低开发速度。非编程人员经常低估生产力低下给项目造成的损失，而且急功近利，这是个问题。
But if refactoring is never part of the priorities, it will not only impact productivity but also product quality.
但如果重构永远不是优先事项的一部分，它不仅会影响生产力，还会影响产品质量。
10) Tool Multiplicity & Hardware
10) 工具的多样性和硬件
Developers use many tools to program, push and merge their code every day. The more automation, the better. It goes without saying that if you use “ancient” tools, this will impact your productivity. Similarly, having a big screen vs only a laptop can have an impact. Given the cost of hardware and the developer’s salary, having just a 5% productivity gain is definitely worth any investment on that point! Just give the tools and hardware that your developer team prefers (individually for hardware, but as a group for the tools).
开发者使用多种工具编程，每天都会push和merge他们的代码，越自动化越好。不言而喻，如果你还在使用“上古”的工具，肯定会影响你的生产力。类似地，有一个大的电脑屏幕和仅仅只有一个笔记本也会对开发者产生不同的影响。考虑到硬件和人力成本，仅有5%的生产力提升也是非常值得往工具和硬件上投资的。给团队开发人员他们喜欢的工具和硬件设备（硬件分配给单个人，工具大家一起用）。
11) “How” Documentation
11) “怎样使用”文档
When learning how to code, we were told to comment early and often. The idea is that it’s better to have too many comments than to have too few. Unfortunately, many programmers incorrectly interpret this to mean that they must comment every single line of code, which is why we often see code like this (from Jeff Atwood’s post on “Coding Without Comments”):
刚学编程时，老师教我们先写注释，而且经常这样说。这是告诉我们注释多多益善，不幸的是，许多程序员不正确地理解了这句话，这导致他们对每行代码都做了注释，这就是我们通常看到代码，比如这样（来自Jeff Atwood发表的文章“Coding Without Comments”）：
1 | r = n / 2; // Set r to n divided by 2 |
Do you have any idea what this code does? Me neither. The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it’s doing it. If there were a bug in the program and you stumbled across this code, you wouldn’t know where to begin.
你能明白这段代码要表达的意思吗？我是理解不了。问题是有大量的注释来描述代码正在作什么，但是却没有一行注释说一下为什么要写这些代码。如果在程序中有一个bug，在你突然接触到这段代码的时候你是不知道从哪里开始查找问题的。
12) Impossibly Tight Deadlines
12) 没法完成的截止日期
This last one is linked to the tendency of managers to ask developers for estimates, then push them to lower those estimates as much as possible, and then magically consider them as deadlines! Managers will even consider that, as the developers themselves “decided” on the estimate, they committed to the deadlines, and therefore the deadlines should be considered valid enough to be shared to upper management.
最后一条与管理者向开发者询问预估时间有关，管理者会尽可能地让开发者缩短预估时间，然后想当然地把这作为最后截止日期。管理者会认为这是开发者自己预估的时间，他们认可这个截止日期，因此截止日期应该深思熟虑后再告诉上面的管理层。
Not surprisingly, developers feel that those deadlines are unreasonable and arbitrarily tight; this creates tension and an inability to focus.
不出意料，开发者会觉得截止日期订的毫无根据而且异常紧凑，这会让开发者感到紧张，因而难以集中精力。
How are all those things unique to developers?
If you look at all 12 things, they are actually pretty common to most other project-based jobs. It’s just that the impact of each of these is even more important for developers, as they need deep focus to progress on their tasks.
为什么这些事情对开发者来说是特别的呢？
如果你看完了这12件事，这些事也同样适用于其他项目导向的工作。仅仅是这些事情对于开发者开说是影响更大的，因为他们需要高度集中注意力来工作。
If you recognize some points mentioned above within your company, it might be interesting to address them with your developers. Talk to them; find out if these are an issue and how it can be resolved. Whatever they say, the most important thing is to trust their feedback and insights. And while today’s technology is very different from 30 years ago, the lesson is still the same. You can’t ignore the human factor when you consider team productivity. Iterate on your processes, environment and work habits with your team, and let them guide you on how to have the highest productivity and impact.
如果你注意到你的公司中存在上面所提到的问题，跟你的开发人员们一起讨论一下这些事情或许会很有趣。跟他们谈一下把，看看上面提到的事情在你公司是不是个问题，如果是，怎么去解决它。无论你的开发者们怎么说，最重要的就是相信他们的反馈和见解。而且即使是当今的科技跟30年前完全不一样了，问题还是这些问题。你在考虑团队生产力的时候是无法忽略人的这些特点的。与你的团队一起思考你们的流程，环境和工作习惯，让他们来告诉你怎么获得最高的生产力和影响力。
2018.11.23 北京 晴 异常冷