同情機器人
Empathy is one of those things that can help in any part of life whether it’s your family, friends, that special person and even also at work. Understanding what empathy is and how it effects people took me long time. I struggle with human interactions and I am not ashamed to admit it, so I wanted to share my experience, as to what I have found from all of it.
同情是可以幫助生活中任何部分的事物之一,無論是您的家人,朋友,那個特殊的人, 甚至在工作中。 了解同情是什么以及它如何影響人們,我花了很長時間。 我在與人之間的互動中掙扎,我不為自己的接受而感到羞恥,所以我想分享我的經驗,以及從所有事物中發現的東西。
I am full stack javascript developer. I love code. Javascript is my favorite language and for as long as I can remember I have considered my self as a one-man-army. I get the part where you have to say this in your interviews: “I am a team player & a people person”, and I have said that. But the truth is I am not and rather I am learning as I go.
我是全棧javascript開發人員。 我喜歡代碼。 Javascript是我最喜歡的語言,并且只要我記得我就一直將自己視為一個單兵。 在采訪中, 我要說的是 : “我是一個團隊合作者和一個人”,我就是這么說的。 但是事實是我不是,而是我正在學習。
The biggest thing I have realized is throughout your experience, what will matter is the lives you have impacted. The relationships you have built. I promise you tech stacks will change and you’ll grow old eventually. Programming might not be a suitable career choice at some point for whatever reason. What will matter at the end is the relationships you’ve built along the way.
我認識到的最大事情就是您的整個經歷,重要的是您受影響的生活。 您建立的關系。 我保證您的技術堆棧會發生變化,并且最終會變老。 出于某種原因,在某些時候編程可能不是一個合適的職業選擇。 最后重要的是您在此過程中建立的關系。
什么是同理心? (What is empathy?)
Empathy is the ability to understand and share the feelings of another. It is the act of putting yourself in others’ shoes and seeing a problem from their point of view.
同理心是理解和分享他人感受的能力。 這是使自己陷入困境并從他人的角度看問題的行為。
In my day work, I get to be a team lead and I get to be responsible for some really genuine and brilliant people. All of them are diverse and bring something unique to the table. Some are fresh in the industry others are experienced. The only way I can develop a really good and productive team who are in sync with each other and at the best of their abilities, is if I can understand their issues from their POV. Whether it is with code or something else.
在我的日常工作中,我要成為團隊負責人,并對一些真正真誠和才華橫溢的人負責。 它們都各不相同,并為餐桌帶來了獨特之處。 有些是行業內新鮮的,有些是經驗豐富的。 我可以建立一個真正優秀和富有生產力的團隊的唯一方法是彼此協作,并盡其所能,這就是我可以從他們的POV中了解他們的問題。 無論是代碼還是其他東西。
移情會帶來什么好處? (What good will empathy do?)
There are so many benefits of having empathy, so I’ll just state a few. The end result of it is
擁有同理心的好處很多,所以我只列舉一些。 最終結果是
a happy team
一個快樂的團隊
a well groomed end-product
精心修飾的最終產品
good work culture.
良好的工作文化。
So, like many other problems we face as software engineers, we tend to solve problems by devising an algorithm. Here is “pseudo code” for empathy.
因此,就像我們作為軟件工程師面臨的許多其他問題一樣,我們傾向于通過設計算法來解決問題。 這是移情的“偽代碼”。
1- better understanding of your colleagues: If you understand them better., you can help them better.
1-更好地了解您的同事:如果您更好地了解他們,則可以更好地幫助他們。
2- The unsaid things: Your team might not share everything with you. Based on their body-language, tone, voice, you will have a better idea of their situation.
2-未說的事情:您的團隊可能不會與您共享所有內容。 根據他們的肢體語言,語氣,聲音,您會更好地了解他們的處境。
3- Resolving conflicts: When you understand the unsaid things, you can address them and make your team members feel heard. This is the first step of resolving a conflict.
3-解決沖突:當您了解未說的內容時,您可以解決這些問題并使您的團隊成員感到被聽到。 這是解決沖突的第一步。
I have always said this: the first point of solving any problem is knowing what the problem is.
我一直這樣說:解決任何問題的第一步就是知道問題是什么。
4- Getting empathy back from your team: There are times when you have to be straight with the team. Maybe your team is slacking, not working effectively or maybe a deadline is closing in and you have to ask them to work overtime a bit (there are some days when the client comes first).
4-從團隊中獲得同情:有時候,您必須與團隊保持直率。 也許您的團隊有些懈怠,工作效率低下,或者截止日期臨近,您必須要求他們加班(有些時候客戶是第一位的)。
In such cases your team might mistrust your intentions. But if you have some inclination of their understanding behind their motivation and point of view, it becomes a bit simpler to gain their trust and convince them of your point of view.
在這種情況下,您的團隊可能會懷疑您的意圖。 但是,如果您對他們的動機和觀點有所了解,那么獲得他們的信任并說服他們相信您的觀點會變得更加簡單。
Before you know it, you will somehow become more in tune with your team’s needs. Not a clairvoyant to be exact, but you will somehow be able to predict your team’s follow up questions and answer them better. You will also be able to understand what is holding them back from their true potential
在不知不覺中,您將以某種方式變得更加適應團隊的需求。 確切地說,這不是千篇一律,但您將能夠以某種方式預測團隊的后續問題并更好地回答。 您還將能夠了解是什么阻礙了他們的真正潛力
工作場所的同理心 (Empathy at the workplace)
It is without any doubt that empathy can help in any kind of job that involves people, and our tech industry is no exception. This is valid even if you work remotely because the messages you see in the chat room are not from bots but from actual people sitting on the other side of the computer.
毫無疑問,同情心可以幫助任何涉及人的工作,我們的科技行業也不例外。 即使您是遠程工作,這也是有效的,因為您在聊天室中看到的消息不是來自漫游器,而是來自坐在計算機另一側的實際人員。
One frequent situation where we can forget about empathy is during a code review, which I talk about below.
我們經常會忘記同理心的一種常見情況是在代碼審查期間,我在下面討論。
Another problem is when 2 people from different teams need to work together to solve a problem or work on a feature. This can produce an “us versus them” attitude. This can be the case if the teams are from different domains or if it’s the same team divided working from different geographic locations.
另一個問題是,來自不同團隊的2個人需要一起解決問題或處理某個功能。 這可能會產生“我們與他們對抗”的態度。 如果團隊來自不同的領域,或者是來自不同地理位置的同一個團隊,那就可能是這種情況。
A variant of “us versus them” can be “developer versus quality assurance” or “developer versus project managers”. What happens is developers end up taking a very defensive stance against managers, and we (developers) don’t try hard enough to understand their side of story (managers/QA). Getting to know the other side would certainly help to empathize with them. If we can somehow understand what they do, why they do it, it will certainly help in building a better relationship.
“我們與他們”的變體可以是“開發人員與質量保證”或“開發人員與項目經理”。 發生的事情是開發人員最終對管理人員采取了非常防御的態度,而我們(開發人員)沒有盡全力去理解他們的故事(經理/質量保證)。 認識對方肯定會幫助他們。 如果我們能以某種方式了解他們的工作,為什么這樣做,那肯定會有助于建立更好的關系。
Daniel Westheide has written an excellent article called “The Empathic Programmer.” Do read it at your pleasure.
丹尼爾·韋斯海德(Daniel Westheide )撰寫了一篇出色的文章,名為《 同情程序員》 。 請隨便閱讀。
讓我們從更好的代碼審查開始 (Let’s start with better code reviews)
Before we start off with better code reviews, it is so important to make your team realize what a “Prime Directive” is:
在我們開始進行更好的代碼審查之前,讓您的團隊意識到什么是“首要指令”非常重要:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” –Norm Kerth
無論我們發現什么,我們都理解并真正相信,鑒于他們當時所知道的,他們的技能和能力,可用的資源以及當前的狀況,每個人都盡了最大的努力。” –Norm Kerth
Once this attitude is established and realized by your team, it does 2 things: First, the person reviewing the code knows that their job is not to judge the person who wrote the code, but rather to make improvements on the code. And second, the person who is getting their code reviewed knows that the feedback they are getting is not a personal attack on them, but an opportunity for growth.
一旦您的團隊確立并實現了這種態度,它就會做兩件事:首先,檢查代碼的人知道,他們的工作不是判斷代碼的編寫者,而是對代碼進行改進。 其次,正在審核其代碼的人知道,所獲得的反饋不是對他們的人身攻擊,而是成長的機會。
I strongly believe the only way of growing is when you get feedback.
我堅信,增長的唯一途徑就是獲得反饋。
更好地塑造我們的語言 (Better shaping our words)
Words, if chosen carefully, can either make this world a better place to live in or hell. It is not guns and ammo. Words are, I believe, the most dangerous weapon at our disposal. Let’s consider the following comment:
如果謹慎選擇話語,可能會使這個世界成為一個更好的生活場所或陷入地獄。 不是槍支彈藥。 我認為,言語是我們可以使用的最危險的武器。 讓我們考慮以下評論:
This is the wrong way to structure test, it handles way to many use cases altogether
這是結構測試的錯誤方法,它對許多用例都進行了處理
We could instead say something like this:
我們可以這樣說:
I think for better readability we can divide these tests into separate modules. Here is a reference from http://some-dummy-reference/example
我認為,為了提高可讀性,我們可以將這些測試分成單獨的模塊。 這是來自http:// some-dummy-reference / example的參考
Another example of a more negative comment like this would be:
這樣的負面評論的另一個例子是:
These 3 lines belong in a separate method.
這3行屬于單獨的方法。
Instead, we can tweak our words a bit and say:
取而代之的是,我們可以稍微調整一下措詞,然后說:
What do you think of extracting these lines into a separate method, to handle calculations separately?
您如何將這些行提取到單獨的方法中以分別處理計算結果呢?
This gives the other person some power and makes them feel that their opinions matter and that they have a say in this matter.
這給了對方一些力量,使他們覺得自己的意見很重要,并且對此事有發言權。
可以有意見 (It is okay to have opinions)
People who know me can vouch for the fact that I argue a lot and I strongly believe in this. Being a software engineer, everything should be 0’s & 1’s. Think of yourself in The Matrix with the chosen one (Neo).
認識我的人可以保證我會爭論很多,我對此深信不疑。 作為軟件工程師,一切都應該為0和1。 在所選的《黑客帝國》(Neo)中想想自己。
So let’s say there is a conflict about anything, perhaps deciding to go for a design pattern A rather than design pattern B, where I am in favor of the latter option. I need to come up with a reason for why I believe my suggested option will work better with the use case that is presented to us.
因此,假設存在任何沖突,也許是決定采用設計模式A而不是設計模式B,我贊成后者。 我需要提出一個理由,說明為什么我認為我建議的選項可以更好地與呈現給我們的用例一起使用。
It is easy to accept and go with the flow, while saying NO is hard because people will argue with you about it. So you need to know why the option you support is better than the one proposed by the team. I honestly love this kind of culture where the team can have a meaningful discussion about choosing design approaches. That is what I believe engineering is all about.
很容易接受并順其自然,但說“不”很困難,因為人們會與您爭論。 因此,您需要知道為什么您支持的選項比團隊提出的選項更好。 老實說,我喜歡這種文化,團隊可以就選擇設計方法進行有意義的討論。 我認為這就是工程的全部意義。
整理您的論點 (Organizing Your Arguments)
If the code review that you are having is about style, like tabs vs spaces or about extra white space etc, then that means your team isn’t well aware of the style guide being followed in your project. And a PR comment isn’t a valid place to have that argument.
如果您所進行的代碼審查與樣式有關,例如制表符與空格或多余的空白等,則意味著您的團隊不太了解項目中要遵循的樣式指南。 公關評論不是有該論點的有效地方。
You can maybe integrate some cool linting tools to automate this process, like EsLint. I wrote an article earlier about writing clean code called These tools will help you write clean code?—?check it out.
您也許可以集成一些很酷的整理工具來自動化該過程,例如EsLint 。 我之前寫過一篇有關編寫干凈代碼的文章,名為“ 這些工具將幫助您編寫干凈的代碼 -進行檢查”。
If, on the other hand, the code review comments are too high level, the commentator does have the right to clarify his opinion. But a better place to have this discussion is on a piece of paper before implementing the code itself. Final code review shouldn’t be an optimal place to discuss how to tackle the problem.
另一方面,如果代碼審查注釋的等級太高,則注釋者確實有權澄清其意見。 但是,在實現代碼本身之前,最好在紙上進行討論。 最終代碼審查不應是討論如何解決問題的最佳場所。
沒照顧 (Failing to care)
Another problem with code reviews is people don’t care about them (I used to be one of them, until someone wrote bad code in my code. Never again.)
代碼審查的另一個問題是人們不關心它們(我曾經是其中的一個,直到有人在我的代碼中寫了不好的代碼。 再也不來了。 )
I can understand. The code reviews are not the most fun part of the job. But they are the most important part. The part where it becomes really difficult is when you have a very big PR to approve?—?and I have put my team in that position more times then I can count. But it has been for important reasons. An ideal situation is to keep your PR as small as possible so the code review is easy and not hard on the eyes.
我能夠了解。 代碼審查不是工作中最有趣的部分。 但是它們是最重要的部分。 真正困難的部分是當您需要批準大量公關時,而我讓我的團隊在該職位上的任職次數超過了我可以數的時間。 但這是有重要原因的。 理想的情況是使PR盡可能小,這樣代碼審查就容易而又不費勁。
If a big code review needs to happen, you can let your team know before hand and do it altogether as a fun exercise. Think of it as a team building activity.
如果需要進行大型代碼審查,則可以先讓您的團隊知道,然后進行一次有趣的練習。 將其視為團隊建設活動。
To make this problem a bit more approachable, maybe you can present the code reviews in a better way:
為了使此問題更容易解決,也許您可??以采用更好的方式呈現代碼審查:
- attach screenshots of before and after the PR 附加PR之前和之后的屏幕截圖
- explain what the PR does and give context on the background 解釋PR的作用并提供背景信息
- give references on your approach 提供有關您的方法的參考
- be ready for feedback?—?what doesn’t break you only makes you stronger 準備好接受反饋-不會破壞您的東西只會使您變得更堅強
April Wensel has a brilliant article on this called “3 Code Review Pitfalls and How to Avoid Them”.
April Wensel在這方面有一篇出色的文章,名為“ 3 Code Review陷阱和如何避免它們 ”。
So let’s promise be kind, be humble, and be the hardest working person in the room.
因此,讓我們保證要仁慈,謙虛并成為會議室中最努力的人。
結語 (Wrapping up)
No one is born with talent, it is all hard work. The reason someone is where they are is because they had the guts and the persistence day in and day out. If you want to be good at something you need to practice it. Empathy is like that as well. You need to practice it everyday to be good at it. Simple as that.
沒有人是天生的,這是所有的努力。 某人之所以在這里的原因是因為他們日復一日地擁有勇氣和毅力。 如果您想擅長某事,則需要練習。 同理心也是如此。 您需要每天練習以精通它。 就那么簡單。
So let’s sum it up;
因此,讓我們總結一下;
- Put yourself in your team members’ shoes, and try to understand things from their point of view. 把自己放在團隊成員的鞋上,并嘗試從他們的角度理解事物。
- Be active in asking questions. If you see your team member down, just ask them about the issue. Asking them shows that you are invested in their well being and happiness. 積極提問。 如果您看到您的團隊成員感到沮喪,只需向他們詢問該問題。 向他們詢問表明您對他們的幸福和幸福有所投入。
- Stop judging people. Everyone is here to work to make a good living and support themselves and their loved ones. If you get a feedback from someone, think of it as a constructive criticism and improve yourself. 停止評判人。 每個人都在這里工作,以過上幸福的生活,并養活自己和親人。 如果您收到某人的反饋,請將其視為建設性的批評并改善自己。
- Share the load if your team is overwhelmed. Jump in help them out. Give them an extra hand. If it is in your hands, maybe give them a day off so they can rest. This way they know that you as a team lead appreciate them for your hard work. 如果您的團隊不堪重負,請分擔負擔。 跳進來幫助他們。 給他們更多的幫助。 如果在您的手中,請給他們休息一天,以便他們休息。 這樣,他們知道您作為團隊的領導者會感謝他們的辛勤工作。
- Try to learn about how to be empathetic in your free time. Personally, books have helped me a lot and there is such good content on the internet if you want to read up. 嘗試了解如何在空閑時間變得富有同情心。 就個人而言,書籍對我有很大幫助,如果您想閱讀,互聯網上有如此好的內容。
- Be attentive and a keen listener. You don’t always have to speak. Sometimes just being there and listening helps. 細心和敏銳的聽眾。 您不必總是講話。 有時候,只是在那里,聆聽會有所幫助。
- And most of all, GIVE RESPECT! To everyone?—?your seniors and juniors, everyone! That includes the janitor in the same building as the CEO. Every human being deserves respect. 最重要的是,給予尊重! 對于每個人-您的老年人和大三學生,大家! 其中包括與首席執行官在同一建筑物中的看門人。 每個人都應該得到尊重。
參考文獻 (References)
3 Code Review Pitfalls and How to Avoid Them (Read here)
3代碼審查陷阱以及如何避免它們(在此處閱讀)
A Guide to Empathy in Customer Service (Read here)
客戶服務移情指南(在此處閱讀)
The Empathic Programmer (Read here)
善解人意的程序員(在這里閱讀)
If you have liked this, share this with your colleagues. I love to hear your opinions. Reach me at twitter @ adeelibr
如果您喜歡這個,請與您的同事分享。 我喜歡聽聽您的意見。 在twitter @ adeelibr上與我聯系
翻譯自: https://www.freecodecamp.org/news/how-empathy-can-help-you-create-a-better-work-culture-c73d2ca15a70/
同情機器人