12年程式設計師得到的12個經驗教訓

我已經在thoughtworks工作了12年。是不是有點不可思議？回首我的職業生涯，我想寫一寫我在這些年中經歷的困難，以及總結得到的12個非常重要...

我已經在thoughtworks工作了12年。是不是有點不可思議？回首我的職業生涯，我想寫一寫我在這些年中經歷的困難，以及總結得到的12個非常重要的經驗教訓。雖然我只選擇了12個，但其實遠遠不止這個數字，但是我覺得12年12個經驗教訓更有韻味。

在我多年的諮詢工作和與許多組織和管理者的共事中，我發現了修復問題的共同套路，那就是管理人員相信工具可以「解決」給出的問題。當問題域被理解透徹，並且不可能有很多例外，以及每個人的行為方式相同的時候，這樣的做法很管用。不幸的是，很多現實問題並非如此。

許多管理者都犯過這樣的錯誤，那就是認為組織的其他部分在做出改變的同時，只有那些參與工作的人才需要「接受敏捷」。在企業中做這樣的統籌需要花費大量的時間和技能，因為你要關注於同步組織在不同水平的變化。

那些想要組織的一部分接受敏捷的組織面臨著真正的威脅。正如有句話所說，「要麼改變組織，要麼改變組織的方式。」

學習的必要經過是犯錯誤。在德雷福斯模型中，這意味著，特別是位於高階初級階段，人需要通過犯錯誤來學習。但是，當人們覺得犯錯會對工作造成壞的影響，會失去同事的尊重或在過程中會傷害到其他人時，那麼他們就不會冒犯錯的風險。

因為我熱衷於教和學，所以我想辦法創造了乙個安全的失敗空間，在這裡失敗的話，可以通過犯一些基本的錯誤來學習。

我以前寫過這個話題的內容，因為這是乙個非常重要的觀察結果。我看到的乙個常見的思維模式陷阱是，人們覺得為了像乙個領導，你需要去擔任領導的職位。但其實人們可以展示他們的領導力而不論其頭銜如何，並且可以通過很多不同的方式做到這一點，只需在沒有明確期望或要求的事情上採取行動。

在我執行的tech lead courses中，我提倡技術領導者至少將他們30％的時間用來寫**。花時間於編碼上有助於建立信任，尊重和理解當前的系統。在做架構決策時，不考慮到當前系統的約束條件往往會造成錯誤的決定。

我記得曾有人談論過xp values，其中有一點就是勇氣。勇氣是領導時所必須的，因為你要冒失敗的風險，以及嘗試一些新事物的風險/回報。沒有風險，往往就不會有很大的回報。

有這麼一條古老的箴言，「依其言而行事，勿觀其行而仿之。」在現實中，不管你說什麼，人們首要的是會記住你是如何行動的。你得始終記得要言行一致。不一致的言行會損害相互之間的信任。說「no」或「現在不行」比答應做一件事卻沒有辦到要好得多。

雖然不是所有的結對程式設計環境都是健康的，但是我相信，當結對程式設計有效工作的時候，團隊往往具備一種更好的協作文化。許多開發人員更喜歡（長期）branch-based development的反模式，因為它推遲了反饋和潛在的衝突**。

我把（可導航的）衝突當作協作團隊的乙個健康標誌。推遲反饋，例如長期分支**審查的情況往往會導致更多的不滿，因為它交付得這麼晚。

每個人都是獨一無二的，每個人都有自己的長處和短處。雖然我們傾向於尋找志同道合的人，但是擁有廣泛優勢的團隊才能走得更好。這一區域中的優勢可能會成為某個上下文中的弱勢，所以當團隊成員擁有更廣泛的優勢時，團隊會變得更強大。雖然優勢的差異可能會導致衝突，但健康的團隊會接受彼此之間的差異，而不是憎惡差異。

《drive》，一本膾炙人口的書，談論了人們如何通過朝某一目標前進而生出幸福感。根據我的經驗，幫助別人找到解決方法，對他們產生積極的影響，才是幸福的源泉。

結論以上這十二個要點並非我在thoughtworks的12年時間裡所學到的全部經驗教訓，但它們確確實實是幫助我為客戶服務的比較重要的經驗教訓。