為什麼軟體工程師或程式設計師脾氣暴躁？ -Human Who Codes

程式設計師是創造者，而不是建造或構造者
在大型和小型公司工作超過十年的軟體行業後，我得出了一個結論：軟體工程師對自己的看法與與他們一起工作的人截然不同。公司（產品經理，設計師，其他經理）傾向於將軟體工程師視為建造者。產品經理的工作是夢見要建造的東西，設計師要使它美化，程式設計師工程師要建造他們想出的東西。基本上，程式設計師工程師被視為這個行業的短期廚師。
當我工作的第一家公司倒閉時，我和經理就我的職業進行了坦率的討論。

尼古拉斯，您的價值要超過程式碼。不管您接下來的演出是什麼，請確保您不是臨時廚師。不要接受會告訴您確切要建造什麼以及如何建造的工作。您需要在某個地方工作，以欣賞您對產品的見識以及構建產品的能力。

他是絕對正確的。有很多公司想要短期廚師，他們希望實施者和建造者按照特定的節奏行事並保持一致。實際上，我會說大多數公司都希望這樣做，無論大小。我無法告訴您有多少家初創公司與我聯絡，提供股權以換取建立創始人的願景。含義：我們已經弄清了所有這些，我們只需要有人來構建它。
這是問題的真正癥結：軟體工程師不是構建者。軟體工程師是創造者。當您從宜家購買傢俱並將其帶回家時，構造就是您要做的事情。如何構造的說明書已經有了，只要按照其說明逐步進行，您會得到想要的那個可笑的小桌子。
建立是一個不同的過程，它在沒有指導或指示的情況下誕生了某些東西。它從一塊空白的畫布開始，然後繪製傑作。軟體工程師之所以一開始不會立即涉足編碼，是因為他們希望某人告訴他們該怎麼做，而因為他們發現自己可以創造出有用的東西而參與其中。每個軟體工程師就會都愛上了編碼，因為她很早就編寫了一個小巧而有用的程式，並且深深著迷。
在軟體，產品經理，設計師和軟體工程師的三足鼎立中，只有工程師才能放棄他們的創造力而只生產產品。軟體工程師並不愚蠢，他們看到這種情況的發生，並且怨恨開始形成（沒有雙關語）。工程師希望成為創意過程的一部分，並被拒絕。因此，您最終會遇到脾氣暴躁的典型軟體工程師個性。

等等，怎麼了？
產品經理是有趣的人。他們的想法和理解市場的能力令人印象深刻。他們也傾向於認為，實際上，如果存在很大的漏洞以至於火車可以透過，他們的想法才會完全形成。這絕對不是對產品經理的批評，只是他們的本性。他們的工作是富有創造力的，而想法並沒有形成完整的形式。這就是使軟體工程師脾氣暴躁的部分原因。
工程師和產品經理都傾向於錯誤地認為產品規格或要求等同於宜家的傢俱手冊。實際上，這些文件很少包含足夠的資訊來構建實際的東西。它們通常只是起點。這給工程師帶來了一個獨特的問題。
要了解該問題，請想想蓋房子的工作。有人決定他們要在特定的土地上蓋房子。這房子要是兩層樓，有一個車庫。甚至還有一張粗略的房子前部草圖，然後說：“這足以讓您開始構造了，對嗎？”您能夠開始構造嗎？
從邏輯上講，您此時無法開始建造房屋。您不知道平方英尺。您沒有平面圖。您不知道這座城市需要什麼樣的新房屋程式碼。字面上沒有足夠的資訊讓您甚至無法開始挖掘泥土。此時，您要告訴客戶他們瘋了，需要準確弄清楚他們想要什麼。現在想象您不能這樣做，因為有人設定了最後期限，您有責任開會。
“好吧，”您的客戶告訴您，“為什麼不立即開始構建，我將為您提供詳細資訊。這樣，我們就不會浪費任何時間。”
您知道沒有足夠的資訊來開始構建，並且進一步質疑客戶現在不會產生任何其他資訊。但是，您有一個限期開會，因此您真的負擔不起坐下來等待更多資訊的機會。你是做什麼？您開始進行假設。
古老的格言“當你假設的時候，你就和你我混在一起了”，這幾乎是正確的。假設很危險，而且常常是錯誤的。
但是，如果不做一些假設，該專案將無法進行。那就是你要做的。首先，假設您已經知道的是真實的，那所房子將有兩層樓和一個車庫。車庫，應該安裝還是分離？應該多大？好吧，讓我們保持簡單，並說它是分離的並且只容納一輛汽車。這意味著您可以作為側面的獨立結構從車庫開始，然後，在有關於房屋的更多詳細資訊時，可以在車庫旁邊繼續。
在車庫工作一個星期後，您的客戶出現了更多細節。實際上，房子必須是三層樓（phe，好東西，你不是從那裡開始的），並且要有八間浴室。沒有關於車庫的更多資訊，但是房子將被漆成藍色。然後，您從邏輯上認為獨立車庫也應被塗成藍色，這就是您接下來要花費時間的地方。
幾天後，車庫快要用完了。您對質量感到非常滿意，因為您獲得的資訊很少。現在，當客戶返回更多詳細資訊時，您就可以開始工作了。車庫實際上需要容納兩輛車，因此不應拆開。因為您創造了美好的事物，但您的內心深陷其中，現在需要推銷它，為“真實”的事物讓路。更糟糕的是，您現在沒有更多的時間來完成整個專案，這隻會增加工作量。

如果您覺得這種類比很瘋狂，那麼您可能從未以軟體工程師的身份工作過。這是我們每一天的現實。我們試圖透過使用創新工具來保持專案運轉，只是發現我們實際上無法讀懂任何人的想法，因此錯誤地猜測了我們正在構建的是什麼。但是，如果我們不這樣做，我們就會閒著，因為沒人喜歡軟體開發的瀑布式過程。
在幾乎所有其他建築行業中，都可以在開始建築之前就所有要求和細節達成一致並最終確定。除軟體外。在軟體中，“沒有足夠的時間”來提前收集所有需求。從第一天起，快速行動的重要性就已經紮根於我們。因此，工程師學會填補產品經理留下的空白，只是為了保持專案的進行。當然，產品經理也因經常改變主意而享有聲譽，這意味著工程師的假設經常在過程中途失效。
難怪軟體工程師會很快精疲力盡並經常更換工作嗎？

第一要務
任何建立者的敵人都是上下文的切換。一旦進入了深具創造力的模式，就如人們所說的那樣，被“流程”干擾將注意力轉移到其他事物上了，這將完全中斷當前流程。是的，編寫程式碼是一個創造性的過程。同時具有邏輯性和創造性。我們不僅在編寫程式碼，而且還在精心設計。
管理工程師時間的人們似乎認為，從一項任務轉移到另一項任務很容易。畢竟，正如某些人告訴我的那樣，努力就是努力。您只需將其定向到需要加農炮和火力的地方即可。當然，那根本不是真的。如果您在一個任務上花費大量時間，然後被要求將其放到其他任務上，那麼您將很難返回到第一個任務並從上次中斷的地方繼續工作。一旦您返回以確保您瞭解所有上下文，就會有一個重新適應的時期，這就是上下文切換的成本。即使完成新任務僅需幾分鐘，也足以中斷流程並因此降低工程師的工作效率。

這是使工程師脾氣暴躁的最重要的事情之一：不斷改變優先順序。如果某事物在一天中是第一優先順序，而其他事物在第二天是第一優先順序，則意味著必然發生上下文切換。創意型別不喜歡在完成之前就被打斷，這就是為什麼工程師樂於繼續編碼直到凌晨，以便完成他們正在做的工作。中斷流程使我們的生產力下降。

真正的優先順序不是暫時的，而是靜態的。在我們職位之上的人們改變主意的頻率對於軟體工程師來說實在令人沮喪。我們經常隨時準備進軍戰鬥，而只是想向前進。但是，如果您有一天告訴我們我們正在建造房屋，第二天我們正在建造汽車，那麼您應該期望正在此隊伍中。

工程師的缺陷
軟體工程師每天都處於困境中，但是即使我們中那些比較熟練的人傾向於這樣做，我們也不是受害者。我們的部分脾氣實際上來自內部，出於某種原因，大多數軟體工程師都已根深蒂固。我們有一個悲慘的缺陷，那個缺陷是我們高估了我們的知識和能力。
此缺陷以多種方式出現。最頻繁的是時間估計。我認識的幾乎每個工程師都長期低估了完成一項或多項任務所需的時間。只有最優秀的人才能夠給出並滿足準確的時間估算，而其他人有時卻相差兩個或更多。問題是，作為有創造力的人，軟體工程師無法預見他們將遇到的問題。
即使許多工程師會抱怨產品經理改變了主意，但幾乎沒有人會在他們的時間估算中做出解釋。沒有時間花在會議上來超過需求並進行更改。bug？我們的程式碼是完美的，並且從來沒有錯誤，因此我們不必擔心（畢竟，質量檢查會捕獲我們以某種方式錯過的任何東西，對嗎？）。我們依賴的其他一些工程師會退出市場嗎？沒關係，其他人會幫忙。
所有這些因素都會很快導致錯過的最後期限，但是沒有一個造成的傷害與未能按時完成任務的第一原因一樣嚴重：沒有考慮到學習的時間。這直接回到了我們的缺陷。我們認為我們已經知道如何完成給我們的任務，但是很多時候這是我們從未完成過的事情。時間估算反映出一種完美的知識狀態，您可以在其中獲得《宜家手冊》並向前邁進。實際上，許多工要求我們去做以前從未做過的事情。
在大學學習電腦科學的工程師在課堂上被賦予錯誤的安全感。當他們實際上幾乎一無所知時，他們以為自己瞭解軟體和軟體開發過程而出來。我絕對是第一份工作的傲慢大學畢業生，告訴每個人他們做錯了。僅僅幾年後，我才發現自己一無所知。
電腦科學程式並不是要為您準備好要在行業中面臨的任務做準備。它們是關於為您提供廣泛主題的概念性知識，以便您在工作中找到它們時不會失明。您將瞭解變數，函式和物件，因為這些是您始終會遇到的事情。您將學習資料庫和查詢，儘管所學的常規形式實際上是無用的。您花了大量的時間在排序演算法和資料結構上，而在專業編寫程式碼時，所有這些演算法和資料結構都是抽象的。簡而言之，電腦科學程式會審查解決問題的解決方案，而這些問題在您進行專業編碼時就不需要自己解決。如果這些天我需要排序一些東西，請呼叫sort()方法。如果我需要一個佇列或一個連結串列，那麼我將使用所使用語言的本地實現。這些都是已解決的問題。
因此，我們來自大學時代，我們知道如何做所有事情，而實際上我們只知道如何做已經做過的事情。為此，我們知道已經完成的工作非常少。但是，我們的行為就像我們知道的一切一樣，並且假設有完善的知識，他們給出的估算值太短了，因為我們沒有考慮學習時間。
問題的一部分還在於我們脆弱的自我。我們擔心如果我們給出的估計值“太長”，人們就會對我們的想法減少。他們說，“好的工程師”應該能夠更快地工作，所以我們預設了。當對一個專案給出初步估計而一個非工程師回來並說那太長時，我總是感到驚訝。首先，正如我已經提到的，由於我們的缺陷，它實際上可能太短了。第二，非工程師如何才能知道需要多長時間才能完成建造？這導致了另一個問題。

我曾經編碼
很少有比“我以前也編寫過程式碼”更能激怒軟體工程師的短語。無論是來自產品經理，設計師還是高層管理人員，除了合理說明工程師為什麼出錯的原因外，使用此短語都只會導致以下結果：蔑視。
以下是非工程師在我面前說的一些常見謬論：

• 我不明白為什麼這麼大功能。只是幾行程式碼嗎？（從技術上講，所有內容都是幾行程式碼。這並不容易。）
• {在此處插入名稱}表示可以在幾天內完成。（這是因為{在這裡插入名稱）已經對解決方案有全面的瞭解。我沒有，我需要先學習它。）
• 我們可以採取什麼措施來加快速度？您是否需要更多工程師？（使更多的工程師經常遇到問題會使情況變得更糟。更快構建某些東西的唯一方法是構建一個較小的東西。）

更多廚師
軟體工程師還不斷面臨廚房裡廚師過多的問題。由於我們低估了完成任務所需的時間，因此大多數軟體都已延遲。無論大小的公司，您都知道和喜愛的產品，都屬於這一類。遲到會使管理人員不滿意，他們通常認為問題是人太少了。他們說，我們將只僱用更多的工程師，這將使一切變得更好。
在某些情況下，可以再增加一些工程師。在大多數情況下，增加工程師人數只會使問題變得更糟。要讓富有創造力的人互相協調非常困難，一旦加入更多的人就變得更加困難。通常，不允許工程師有空閒時間。如果管理層意識到工程師閒置，他們傾向於為他們建立工作。
幾年前，這以一種幾乎滑稽的方式發生在我身上。我們正在設計新的Yahoo主頁，僅由一小部分人從頭開始對其進行重建。實際上，這是一種理想的情況，我們中的少數人能夠專注於應在其上構建頁面的基礎體系結構。我們進行了全部設計，當我們突然得到八名工程師時，準備開始進行原型設計。我們的行軍命令？這些工程師需要立即開始為新主頁編寫程式碼。因為該體系結構不存在，這是一個難題。但是工程師不能閒著，他們被分配到專案中並且需要開始做一些事情。這是一個經典的雞肉和雞蛋問題。
在理想的情況下，我們至少應該構建該體系結構的原型，然後再聘請其他工程師來幫助構建。但是，在這種情況下，我們陷入了困境。我最終要做的是使用另一個專案中的現有架構，並建立一個薄的外觀，使其看起來像我們實際的架構一樣。工程師能夠停止他們的工作，而我們能夠同時構建實際的架構。對於可怕的問題，這是一個可怕的解決方案，但後來又困擾了我們，因為工程師到達了立面的邊緣，而新建造功能最終將存在但還不存在。我最後不得不告訴我的經理，除非他給我們時間來構建實際的體系結構，否則我們建造的紙牌屋將崩潰。
一個專案中有太多的工程師是一個嚴重的問題。增加更多的工程師假設要完成並行任務，但實際上，任何一個專案上的並行任務數量都是有限的。當可用的工程師人數過多時，工程師的時間將最終從開發轉向計劃，同步和協調。回到我之前的隱喻，您必須先構建第一層，然後才能構建第二層。軟體專案上的許多工實際上是順序的，因此增加更多的工程師並不能加快工作速度。就像我以前的一位同事曾經經常說的那樣，我不在乎你給我送多少女人，還是要花9個月才能生孩子。

真正的脾氣暴躁
因此，如果沒有足夠的資訊，不斷變化的要求，沒有足夠的知識來完成這項工作，並且人們不斷地猜測我們，那麼我們每天就會步履艱難。作為有創造力的人，我們忍受了所有這些，因為我們知道有一天人們會使用我們的工作。這實際上是驅動軟體工程師的主要因素：我們甚至不認識的人的想法將受到我們工作的影響。無論您是在每天訪問數百萬人的網站上工作，還是在餐廳的銷售點系統上工作，都知道我們正在影響人們的生活，這是一個強大的推動力。
當由於人們改變主意而出現延誤時，我們會變得非常脾氣暴躁。脾氣暴躁。我們推遲在人們面前開展工作的目標，這令人沮喪。令人驚訝的是，軟體工程師通常不是完美主義者。我們通常可以從那裡得到一些好的東西，而不是從那裡得到一些好的東西。我們喜歡構建能夠快速交付的小物件，然後再將它們組合成大物件。為什麼？因為這就是我們將工作推向人們的方式。
現在，我們都知道延遲與其他任何東西一樣，都是軟體的一部分。如果他們不花時間去嘗試並使工程師工作，工程師們將瘋狂地工作。工程師不討厭辛勤工作或長時間工作。我們討厭它沒有回報。

謝謝你
作為軟體工程師，我們的工作時間表與其他時間表截然不同。通常在深夜醒來的不是設計師或產品經理，因為生產中發生了一些問題。一次我正要離開辦公室，因為生產問題辦公室要去約會。她坐著耐心地等待了一個小時，而在我最終設法起飛之前，我瘋狂地試圖解決這個問題（我不能怪她）。
但是，您很少會發現軟體工程師抱怨長時間工作或由於生產問題而被喚醒。該軟體是我們的寶貝，我們喜歡照看它。這意味著如果它需要在深夜餵食，我們就這樣做。如果週末需要額外的照顧，我們也會這樣做，因為我們的創造力正在增長，所以都面帶微笑。
工程師能夠簽入任務的最後程式碼時，尤其高興。我從未見過工程師這麼高興，就像他們傳送一封電子郵件說任務已完成並準備進行審查一樣。
想象一下，如果可以的話。您已經在某件事上工作了一天，一週或幾周，並進行了提交。您為自己感到驕傲，因為您完成了任務，可能學習了以前不知道的事情。您真正想要的只是花一點時間坐下來欣賞一下您的作品。也許有人說“幹得好”。我們得到什麼回應？Bug。某些功能不起作用，其他功能不正常，依此類推。當我們進入固定模式時，我們的好心情被破壞了。

為什麼我們說“不”
鑑於我提到的所有內容，以下是工程師拒絕（或看上去很脾氣暴躁）的常見原因：

• 該需求在開發過程中來得很晚，沒有足夠的時間在截止日期之前完成。
• 該需求使為使專案繼續進行而在流程的早期做出的一個或多個假設無效。
• 該需求是先前需求的沖銷。
• 否則，該需求會增加截止日期之前必須完成的工作量。
• 我們非常精疲力盡，任何需求似乎都需要大量額外工作，而我們只是不想處理它。

護理和餵養
那麼，您如何處理業務中這些脾氣暴躁的必需品呢？回顧一下推動工程師發展的因素：

• 有創意
• 解決問題
• 人們使用我們的工作

跨職能工作
就像產品經理和設計師一樣，軟體工程師是富有創造力的，因此您應該努力將它們納入創作過程。在集思廣益會議和審查初始設計時，工程師是寶貴的資產。讓每個工程師都有機會與構想團隊會面並直接與他們合作（不一定要同時全部工作）。簡而言之，請儘早將工程師注入到創作過程中。沒有工程師不喜歡在不瞭解規範和設計的情況下把它們扔在牆上。
工程師具有很高的邏輯性，因此在這些早期會議中瞭解需求的來源可以大大避免產生問題。當工程師覺得自己像建造者時，他們會提出質疑，這會拖慢整個過程。當工程師是共同創作者時，問題會更少，因此流程後期的延遲也更少。
此外，工程師在可能的知識方面經常遙遙領先。如果您考慮使用前端工程師，那麼我們比產品經理和設計人員早就具備了什麼樣的瀏覽器功能。當我們共享這些知識時，實際上，由於可能，我們實際上會給每個人關於如何構建產品的新想法。想象一下，如果您試圖建立一個照片共享站點，卻不知道現在可以將檔案從桌面拖放到瀏覽器中進行上傳？2這將如何影響產品設計？
因此，請儘早邀請工程師參與創作過程。讓他們給您反饋並提供有關可能的資訊。受到命令的感覺越少，我們就越有可能傾聽並樂於完成工作。只有當我們覺得我們為創造這個東西做出了貢獻時，這才真正發生。

創造空間
遵循軟體工程師作為創造者的主題，嘗試為我們提供足夠的創造力。駭客日和駭客周之所以如此受歡迎是有原因的–這是因為這是工程師需要加油並重新發現對程式碼的熱愛的創造性渠道。駭客事件是工程師可以完全發揮創造力，擺脫常規工作約束的時候。
每個季度的駭客日足以使人們興奮。想讓人們更加興奮嗎？給駭客天一個主題。為最有創意，最有可能運送的產品提供獎勵，依此類推。關鍵是要養活軟體工程師的創造力，這樣，當他們回到正常的工作中時，他們會感到精神煥發並準備再次做出貢獻。
請記住，工程師在這方面並不特殊。每個人都需要時間來發揮創造力。但是，以我的經驗，產品經理和設計師往往會更頻繁地獲得這些東西。對於設計師來說，在場外有管理和設計峰會，但工程師往往被排除在外。
順便說一句，駭客事件並不是做到這一點的唯一方法，但它們是入門的最佳方法。您還可以透過派工程師參加會議來點燃創造力，使他們可以保持最新技能。允許工程師購買對公司有用的書籍。允許工程師表達他們對正在進行的專案的想法。眾所周知，Google為工程師提供了20％的時間從事輔助專案。所有這些都可以大大有助於與您的工程師建立良好的關係。

鼓勵休息
由於我們會定期進行大量的時間和智力鍛鍊，因此工程師需要休息一下。不幸的是，這也是我們在排程方面不太擅長的事情。我們被整個過程所困擾，以至於忘了去度假。在我職業生涯的前五年，我認為我總共休了7天的假期。我不知道為什麼，但是我們不太擅長抽時間讓自己減壓。那是個問題。
工程師的倦怠是獨特的，因為我們習慣於透過它進行供電。當倦怠變得足夠嚴重時，我們離開，尋求緩解。而且，工程師可能永遠也不會告訴您他們正在接近這一點。我們為此感到自豪。在我的上一個團隊中，我告訴工程師，他們第一次感到沮喪，就來找我說話。我不希望他們等到變得如此之大以至於他們逃脫的唯一方法就是離開。我不希望他們離開，我希望他們幸福，而我唯一能幫助的方法是，如果我知道他們開始不幸福。
鼓勵工程師請假。貴公司會給您一些假期，因此請確保鼓勵工程師使用全年的假期。至少每4-5個月一次。經理們很容易為此提供幫助，因為他們知道專案進度表。
當工程師定期休息時，它將使他們脫離嚴格的期限來恢復他們的創造力。是的，我們可能仍會在放假時進行某種編碼，但這將完全是我們的創造，因此與我們在工作中的工作有很大不同。這是重新整理併為下一場戰鬥做好準備的重要部分。

讓他們編寫程式碼
聽起來可能具有諷刺意味，但許多公司僱用軟體工程師，他們的日子充斥著無用的會議，然後才讓他們實際進行編碼，影響了生產力。通常，軟體工程師可以連續至少四個小時編寫程式碼而不會受到干擾，因此這段時間他們的生產力最高。
如果您知道一個小時或兩個小時內要召開會議，那麼在編碼時就很難進入良好的流程，這在編碼時始終在您的腦海中。編碼一個小時，停止一個小時，編碼一個小時，停止一個小時等等，這簡直是徒勞的。您無法進入流程，就像開始一樣，必須停止。軟體工程師的大腦必須切換到良好的編碼模式，因為這種切換需要時間。

確保工程師每天至少有四個小時的不間斷編碼時間。這是使工作更快完成的關鍵。這似乎是合乎邏輯的：如果人們通常每天工作八小時，則至少應將一半時間用於主要任務。我曾經發現我在下午1點到5點之間的工作效率最高。我知道，如果每天都有時間，我可以輕鬆完成任務。當那段時間開始被會議打斷時，我知道我不會做太多事情。
另外，每週至少需要一天沒有開會。這包括每日站立。只是讓工程師們有一天可以完全自己管理時間並完成所有工作。一整天不間斷地完成了多少工作，這絕對令人驚訝。如有必要，允許工程師在家工作以確保他們不被打擾。實際上，我經歷了一段職業生涯，期間經理要求我每週至少兩天在家工作，因為我在辦公室經常被打擾。結果：我很快完成了工作。

表達讚賞
這是可以立即完成並且完全有效的。前面我提到過辛苦地完成任務，但遇到的錯誤卻使它感到沮喪。我們的工程師很少有機會坐下來欣賞我們的工作，更別說得到別人的支援了。
當工程師完成一項任務，尤其是一項漫長的任務時，簡短地說聲感謝將大有幫助。即使只是，“嘿，感謝您完成此操作。我們來看看。”足以分散漏洞開始氾濫時通常發生的防禦性。感到讚賞對軟體工程師很重要，因為我們得到的大多數反饋都是錯誤的，包括錯誤，生產問題，等等。一點點積極的反饋使其餘的一切都可以容忍。
對於獎勵積分，設定一個獎項，該獎項每季度頒發給對影響力最大或改善最大的工程師。該獎項甚至不必像iPad那樣大而可取（儘管我們很樂意接受它以及其他禮物），它可能是一個小小的獎盃，並向團隊或部門發了一封電子郵件，以表彰其努力。
並且，當您感謝人們在產品上的辛勤工作時，請確保不要忘記工程師。我參加過無數次會議和許多專案，在這些會議上，人們公開稱讚產品團隊或設計師在專案上的工作，卻從未提及工程師的血汗與淚水使事情變得真實。由於這三類產品，每一種產品都是成功還是失敗，所以沒有人能夠獨自完成。確保您的公司始終將團隊視為一個整體，而不僅僅是一個特定的部分。

結論
我們的軟體工程師是一群有趣的人。我們伴隨著一種確定的個性，我們確實希望使最好的事情成為可能。如果您不再像短時間廚師那樣對待我們，而開始像創造性過程中那樣對待我們，您可能會比以前更快，更遠。我所工作的團隊由於不瞭解工程師的心態以及驅動他們的原因而產生了不同程度的摩擦。我衷心希望這篇文章能夠導致工程師與他們之間的更好的溝通。其實並不難。我們都是想成為解決方案一部分而不是工蜂的人。