前不久，Jenna Bilotta［譯注1］寫了篇很棒的文章叫做《設計師和工程師怎樣才能默契地工作》［譯注2］。在文章中她說到了設計師和工程師更加富有成效地工作的方法。面對相同的和設計師一起工作的挑戰（及當我作為UI角色和工程師一起工作的挑戰），我贊賞她建議的那些實際方法。尊重其他角色起到的作用以及明白他們工作時的想法總是有好處的。

其中有一個她對工程師的建議是不要過快地說“不”。這困擾了我很久，并一直在我腦海中揮之不去。我的第一反應是：“但你們不明白為什么我們會說‘不’！”，隨后產生了成千上萬的自我防衛想法。當然她是對的，我們的確非常快地說“不”，不僅僅是對設計，對所有的一切都會這么說。這使我開始思考軟件工程師的心理以及是什么導致我們變成現在這樣的。

譯注1：Jenna Bilotta，Google產品體驗設計師和自由顧問。設計過YouTube和Google Reader等產品。

譯注2：本文相當精彩，推薦給所有的設計師和工程師們。

我們的名聲

坦白講，軟件工程師一般都因傲慢自大、難以相處以及喜怒無常而著稱。我們也因在辯論賣弄學問的細節時說“不”而出名，并且認為自己知道怎樣把每個人的工作做得更好。總之這種名聲是應得的。這正是我們天天在做的：一邊寫代碼，一邊上Twitter和Hacker News。

（邊注：有些人會說這對所有的工程師來說是不正確的，你說對了。對于在工程師中的一小部人來說，上面的某個或者所有的觀點對于他們來說都是不正確的。在滾動到底部留言告訴我這篇文章讓你有多無語時，請繼續讀下去。）

名聲不是隨便就能獲得的，名聲是靠經驗掙得的。名聲這東西困擾我的是，就我自身認識的一些工程師來說，一般他們都是喜歡娛樂的、和藹可親的（如果不是固執己見的話）且令人愉快的群體。他們是你在工作之余想一起出去玩的及在周末想追隨的人。那么為什么在工作面前，另外一個不同的性格就會出現了呢？

創造者，不是建造者

我有一個推理。這個推理是軟件工程師把自己和與之一起工作的人看成是非常不同的群體。

我在軟件行業的大公司和小公司工作了十多年后得出了這個結論。公司（產品經理、設計師及其他管理者）往往把軟件工程師當作建造者。產品經理的工作是夢想建造什么，設計師的工作是怎樣在審美上取悅別人，工程師的工作是建造他們想出來的東西。基本上，工程師被看作為該行業的“臨時工”［譯注3］。

譯注3：英文原文是”short-order cooks”

我的第一個經理告誡過我一些事情。在我的第一家公司快要倒閉的時候，他和我就我的職業生涯進行了一場很坦白的探討。雖然我們有時相處得不好，但他給了我這個非常好的建議（大概的意思）：

“Nicholas，你比你的代碼有價值。不管你下份職業是什么，務必不要當“臨時工”。不要接受那種會明確告訴你要建造什么和怎么建造的工作。你應該在那種對產品有深刻理解并且也有能力來建造的地方工作。”

他是完全正確的。有很多的公司都想要“臨時工”，他們想要實現者和建造者按特定的節奏并要保持一條直線前進。實際上，我會說幾乎所有的公司都想這樣，不管是大公司還是小公司。我無法告訴你有多少家創業公司聯系我，給我股權，作為交換的條件是幫創始人建造他們的愿景。這隱含的意思是：我們已經想清楚了所有的東西，只需要某個人來建造它。

這里正是問題的癥結所在：軟件工程師不是建造者。軟件工程師是創造者。建造是你從宜家買了一件家具帶回家，說明書就擺在那兒，如果你按部就班地照著做，就能得到你想要的滑稽小桌子。創造是不同的過程，它在沒有指導和說明書的情況下會產生一些東西來。這就像是在一塊空白的畫布上繪一副杰作。軟件工程師不編碼是因為他們想別人來告訴他要做什么，他們開始編碼了是因為他們發現了能夠創建一些有用的東西。每個軟件工程師都是因為早先做了一個有用的小程序而愛上編碼，從此便迷上了。

在軟件的三個統治角色中（即產品經理、設計師及軟件工程師），只有工程師是被期待不用創造的，只管生產。軟件工程師不是傻瓜，他們看到發生了什么，會開始“創造”不滿（沒有雙關語義）。工程師想成為創造過程的一部分，但被拒之門外。因此最終有了典型的軟件工程師的性格叫做暴躁。

等等，出了什么問題？

產品經理是很有趣的人。他們的想法和了解市場的能力令人欽佩。他們也有一種傾向，認為他們的想法是完整的，其實，那漏洞大得火車都能通過了。我是友好地說的，我有幾個要好的朋友是產品經理，大家都知道我曾經當著你的面說過這種話。這絕對不是對產品經理的批評，這是他們的本性使然。他們的工作是一種創造性的，呈現的想法是不完整的。這是使軟件工程師脾氣變得暴躁的一部分原因。

工程師和產品經理都趨向于認為，產品規范或需求就相當于宜家的家具使用說明書，這是不對的。在現實中，這些文檔很少包含足夠的信息來建造實際的東西。他們通常只是工程的起點，這給工程師提出了一個獨特的問題。

要理解這個問題，考慮造房子的工作。有人已經決定希望在某塊土地上造一所房子。房子有二層和一個車庫。甚至還有一張餐巾紙，上面畫著房子的正面草圖。那人帶給你這個信息和餐巾紙，說“這足以讓你開始造了吧，對不對？”那你是否能夠開始造呢？

從邏輯上講，這時你還不能開始造房子。你不知道房子的建筑面積。你沒有房子的平面圖。你不知道城市對新房屋的要求規范。從字面上看是沒有足夠的甚至可以開始挖土的信息。此時，你會告訴你的客戶，他們是瘋狂的，必須要弄清楚自己想要什么。現在假設你不能這樣做，因為某人已經設定了Deadline，于是你負責召開會議。

“嗯，”你的客戶告訴你，“為什么你不先開始造呢，當我想到細節部分時我會告訴你的。這樣一來，我們沒有浪費任何時間。”

你知道，沒有足夠的信息能讓你開始造，并且現在進一步質疑客戶也不會得到任何別的信息。然而，你要趕Deadline，坐在那里等更多的信息你是受不了的。你會做什么？你開始假設了。

俗話說得好，“當你假設時，就把你和我都當成驢了”，大概再如此正確不過了。假設是危險的，而且往往是錯誤的。然而，如果沒有做一些假設，項目就無法向前推進。這就是你所做的。你假設你已經知道的信息是對的：房子有兩層樓和一個車庫。車庫，它應該是附著式的或分離式的？它應該是多大？好吧，簡單起見，它和房子是分開的，并只能停一輛車。這意味著你可以先開始造車庫，作為一個房子旁邊的獨立建筑物，當有關于房子的更多細節時，你可以繼續建造一旁的車庫而不受影響。

車庫造了一周后，你的客戶想到了更多的細節。事實上，房子有三層和八間浴室（唷，真幸運，還沒有開始造房子）。沒有車庫的進一步信息，但房子要被漆成藍色。然后，你從邏輯上假設，車庫也應該被漆成藍色，所以未來的一段時間你都花在這上面了。

幾天后，車庫差不多造好了。你對建造的質量相當滿意，因為只有這么少的信息你就造出來了。你現在開始準備造房子了，就在這時，你的客戶回來告訴你更多的細節。車庫實際上需要能停下兩輛汽車并且不是分離式的。你感到很沮喪，因為你造了一件好東西，現在需要用推土機推平掉，為“真實”的東西讓道。更糟糕的是，你現在只有更少的時間來完成整個工種了，這只能增加暴躁的級別。

如果這個比喻對你來說近乎瘋狂，你可能永遠沒做過作為一個軟件工程師的工作。這是我們現實生活的每一天都會發生的。我們試圖通過我們的創造力來推進項目，最終發現事實上我們不能讀懂任何人的想法，因此錯誤地猜測真正要建造的東西。然而，如果我們不做假設，就會坐在那里無所事事，因為沒有人喜歡瀑布流方式的軟件開發過程。

除了軟件行業，幾乎所有其他行業建造東西，預期的所有需求和細節在建造開始前都已商定并最終確定。在軟件行業，“沒有足夠的時間”提前收集所有的需求。從第一天開始“快速推進的重要性”就已深深地釘在了我們的心中。所以工程師學著去填充產品經理留下的空白，僅僅是為了保持項目能夠向前推進。當然，產品經理也因經常改變主意而著稱，這意味著工程師的假設在項目推進過程的中途往往會失效。

那么，軟件工程師們常常會很快失去工作的熱情并頻繁跳槽，這還用懷疑嗎？

第一優先級

上下文切換［譯注5］是任何創造者的敵人。一旦你沉湎于創造模式（有人稱之為“流”）里，把注意力轉移到別的東西上面就會使你焦慮不安，當前的過程也被完全中斷。編碼是一個創造性的過程。它同時是邏輯性的和創造性的。我們不僅僅是在編碼，我們是在精心地設計代碼。

譯注4：英文原文是”context switching”

在管理工程師時間的人當中，好像認為工程師很容易從一個任務轉移到下一個任務。就像有些人告訴我的，工作畢竟就是工作。你就直接指揮他去需要去的地方，就像指揮發射大炮一樣。當然這根本就是不對的。如果你在一個任務上花費了大量的時間，然后被要求放下它去做其他的任務，你就不能很容易地再回到首次的任務，并從離開時丟下的地方重新拾起來。在你再回過頭時要確保明白所有的狀況，這有一個重新適應的過程，這是上下文切換的代價。即使新的任務只需要幾分鐘即可完成，這足以把“流”中斷，從而使工程師生產力低效。

這是讓工程師脾氣變得暴躁的最主要的原因之一：不斷改變任務的優先級。如果第一天某個任務的優先級最高，第二天別的任務優先級最高，這意味著必然會發生上下文切換。富有創造性類型的工作是不想被打斷的，這是為什么工程師們能高興地持續編碼，直到早上凌晨才結束工作。把“流”中斷，會使我們的生產力低下。

真正的優先級不會是臨時性的，它們是不變的。在我們上面的人頻繁改變他們的想法，這會非常令軟件工程師們沮喪。我們時刻準備著投入到戰斗中去，只需給一個行軍的方向。但如果第一天你告訴我們是在造一所房子，第二天告訴我們是在造一輛汽車，你應該預料到你的士兵會和你的意見不合。

工程師的不足

軟件工程師每天都被推入困境，但我們不是受害者，即使我們這些人會很夸張地傾向于表現為受害者。實際上我們脾氣暴躁的一部分原因來自于自身，由于某種原因深深扎根在大多數軟件工程師的心中。我們有一個很悲劇的不足之處，這個不足是我們高估了自己的知識和能力。

這個不足會以多種方式表現出來。最常發生的是時間估計。幾乎每一位我知道的工程師，會習慣性地低估完成一項或一系列任務需要花費的時間。只有最出色的人能給出精準的時間，并和實際情況相符，而其余的人有時會漏掉兩個或多個因素的一個。問題是軟件工程師作為創造者，無法預見他們會遇到的問題。

盡管許多工程師會抱怨產品經理改變他們的想法，但幾乎沒有人會對他們的時間估計負責。沒有時間申請召開會議再過一遍需求并做出更改。Bugs？我們的代碼是完美的，從來沒有bug，所以我們并不需要擔心（終究QA還是會測出一些莫名其妙遺漏掉的問題，對吧？）。我們依賴的一些人會退出？沒關系，其他人會來補足這個空缺的。

所有這些原因加起來很快就會趕不上Deadline，但是在事情沒有及時完成的理由當中，沒有一個比這更加危險：沒把學習的時間算進去。這又直接回到了我們的不足了。我們認為已經知道如何完成所分配的任務，但這經常是我們之前從來沒有做過的。時間估計反映了一個完美的知識狀態：你有宜家手冊幫你開路。現實情況是，許多任務都要求我們做以前沒做過的事情。

在大學學習計算機科學的工程師，在課堂上教會的對軟件安全的感覺是錯誤的。他們出校門后認為明白軟件及軟件開發過程，其實什么都不知道。我在第一份工作的時候絕對是傲慢的大學畢業生，告訴大家他們這樣做是錯的。我在多年以后才能弄清楚其實我什么都不知道。

計算機科學課程不是為你工作時準備的。他們教會你的是主題范圍廣泛的理論知識，以便你在工作中遇到他們時不會傻了眼。你學習變量、函數和對象，因為你將一直會遇到這些東西。你學習數據庫和查詢，然而你學習的正規形式在實際工作中是沒有用的。你在排序算法和數據結構上花費了大量時間，所有這些在你工作編碼時都是不用考慮的。總之，計算機科學課程是在評論問題的解決方案，你在工作編碼時決不需要靠自己來解決。如今如果我需要對什么東西進行排序，只需調用sort（）方法即可。如果我需要一個隊列或鏈表，只要使用所用語言本身的實現即可。這些都是已經解決好的問題。

因此，剛走出大學校門的我們認為知道如何做一切東西時，其實知道的都是已經被解決的問題。事實情況是我們只知道已被解決問題中的很少一部分。然而，我們做出像知道一切一樣，自認為有完整的知識，給出的估計時間很短因為不用考慮學習的時間。

我們脆弱的自尊心也是問題的一方面。我們害怕如果估計的時間“太長”，人們就會小看我們。他們說“優秀的工程師”應該能夠快速地工作，我們默許了。我一直很驚訝，當項目有了初步的估計時間后，一個非工程師人員來說這太長了。首先，正如我已經提到的，由于我們的不足，實際上很可能時間還是太少了。其次，一個非工程師人員怎么知道需要花多少時間來建造呢？這引申出了另外一個問題。

我曾經寫過代碼

沒有比“我曾經寫過代碼”這樣的話更能讓軟件工程師惱火了。無論這是來自一個產品經理、設計師或高層管理人員，除了合理的質疑為什么工程師是不對的外，說出這種話來的人只會遭人鄙視。如果我問LeBron·James［譯注6］，他為一場比賽需要準備多少時間，如果我不同意他的理由是因為我在高中時打過籃球，我相信他會被逗樂的。軟件工程師也都是一樣的

譯注5：即勒布朗·詹姆斯，NBA著名球星，人稱小皇帝

下面是一些常見的謬論，是非工程師人員在我面前說的：

我不明白這為什么會是這樣一個大問題。不就是幾行代碼嗎？（從技術上來說，一切都是幾行代碼，這種話不會使問題變得容易或簡單。）

{請對號入座}說，這個可以在一兩天內完成。（這是因為{請對號入座}已經擁有完整的解決方案的知識。我沒有，我需要先學習。）

我們能做些什么能使這個建造得更快些？你需要更多的工程師嗎？（在一個問題上投入更多的工程師，往往會使情況變得更糟。快速建造東西的唯一方法是建造一個小點的東西。）

你能做到的最糟糕的事情是告訴他們你曾經寫過代碼。請注意，這實際上和一個專業的軟件工程師是非常不同的。工程師轉行做產品經理，在一段有限的時間內還是有些可信的（通常約為5年，大于這個時間則一切都已經完全改變了）。但是，那些從來沒有專業地開發過軟件的人，最好還是偷偷地保持編碼的愛好吧，而不是在企業里面使用它來為你爭論一切。

（說句公道話，對于設計師們也是有這個問題的。每個人都是業余的視覺設計愛好者，因為我們都喜歡漂亮的東西，但并不是每個人都有資格來設計東西的。）

更多的廚師

軟件工程師也經常面臨廚房里有太多的廚師的問題。因為我們低估了完成任務需要花費多長時間，大多數軟件都會延遲交付。這對大公司和小公司、你知道的和喜歡的產品都是適用的，他們都屬于這一類。延遲交付會讓管理者不高興，他們通常覺得問題是工程師太少了。他們說將會雇用更多的工程師，這會使一切變得更加美好。

在某些情況下，再多增加幾個工程師是有效果的。但在大多數情況下，增加更多的工程師，只會使問題變得更糟。讓富有創造力的人互相協調配合已經夠難的了，你再添加更多的人進來只會變得更加困難。一般地，工程師是不允許有空閑時間的。如果管理者注意到有工程師閑著，就常常會為他們制造一些工作來。

這樣的事情在幾年前以一種幾乎是滑稽可笑的方式發生在我身上。我們一個小團隊在設計新的雅虎首頁，從頭開始重做。其實，我們之中的少數人能把注意力集中在構建頁面依賴的底層構架上，就是一個很理想的情況了。我們把所有的都設計完了，正準備開始做原型，突然給了我們8位工程師。我們的開拔令嗎？這些工程師需要立馬開始為新首頁編碼。難題相當多，因為架構根本不存在。但工程師不能閑著，他們被分配到項目中總需要開始做一些事情。這是一個典型的雞和蛋的問題。

在理想的世界里，我們至少先建成一個原型，然后再接受別的工程師來幫忙建造。然而在這種情況下，我們被困住了。最后我使用了從別的項目拿過來的已有架構，創建一個很弱的模型，使它看起來好像實際的架構存在一樣。工程師們能夠停止他們手中的工作，同時我們能夠建造實際的架構。這是對恐怖問題的恐怖解決方案，這最終會刺痛我們，因為工程師最終會碰到目前并不存在的新架構功能的條條框框。最后在某個時候，我不得不告訴我的經理，如果不給我們時間建造實際的架構，空中樓閣是會倒塌的。

一個項目有太多的工程師，是一個嚴重的問題。添加更多的工程師就是在假定有并行任務需要完成，但在現實中，任何一個項目的并行任務數量是很小且有限的。當有更多的工程師可以使用時，很多工程時間就會從開發轉向規劃、同步和協調。回到我剛才的比喻，在第一層樓建成前你是無法建造第二層樓的。實際上許多軟件項目的任務是連續的，因此增加更多的工程師并不會加快速度。或像我以前的一個同事經常說的，不管你給我多少個女人，要生小孩仍然需要九個月的時間。

真正暴躁

所以，沒有足夠的信息、不斷變化的需求、沒有足夠的知識來完成這項工作及另外人們不斷猜疑我們，導致我們每天都在吃力地工作。作為創意人，我們容忍了所有這一切，因為我們知道有一天人們會用我們的作品。這是最主要的真正驅動軟件工程師的動力：甚至我們不認識的人都會受到我們作品的影響。無論你是在做一個每天有百萬級訪問人數的網站，抑或是為餐館做一個銷售點系統，影響人們生活的知識是強大的驅動力。

由于人們改變他們的想法導致有延誤時，我們會變得非常暴躁。發神經似地暴躁。我們在人們面前的工作目標已被推遲，這是令人泄氣的。令人驚訝的是，軟件工程師通常不是完美主義者。我們通常對有些東西好了就行，而不是要非常好。我們喜歡先快速地發布一些小東西，然后晚些時再把它們組合成一個大東西。為什么？因為這就是我們如何把產品給人們的。

現在，我們都知道延誤和其他東西一樣都是軟件的一部分。估計的時間不夠時，工程師們會拼命工作并完成目標。工程師不討厭努力工作或長時間工作，我們討厭沒有取得成功。

得到了什么可以表示感謝的東西？

作為一個軟件工程師，我們的工作時間線和其他人是非常不同的。通常不會是設計師或產品經理在半夜醒來，是因為產品中的一些東西出問題了（雖然，我也知道在發生這樣的事情時產品經理也是希望能被通知到的）。有一次我即將下班去約會，突然被叫到辦公室里，因為有個產品問題。她坐在那兒，而我在狂暴地試著解決這個問題，她最后離開前耐心地等了一個小時（我不能責怪她），留下我一人在那兒工作，我只能在即時聊天工具上和我的同事分享我的痛苦。

然而，你很少發現軟件工程師會抱怨長時間的工作或者由于產品問題被叫醒。軟件是我們的孩子，我們喜歡這樣來關心她。這意味著，如果需要在半夜起來喂她，我們就會做。如果需要在周末額外的照顧，我們也會做，我們會面帶微笑，因為我們的創造力在增長。

工程師在可以提交任務最后的代碼時會特別高興。當他們發送一封電子郵件說任務完成了準備接受評論時，我從來沒有見過他們如此快活過。然而，在接下來的十分鐘，這種情緒很快破滅了，人們開始對他們新創造的寶貝提交bug了。

如果你肯再想象一下，你在一個東西上工作了一天或一個星期或幾個星期，然后提交了。你感到很自豪，因為你完成了任務，很可能學做了一些之前不知道的東西。你真正想要的是花點時間坐下來，欣賞你的作品一會兒。也許有人說，“干得好。”我們得到什么反饋？Bugs。有些東西無法工作，另外有些錯位了等等。我們的好心情被破壞了，我們倉促地進入了修復模式。

為什么我們說“不”

鑒于我已經提到的一切，下面是工程師說為什么說“不”（或是脾氣暴躁）的常見原因：

需求在開發過程中姍姍來遲，在Deadline前沒有足夠的時間來適應。

需求導致早期過程中為了推進項目而做的一個或多個設想變得無效。

需求和先前的要求相反。

需求在其他方面增加了工作量，而且在Deadline之前必須要完成。

我們是如此的精疲力竭，任何需求看起來都像是大量的工作，我們就是不想做這個。

請記住，除了最后一項，所有這些工程師要做的都要趕上Deadline，以便完成項目。只有在我們工作的時候任務不發生改變，我們才會想把它做完。當他們發生改變且我們真的很暴躁的時候，“不”字就會在你說完話前脫口而出。

關愛

那么，你的企業是如何處理這些必然會出現的暴躁呢？先回顧一下驅動工程師的東西：

有創意的

能解決問題的

人們使用我們的作品

請注意名單中缺少什么。錢。向工程師砸錢很難滿足他們。這聽起來是陳詞濫調，但對工程師來真的不是錢的問題。錢讓他們有樂趣，但我們真正感興趣的是編碼和創造。當我們能在一個健康的環境工作時，我們能在很長的一段時間內保持快樂。

那么，你如何為工程師創造一個健康的環境？

交叉工作職責

軟件工程師就像產品經理和設計師一樣富有創造力，所以你在創造工作過程中要算上他們。工程師在頭腦風暴會議和初始設計評審時是巨大的資產。給每一位工程師和創作團隊見面的機會，讓工程師直接和他們一起工作（不需要一直在一起）。總之，盡早讓工程師加入到創造過程中去。沒有工程師會喜歡他們不理解的從墻外扔過來的規格說明和設計稿件。

工程師們的邏輯性很強，所以參加這些早期的會議，明白需求是從哪來的，對完全地避免問題是有很大的幫助的。當工程師感覺像建造者，他們會有疑問，然后進度就慢下來了。當工程師是共同的創造者時，問題很少，因此之后的過程中延誤就更少。

更重要的是，工程師們在什么是可能做到的知識方面遠遠領先于別人。如果考慮前端工程師，我們知道什么瀏覽器能夠實現，遠遠早于產品經理和設計師知道的時候。當我們分享這個知識點時，我們實際上給了大家如何做產品的新思路，因為知道了什么是可能做到的。試想一下，如果你想創建一個照片共享網站，不知道現在可以把文件從桌面拖放到瀏覽器上傳？［2］這對產品設計會有怎樣的影響？

因此，請在早期邀請工程師加入到創作過程。讓他們給你反饋，并提供什么是可以做到的信息。我們被呼來喚去的感覺越少，我們就越有可能傾聽并愉快地著手工作。只要我們感覺對創造這東西有貢獻時，我們就會這么做。

留出創意空間

跟著“軟件工程師是創作者”這個主旋律，試著為我們提供充足的機會勇于創新。Hack日和Hack周如此受歡迎的原因：因為這是創意的發泄方式，工程師需要加油，需要重新發現自己喜愛的代碼。Hack活動是工程師們可以盡情創作的時候，是擺脫了正常工作的限制的時候。

每季度的Hack日足以讓人興奮。想讓人更加興奮？給Hack日一個主題。給最具創意、最有可能推出產品的人獎勵等等。總得來說就是激勵軟件工程師的創造力，當他們回到正式工作時，會感到神清氣爽，準備再次貢獻自己的創造力。

請記住在這方面工程師不是特別的。每個人創作時都需要時間。然而，據我的經驗，產品經理和設計師往往更加能夠體會到這一點。管理者有拓展的地方，設計師有設計峰會，但工程師往往會被遺棄。

隨便說下，Hack活動不是做到這一點的唯一方式，但他們是最好的開始方式。你也可以派工程師參加會議，使他們能夠保持更新技能，點燃他們的創意之火。花費公司的一丁點兒錢讓工程師去買書，有助于完善他們的知識儲備。讓工程師表達自己對正在做的項目的想法。眾所周知，Google給工程師20％的時間去從事編外項目。所有這一切對于和你的工程師建立極好的關系是非常有幫助的。

鼓勵休假

我們經常進行數個小時的腦力勞動，我們需要休息。不幸的是，安排時間并不是我們很在行的。我們沉湎在工作的過程中，忘記了休假。我覺得在我職業生涯中的第一個五年里，我總共休了7天的假期。我不知道為什么，但我們對給自己騰出時間來緩解壓力這種事情不大在行。這是一個問題。

工程師倦怠是很特別的問題，因為我們習慣于在項目表現為精力充沛。當倦怠變得糟糕透了，我們會離開去尋找安慰。此外，工程師將可能永遠不會告訴你他們正在接近這個點，我們太自負了。在我上一個團隊，我告訴工程師，請在他們第一次感到沮喪時來和我說說話。我不想讓他們等到直到它變得這么大，以至于他們逃脫的唯一辦法是離開。我不想讓他們離開，我想讓他們快樂，只有我知道他們開始不高興了我才能幫助他們。

鼓勵工程師休假。你的公司提供了一些數量的假期，所以一定要確保在一個整年中鼓勵工程師們休掉這些假期。每4-5個月至少休一次。管理者是幫助完成這事的好角色，因為他們知道項目的進度。

當工程師需要定期的休息時，他們不用面對苛刻的Deadline，恢復了創造力。是的，我們仍然可能會在休假時花一些時間編碼，但這是純粹的創作，這和我們在工作中做的是相當不同的。這對重新提起精神準備下一場戰斗是很重要的。

讓他們寫代碼吧

聽起來具有諷刺意味的是，很多公司雇用軟件工程師，然后在實際工作中不讓他們編碼。替代的是他們的日子都充滿了阻礙生產力的無用會議。在一般情況下，軟件工程師們至少能夠編碼四個小時而不被中斷時，他們的生產力是最高的。

如果你在編碼的時候知道在一或兩個小時之后有會議，就很難進入到“流”里面，因為這總會在你的腦海里。編碼一個小時，停止一個小時，編碼一個小時，停止一個小時等等是驚人的低產的。你不能進入“流”當中去，因為你剛開始，你就必須停止。軟件工程師的大腦切換到很好的狀態去編碼是需要時間的。

確保你的工程師每一天至少有四個小時不間斷的時間用來編碼。這是更快地工作的關鍵所在。這似乎相當合乎邏輯：如果人們一天通常工作8小時，至少有一半的時間應該花在主要任務上。我以前覺得，我在下午1點和下午5點之間是最高產的。我知道如果每天都擁有這段時間，我可以很容易地完成任務。當這段時間開始被會議中斷，我知道就不能完成更多的任務了。

此外，每周至少有一天沒有會議，包括每天的站立會議。讓工程師有一天能完全自己管理自己的時間，把所有的事情做完。一整天都沒有被中斷，完成的工作量絕對是驚人的。如果有必要，讓工程師可以在家工作，以確保他們不會被中斷。實際上在我的職業生涯期間我有過這樣的經歷，我的經理要求我每周至少兩天在家工作，因為我在辦公室里會被中斷太多次了。結果是：我的工作完成得非常快。

表達謝意

這是可以立即做并且是完全有效果的。我前面提到的長期勞累地趕工完成任務，結果是遭受被提交bug的沮喪。我們的工程師很少有機會坐下來欣賞自己的作品，更不用說得到別人從背面拍肩膀的贊賞了。

當一位工程師完成了任務，尤其是一個漫長的任務，快速地說聲謝謝是大有幫助的。即使它只是“嘿，謝謝把那完成了，我們先看看。”也足以增強面對通常會發生的bug涌現情況的防御能力了。被感激的感覺對工程師來說是很重要的，因為我們得到的大部分反饋是消極的：以bugs的形式、產品問題等等。一點點積極的反饋就能使工程師容忍其余全部的東西。

每個季度給那些做了最大影響的，或者改進最多的，或者任何其他東西的工程師加分、設立獎品。獎品甚至并不必是像iPad那樣大件的和令人滿意的東西（雖然我們會和其他的東西一起欣然接受），它可以是一個小小的記念品以及發封電子郵件給團隊或部門，讓別人也察覺到我們的努力。

請務必確保當你感謝在產品上辛勤工作的人們時不要忘記工程師。我已經參加過無數次的會議，在上面人們公開稱贊產品團隊或設計師在對項目的作用，從來都沒有提到工程師。正是他們的血液、汗液和眼淚才把東西變成真實的。每一個產品是成功還是失敗歸根于所有三組人員，沒有一組可以單獨做到這一點。確保公司始終把團隊當作一個整體，而不是一個特別的角色。

總結

我們軟件工程師是一個有趣的群體。我們有一定的個性，我們要做最出色的東西。如果停止把我們當作“臨時工”，開始把我們看作創作過程的一部分，你很可能得到更多，另外項目也會比你想象得更快推進。由于不理解工程師的心態和是什么在驅動他們，我工作過的團隊都有不同程度的摩擦。我真誠地希望本文將更好地引導工程師及和他們一起工作的人之間的溝通。這真的沒有那么難。我們都想覺得自己是解決問題的一部分，而不是一只小工蜂。