不，這不是通常的情況。您遇到了相當普通的野獸，但是，《精英超級授權開發者》。他的頭腦比其他任何人都要聰明，並且出於同樣的原因也有權粗魯。他有些斧頭要對付莫蒂。盡可能避開他並繼續前進。

儘管他當然有權利親自調查問題，但文明的回答是“謝謝您的建議，我會調查一下。”兩者之間可能已經存在不良血液，或者他可能只是野性的，但是在兩種情況下，儘管這種行為在技術上並不為人所知，但這是不可接受的或“正常的”。

作為一名開發人員，我發現第一份報告非常有用。沒有冗長的解釋，也沒有冗長的valgrind痕跡可供閱讀。有了該修補程序，我可以立即看到問題所在，並且如果我最近使用該代碼，即使不檢查代碼，也可能知道它是否正確修復。因此，我只想回答“謝謝您抓住它”或“謝謝，不應共享該指針，但是我知道既然您引起了我的注意，應該解決該問題”或類似的東西。

此外，我在郵件中也沒有發現任何優越感。

現在，抄送每個人的狀況可能不好，也可能不會很糟。該代碼也可能是其他人所知道的，因此，如果CC收件人列表足夠短，則很好。郵件足夠簡短，每個人都可以立即從補丁程序中看到他們是否感興趣，只浪費了一點時間。但是，如果有些人不參與CC中的源代碼庫，那是不合適的。

另一個問題是，如果該人應該花時間來調試這樣的問題。但是，除非他們未能達到自己的目標，否則像這樣承擔整個軟件的責任通常是非常非常有價值的特徵。它顯示出熱情和關懷，真是難得的事情。這些事情可能做得太過分了，但是看到隊友更關心其他人的代碼中的錯誤，除非它直接影響了他們，這是非常普遍的。

要回答標題問題。在我看來，莫蒂的語氣是專業和正常的。 cks的音調...不幸的是也不是那麼不尋常，但這很不幸。但是，我們所有人的日子都不好過，因此我將不再分析單個匿名消息。這可能是一個不好的信號（看起來像是TBH），或者它可能只是您需要習慣的相當體面的工作場所文化的一部分。

我知道問題已經回答，並且我同意接受的答案，但是我只是想用更多信息擴展它。

您在這裡看到的是一個潛在的 XY問題。在我看來，XY問題是每個問題解決者（不僅僅是程序員）都需要意識到和避免的事情。

XY問題的原理非常簡單：

• X是一個問題，需要解決。
• Y是解決方案，但不是最佳解決方案。無論如何，它都是被選擇的（通過懶惰或不了解有更好的解決方案）
• 當出現實施Y的問題時，人們會花時間嘗試使Y正常工作，而不是實際去那裡看是一個更合適的Z解決方案。

一個明顯的例子：

• X =我想對該Excel數據進行排序。
• Y =我可以編寫一個應用程序來對數據進行排序並保存文件。
• Z =我應該學習如何使用Excel的排序功能。

這從本質上講是莫蒂電子郵件中發生了什麼。 Rick無法將請求標記為Y或Z，因為Morty不會解釋X。解釋X比提供Y / Z解決方案更重要，因為Rick知道X時就能找到Z，但是他可以t 猜測 X無處不在。

這是X問題：

某些平台代碼中的內存洩漏

請注意，這很模糊。有什麼問題？它發生在哪裡？什麼時候發生的？

然後莫蒂提出了一個Y解。由於我們不了解X的細節，因此無法衡量Y是否是X的適當解決方案。

這就是為什麼里克將其推回去的原因。他被要求在沒有任何選擇的情況下更改某些內容（並有效地承擔了更改某些內容的責任）。 Morty有效地破壞了Rick的責任（編寫良好的代碼），並用對所提供的代碼適當且良好的盲目信任請求來代替。

這樣想：您是一個警官。一個男人走到你面前說：“我需要你逮捕那個男人”（Y）。

警察不應該遵守，因為他不能親自確認逮捕那個男人是有根據的。

但是，如果那個男人說“那個男人只是用冷血殺死了一個人”，那麼警官就能真正理解問題並自己決定解決方案（逮捕那個男人）。

這基本上就是莫蒂做錯了。我確實認為Rick可以更友好地措辭（如果這是Interpersonal.SE，我肯定會改寫Rick的一些句子），但是他的要求是有效的。

忽略兩者之間是否存在潛在的緊張關係，是一般的溝通問題還是您所在位置的標準語氣，我想集中討論您的問題：

這種語氣在技術工作場所？

否，這種語氣並非完全不同尋常。

1. 該行業的人們習慣於使用語法編程語言，確切的技術規範有時會忘記他們的交流語氣。通常，只要外部人不參與交流，這就不成問題。習慣了很多截然不同的消息。

2. 這是陳詞濫調，但是是的，還有一些書呆子的人社交能力很差技巧，因此您最好學會與他們打交道，而不要個人化。指出一些不可否認的錯誤是一回事-弄亂它只會觸發一些防禦機制。

ol>

這就是說，可以用一種更好的方法來完成。根據經驗，避免出現此類問題：

• 稱讚公眾，批評私人。
• 如果您遇到某人的麻煩，請不要為此使用電子郵件！
• 如果您發現錯誤，請通過標準的機制報告該錯誤。團隊。
• 除非被要求，否則不要做別人的工作。

有對他的感情有價值。我知道很多時候，我對根本原因的預感使某人走錯了道路，浪費了他們的時間。我認為嘗試利用這種力量是值得的。當我需要解決所卡住的錯誤時，我會盡量避免將自己的預感強加於他們，以使他們可能新穎而富有成果。他是個混蛋。

並非所有人都同意，但是IMO 這是正常的回答，請不要個人化。

這是一封易於理解的電子郵件，他激發了自己的動機為什麼他不喜歡聽您的解決方案（不是因為這是您的解決方案，而是因為他想以空白告終）。

對您而言，這不是私人的，或者侮辱或破壞，這是一種解釋。對於某些人來說這有點直接，但這通常是程序員敏捷，直截了當和（過於）事實。您可以用正常的語調閱讀整封電子郵件，他在其中解釋他的首選方法。僅僅因為您不喜歡它，並不意味著這是一種不好的做法，所以您會遇到很多與您工作有所不同的人。

我確實同意它可能有些措辭更加客氣地講，但是，程序員常常只是在沒有所有這些解釋的情況下說出他的意思（這不是藉口，但這可能是一種解釋）。

解決問題是他的工作，而不是你的您只是在一些事情上花了時間，否則就可以使用。不要誤會我，練習錯誤修復很重要！但是，研究應用的解決方案並將其與您的解決方案進行比較。您的解決方案可能似乎很好，但是經驗可能會告訴您其他情況。

雙方都是錯的。

在首封電子郵件中，Morty不應抄送所有人。這樣，他通過向所有人指出自己的錯誤使Rick感到尷尬。我不知道莫蒂是不是試圖通過這樣做來得分，還是他很愚蠢。但是，從Ricks的角度來看，結果是相同的。 Morty最好只將這封電子郵件發送給Rick，這樣他們就可以解決此問題，而不必讓任何人看上去都不好。

Rick尷尬的是，他的錯誤被公開指出並做出了嚴重的反應。他不應該放下莫蒂。他不應該公開批評莫蒂（Morty）試圖提供幫助。

一個電子郵件交換示例沒有告訴我們有關公司文化的任何信息。但是，如果發送公開電子郵件指出別人的錯誤，並發送電子郵件告訴人們他們不應該提供幫助，這很常見，因為這說明您有毒文化。

不幸的是，這種有毒文化在軟件中很常見公司在美國。就像寫的 [1] [2] [3]一樣，並談到了特定類型的軟件工程師對待他人的方式，尤其是非-軟件工程師和不適合他們的軟件工程師刻板印象的人。

這種文化不是對待人的正確方法。好的公司，經理和同事不容忍這種文化。好的員工不會公開指出彼此的錯誤，好的員工也不會忽略別人的幫助。

您需要弄清楚這種行為在您部門和公司的文化中是可以接受的。如果您認為自己所在的公司被接受，則需要確定是否認為自己可以改變文化，是否值得付出努力。需要弄清的重要一點是這種文化是否來自領導。如果領導層樹立一個壞榜樣，您將無能為力。如果這是基層文化，他們就有說服人們改變的機會。這將是一項艱鉅的工作，因此您最好決定該公司值得修復。

正常是相當主觀的，尤其是因為您對那個工作場所的歷史一無所知。

瑞克要么具有可怕的人際交往能力，要么這兩個人之間有些血腥。

Morty可能有意製造了一封“合理的”電子郵件，希望觸發Rick。

由於您是新來的，您將需要評估這種有毒行為是否也傳播到了其他人，或者是否是一種有毒行為。

無論發生什麼情況，都不要讓它傳播到您的個性中。

我是從經理的角度寫這篇文章的，他的經驗涵蓋了這種情況的多個方面。

科技公司的這種情況正常嗎？ / p>

這對於幾乎每個行業的任何公司來說都是正常的，而不僅僅是技術。

廣義上講，發送給開發團隊所有成員的電子郵件：

• 指出了一個可疑漏洞（“我認為我發現了內存洩漏...”）
• 聲明找到了一個授權的解決方案（“我相信我找到了來源和問題...”）
• 出示了一份洗衣清單要實施的修復程序

概括地說，這裡發生的是 Morty向Rick提供了一個指令，先建立該指令的合理性，然後逐項列出

該指令的詳細信息。

它使問題變得更加複雜，因為該指令是在組設置中給出的（抄送給所有e團隊）。

里克和莫蒂的組織關係

我們不知道這兩個人之間的關係。但是，通常可以將其概括為以下三種可能性之一：

• Rick高於Morty
• Morty高於Rick
• Rick and Morty相等

瑞克是否應該接受莫蒂的指示？

• 不？然後，Rick有理由推後退
• 是嗎？然後，無需抄送所有人。里克（Rick）在告訴莫蒂（Morty）他如何最好地完成自己的工作時仍然[em]仍然是有道理的。 >
  • 醫療。 Oz醫師告訴No醫師，他已經診斷出No醫師的病人，並且在不向No醫師提供症狀的情況下進行X，Y和Z檢查。
  • Automotive。工程師1告訴工程師2，工程師2的懸架設計中發現了一個問題，解決方法是將凸耳A焊接到插槽B，而沒有提供表明問題的測試數據
  • 技術支持-技術1告訴技術2，技術2的系統存在問題，解決方法是實施補丁A，B和C，而沒有提供表明問題的錯誤消息。

  TL; DR

  最重要的是，負責進行實際修復的人員正在告訴該人員他們需要正確完成這項工作。唯一可能“脫節”的人是Morty，因為他抄襲了所有人的被動攻擊行為。

  在每個行業中，每天都會發生這種情況。沒什麼新奇或異常。

  --- a / spaceship / DoBattle.cpp +++ b / spaceship / DoBattle.cpp vector<part>部件= getSpaceShipParts（）; + shared_ptr<SpaceShip> p =新的SpaceShip（零件）； -SpaceShip * p =新的SpaceShip（零件）；交戰（p，敵人）;  

不幸的是，此更改確實修復了該錯誤（假裝valgrind測試是無條件的），但是它引入了一些不必要的代碼哲學之爭。如果您不是常規的貢獻者，請不要參與代碼哲學之爭。

為避免哲學之爭，應該發送此文本。是的，從客觀上講，這是更糟的，但是它與已經存在的代碼風格保持一致：

  --- a / spaceship / DoBattle.cpp +++ b / spaceship / DoBattle.cpp SpaceShip * p =新的太空船（零件）；交戰（p，敵人）; + delete p;  

但是有了開發人員的回答，我認為他也不希望那樣。我聽到的這種語調太多了，即使是那些應該更了解的人也是如此。這是不正常的，但足以讓您聽到很多。我很失望。

1）交流：OP使cc開發團隊的其餘成員看起來像是標準做法。我從來沒有理由不將開發團隊的其他成員納入影響每個人的問題/解決方案中。

2）問題/解決方案：這裡沒有發現任何錯誤。

3）響應：太多錯誤導致我什至不知道從哪裡開始。
a ）“我沒有閱讀建議的修復程序”：絕對糟糕。始終閱讀建議的代碼。 b）“我必須等幾天才能提出解決方案”：讓我翻譯一下：“我必須等待在幾天前，我將完全忽略您所做的工作並放棄您的解決方案。我不僅會浪費時間來實施解決方案，而且還會浪費更多時間來為已解決的問題提出解決方案（通過您寫的代碼，我將丟棄）“
c）'查看真正的問題所在，並查看修復的內容'：測試。測試一下是否有問題。然後測試它，看問題是否解決。通過提出自己的需要測試的解決方案 而不是測試建議的解決方案以查看其是否可以解決所有問題，您將一無所獲。如果仍不能解決問題，您可以嘗試並提出建議的解決方案或解決問題的方法。

在我的公司中，立即將回復轉發給我的經理，且未加評論。根本無法接受。