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.

讓我們成為我們喜歡與之合作的軟件開發人員。