idea无法忍受

by Bruce Flow

通过布鲁斯流

不要成为无法忍受的软件开发人员 (Don’t be the software developer you can’t stand working with)

I have more than 10 years of industry experience as a software developer. I am working at one of the largest tech companies. I have also worked as a Scrum Master in multiple projects.

作为软件开发人员，我有十多年的行业经验。 我在最大的科技公司之一工作。 我还曾在多个项目中担任Scrum Master。

By no stretch of the imagination am I the most experienced developer out there. Yet, I have worked with enough software developers to recognize that I enjoy working with some developers much more than others.

毫无疑问，我是最有经验的开发人员。 但是，我已经与足够多的软件开发人员一起工作，以认识到与其他开发人员相比，与其他开发人员合作的乐趣更大。

The developers that I enjoy working with are the ones that collaborate well with me. They are professional yet pleasant. Their friendly competition pushes me to be a better developer every day.

我喜欢与之合作的开发人员是与我合作良好的人。 他们很专业但是很愉快。 他们的友好竞争促使我每天成为更好的开发人员。

And there are developers that annoy the heck out of me.

还有一些开发人员使我烦恼。

I did a breakdown of the characteristics of these difficult developers. It is not a list of rants. I made the list to learn from it for my own personal development. I also use the list to check myself from time to time as a means of professional self-reflection.

我对这些困难的开发人员的特征进行了细分。 这不是名单。 我列出了要从中学习的列表，以进行个人发展。 我还使用该列表不时检查自己，作为专业自我反省的一种方式。

The following is a list of annoying things software developers do. For every characteristic, I also provide suggestions of what we can do instead.

以下列出了软件开发人员所做的烦人的事情。 对于每个特征，我还提供了我们可以做些什么的建议。

Craft.io草率 (Having sloppy craftsmanship)

You know that developer. That developer that names variables, has typos in function names, and leaves remnants of old comments in the code. That developer that can’t bother to run the code formatter despite being told 5 times. The developer that ignores lint issues even when the IDE screams at them.

你知道那个开发商。 那个命名变量的开发人员，在函数名称中有错别字，并且在代码中留下了旧注释的残余。 即使被告知5次，该开发人员仍然不愿意运行代码格式化程序。 即使IDE对它们发出尖叫，开发人员也不会理会它们。

Having sloppy craftsmanship annoys other developers. It also slows the development process down. In code reviews, other developers have to waste time commenting on glaring issues that should have been fixed during coding. In other cases, other developers have to fix these problems themselves.

马虎的手Craft.io惹恼了其他开发人员。 这也减慢了开发过程。 在代码审查中，其他开发人员不得不浪费时间评论在编码过程中应该解决的明显问题。 在其他情况下，其他开发人员必须自己解决这些问题。

Even worse, the lackadaisical attitude increases the chances of having bugs in the software. Bugs cost money and time to fix down the line.

更糟糕的是，缺乏狂热的态度会增加软件中存在错误的机会。 错误花费金钱和时间来解决问题。

I get frustrated with sloppy craftsmanship because it is a question of attitude. That that can only change if that sloppy developer decides to take pride in their work.

我对草率的手Craft.io感到沮丧，因为这是态度的问题。 只有当那个草率的开发人员决定以他们的工作为荣时，这种情况才能改变。

As software developers, we have much freedom to choose how we do things.

作为软件开发人员，我们拥有选择我们做事方式的自由。

Using this freedom to hone our skills is hard work. It is easier to just coast. Nevertheless, there are major long-term payoffs.

利用这种自由来磨练我们的技能是艰苦的工作。 滑行比较容易。 尽管如此，仍有大量的长期收益。

“Without craftsmanship, inspiration is a mere reed shaken in the wind”

“没有技巧，灵感就只是在风中摇曳的芦苇。”

“Without craftsmanship, inspiration is a mere reed shaken in the wind”

“没有Craft.io，灵感就只是芦苇在风中摇曳”

Taking pride in our craftsmanship makes us increasingly better at what we do. It also inadvertently helps us derive more satisfaction from our work. Getting better at what we do opens up more opportunities in the future.

以我们的手艺而自豪使我们在做事上变得越来越出色。 这也无意间帮助我们从工作中获得更多的满足感。 在我们的工作上做得更好，为将来打开更多的机会。

不尊重别人的时间 (Being disrespectful of others’ time)

There’s that developer who comes late to meetings on a constant basis. Everyone is late once in a while. Yet, coming in late all the time is choice.

有一个开发人员经常迟到会议。 每个人偶尔都会迟到。 然而，总是迟到是一种选择。

Depending on the importance of that developer in that meeting, two things could happen. The team will either have to wait for the developer or have to spend time bringing them up to speed on what they have missed.

根据该开发人员在该会议中的重要性，可能会发生两件事。 团队要么必须等待开发人员，要么必须花费时间使他们加快他们错过的事情的速度。

Habitually coming in late to meetings is a blatant disrespect to others. It might not seem like a big deal if you come in a few minutes late, but here’s my rough formula to calculate the time wasted:

习惯迟到开会是对他人的公然蔑视。 如果您迟到了几分钟似乎没什么大不了的，但是这是我用来计算浪费时间的粗略公式：

Total time waste = n x (t1 + t2)n = number of peoplet1 = time late to meetingt2 = time wasted bring the developer up to speed

Example scenario:

示例场景：

A team has six developers. One developer shows up 10 minutes late. The team takes five minutes to bring them up to speed. The total time loss would be 6x(10+5) minutes. That would be a total of 90 minutes wasted.

一个团队有六个开发人员。 一位开发人员迟到了10分钟。 团队需要五分钟来使他们加速。 总的时间损失将是6x(10 + 5)分钟。 那将总共浪费90分钟。

Coming late to meetings disrupts the flow of the meeting. Other colleagues might be having a productive discussion when the late developer interrupts.

开会迟到会打乱会议的流程。 当已故的开发人员中断时，其他同事可能会进行富有成果的讨论。

Punctuality is an attitude.

守时是一种态度。

Having the attitude of punctuality saves everyone’s time and nerves. Besides, it also gives the positive impression of reliability. Showing up at every meeting on time means we give a damn. It means the chances are higher that we give a damn about delivering our work on time, too.

守时的态度可以节省每个人的时间和神经。 此外，它也给人以可靠性的正面印象。 准时出现在每次会议上都意味着我们该死。 这意味着我们也很可能准时交付工作。

忽略工作的非代码方面 (Disregarding non-code aspects of work)

There are times that I hear a developer say “The UI I built is ugly because I am not a designer”. This makes me want to get into Hulk mode and flip my standing desk.

有时候我听到开发人员说“我构建的UI很丑，因为我不是设计师”。 这使我想进入绿巨人模式并翻转我的站立式办公桌。

Coding is just one of the responsibilities of the developer.

编码只是开发人员的职责之一。

To be good at software development means that we adopt a holistic approach to our work. We should also consider aspects like user experience, architecture, and business strategy.

擅长软件开发意味着我们对工作采用整体方法。 我们还应该考虑用户体验，体系结构和业务策略等方面。

To think that software development is merely about coding is like saying you can drive because you know how to step on the gas pedal.

认为软件开发仅与编码有关，就像说您可以驾驶，是因为您知道如何踩油门踏板。

Ignoring the big picture will make the software hard to use, expensive to maintain, and inconsistent with the other components.

无视大局将使软件难以使用，维护成本高昂且与其他组件不一致。

It is our responsibility as software developers to educate ourselves in all aspects. Granted, we cannot be experts in all fields. The important thing is to have adequate awareness. We can always request the help of experts when needed.

作为软件开发人员，我们有责任在各个方面进行自我教育。 当然，我们不能成为所有领域的专家。 重要的是要有足够的认识。 我们随时可以在需要时寻求专家的帮助。

Having a holistic view of things will also allow us to understand other roles better.

从整体上看待事物也可以使我们更好地理解其他角色。

When I engage in discussions with designers, I make it a habit to learn how design decisions are made. I do it by asking questions. This improves my basic understanding of design principles.

当我与设计师进行讨论时，我习惯于学习如何制定设计决策。 我通过提问来做到这一点。 这提高了我对设计原理的基本理解。

Learning to see the bigger picture better is a continuous process. A process driven by curiosity and the commitment to produce good work.

学会更好地看到更大的图景是一个连续的过程。 一个由好奇心和做出好的工作的承诺驱动的过程。

谈论借口而不是解决方案 (Talking about excuses instead of solutions)

Everyone has a bad patch at some point. Sometimes, it takes longer to produce the results we want. This is totally fine. It is not fine when a developer constantly produces excuses instead of results.

每个人在某个时候都有一个不好的补丁。 有时，需要更长的时间才能产生我们想要的结果。 很好 当开发人员不断产生借口而不是结果时，这是不好的。

Typical excuses include time constraints, inadequate knowledge, or task difficulty.

典型的借口包括时间限制，知识不足或任务困难。

Producing excuses on a constant basis has zero positive effect on the team. It wastes time at best. In the worst case, it lowers the bar of excellence in the team.

不断产生借口对团队的积极影响为零。 充其量只是在浪费时间。 在最坏的情况下，它会降低团队的卓越水平。

Instead of excuses, I prefer to hear about the specific steps the developer has already taken.

我更希望听到有关开发人员已经采取的具体步骤的解释，而不是找借口。

This has many benefits:

这有很多好处：

• Gives the team a better chance to offer help or solutions使团队有更好的机会提供帮助或解决方案
• Allows the team to learn from the problem允许团队从问题中学习
• Provides a better picture of the task progress提供更好的任务进度图

Talking about solutions is what we do. After all, we are engineers. Engineers solve problems.

谈论解决方案是我们要做的。 毕竟，我们是工程师。 工程师解决问题。

对未知事物进行哲学思考而不是找出问题所在 (Philosophizing about the unknown instead of figuring out the problem)

On many occasions, colleagues argue technical topics based on their opinions. Opinions that are not backed by any facts.

在很多情况下，同事会根据自己的观点来辩论技术主题。 没有任何事实支持的观点。

Such lengthy discussions can be ended by finding out the facts instead of arguing about it.

这样的冗长讨论可以通过发现事实而不是争论来结束。

“Truth is ever to be found in simplicity, and not in the multiplicity and confusion of things.”

“真理总是在简单中找到，而不是事物的多重性和混乱性。”

“Truth is ever to be found in simplicity, and not in the multiplicity and confusion of things.”

“真理总是在简单中发现，而不是事物的多重性和混乱性。”

In software development, we deal with both technical and non-technical issues.

在软件开发中，我们同时处理技术和非技术问题。

With the technical issues, we have the luxury that things are usually black and white. Any disputes can be resolved by trying out code in a sandbox or running a piece of software to check what it does.

面对技术问题，我们可以奢侈地做到事物通常是黑白的。 通过在沙盒中试用代码或运行软件检查其作用，可以解决任何争端。

Non-technical issues are resolved by reading the documentation, asking subject experts, or googling.

通过阅读文档，咨询主题专家或使用Google搜索，可以解决非技术性问题。

抱怨并带有消极情绪 (Complaining and having an aura of negativity)

Most developers I have worked with are positive and enthusiastic people. Maybe that is why working with negative developers bugs me so much.

与我合作的大多数开发人员都是积极积极的人。 也许这就是为什么与负面的开发人员合作会困扰我太多的原因。

Negativity is infectious. If someone complains, it focuses the attention on the negative side of things. Others will be inclined to adopt the same attitude.

负性具有传染性。 如果有人抱怨，它将注意力集中在事物的消极方面。 其他人则倾向于采取相同的态度。

“Negativity is the enemy of creativity.”

“否定性是创造力的敌人。”

“Negativity is the enemy of creativity.”

“否定性是创造力的敌人。”

Of course, it is not all roses in software development. There are hard times. We do sometimes have to work with legacy code from the dark ages or with tools that have the performance of a sloth.

当然，这并不是软件开发中的所有玫瑰。 有困难时期。 有时，我们确实不得不使用黑暗时代的遗留代码或具有懒惰性能的工具。

It is better to ask ourselves what we can control instead of reiterating what we cannot change.

最好问问自己我们可以控制什么，而不是重申我们不能改变的东西。

We can allocate resources for code refactoring or write documentation. We can find out if we can tweak the memory settings of slow tools to speed them up.

我们可以分配资源进行代码重构或编写文档。 我们可以找出是否可以调整慢速工具的内存设置以加快速度。

在会议上乱逛 (Rambling on in meetings)

In meetings, I see eyes rolling back when “that developer” rambles on and on.

在会议上，当“那个开发人员”不断走来走去时，我回头看。

Like any other profession, verbal communication is one of the key soft skills we have to learn.

像其他任何职业一样，口头交流是我们必须学习的关键软技能之一。

When communicating, getting straight to the point works wonders. Colleagues will understand us and the situation better.

交流时，直截了当就能创造奇迹。 同事会更好地了解我们和情况。

One communication pet peeve of mine is when a developer talks to non-coders using jargon. Designers sometimes pretend to nod when a developer rambles on about JavaScript intricacies. Anything to get them to stop talking.

我的一个交流烦恼是开发人员使用行话与非编码人员交谈。 当开发人员大谈JavaScript复杂性时，设计师有时会假装点头。 让他们停止说话的任何方法。

Knowing whom you are talking with and speaking in their lingo is common sense. Sometimes, common sense is not common.

知道您正在与谁交谈并用他们的语言说话是常识。 有时，常识并不常见。

为自己偷信用 (Stealing credit for yourself)

Once in a while, I will see a developer stealing credit for the work produced by a team effort. They would write an email to management advertising the feature or talk about a task as if they had done it alone.

偶尔，我会看到开发人员因团队合作所产生的成果而功不可没。 他们会写一封电子邮件给管理层，以宣传该功能或谈论一项任务，就好像他们是独自完成一样。

More often than not, this is communicated in a sneaky non-straightforward way. The credit taking statements are cleverly implied.

通常，这是以偷偷摸摸的，非直截了当的方式传达的。 巧妙地暗示了信用声明。

Such strategies might produce short-term visibility for that individual.

这样的策略可能会对该人产生短期可见性。

In the long run, such developers will be alienated. This is done either by choice or subconsciously. Other team members will evolve their communication to highlight their contributions better.

从长远来看，这样的开发商将被疏远。 这是通过选择或潜意识完成的。 其他团队成员将发展他们的沟通，以更好地突出自己的贡献。

It would make much more sense to give credit to others when it is due. No need to overdo it. But I’m saying give due credit.

在适当的时候给予他人荣誉会更有意义。 无需过度操作。 但我是说应有的信誉。

There are many ways to give credit. We can mention the colleague’s contributions during Daily Scrum. We can thank the colleague via email and copy their manager.

信用有很多种方法。 我们可以提到同事在每日Scrum期间的贡献。 我们可以通过电子邮件感谢同事并复制他们的经理。

There are myriad benefits of giving due credit:

给予应有的信誉有很多好处：

• You feel good because you are honest.因为诚实，所以感觉良好。
• The contributing colleague feels acknowledged.有贡献的同事感到被认可。
• Allows the manager to have a more accurate impression of the colleague.使经理对同事有更准确的印象。
• The team has a better picture of skill sets of individuals.团队对个人技能有更好的了解。

Thus, let us be aware of when to give or take credit.

因此，让我们知道什么时候给予或给予信贷。

结论 (Conclusion)

The path to becoming a better developer is a never-ending process. Sometimes, it makes sense to take a stop on that path to reflect on how we do things. The art of professional self-reflection helps us correct our course. Becoming better at our trade increases our level of contentment with what we produce.

成为更好的开发人员的道路是一个永无止境的过程。 有时，在那条路上停下来反思我们的做事方式是有意义的。 专业的自我反省的艺术可以帮助我们纠正路线。 在我们的贸易中变得更好会提高我们对所生产产品的满足程度。

Let us be the software developer we love to work with.

让我们成为我们喜欢与之合作的软件开发人员。

翻译自: https://www.freecodecamp.org/news/dont-be-the-software-developer-you-can-t-stand-working-with-3f608c0cb00a/

idea无法忍受