Bob Martin 以 CTO 的身分，對勇氣提出五項期望。這裡的勇氣不是魯莽冒進，而是專業人員在面對壓力時堅持做對的事的能力——互相補位、誠實估算、勇於說不、持續學習、以及傳承經驗。

We Cover for Each Other（我們互相補位）#

什麼是真正的團隊？#

我們用「團隊」（team）來形容一群開發者，但真正的團隊是：當某個成員倒下時，團隊仍能繼續朝目標前進。就像船上的每個船員都有自己的工作，但每個人也知道如何做另一個人的工作——因為船不能因為一個人倒下就停。

團隊成員可能因為各種原因倒下：

  • 生病
  • 家庭問題
  • 休假

工作不能因此停擺，其他人必須能填補空缺。

你的責任#

Bob 把這個議題翻轉過來：確保有人能替你補位，是你的責任。

  • 你有責任確保自己不是團隊中不可或缺的那個人
  • 你有責任主動找其他人，教他們足夠多你的工作內容，讓他們在緊急時能接手
  • 最好的教學方式：坐下來跟他們一起在工作站上寫一兩個小時的程式碼
  • 不只教一個人——知道你工作的人越多，補位能力越強
  • 一次不夠——你持續在進展，所以必須持續讓其他人跟上你的進度

Collaborative programming（協作程式設計）的紀律在這方面特別有幫助。

Honest Estimates（誠實的估算）#

估算的本質是不確定性#

作為程式設計師，最誠實的估算其實是「我不知道」——因為你確實不知道任務需要多長時間。但你也知道你大概不需要十億年。所以誠實的估算是你不知道的和你知道的混合體。

一個誠實的估算看起來像這樣：

機率預估完成時間
5%這個週五前完成
50%下個週五前完成
95%再下個週五前完成

這樣的估算提供了一個機率分布，描述你的不確定性。描述不確定性正是讓這個估算誠實的原因。

大型專案 vs. 小型任務#

大型專案：當管理者要求你估算大型專案（例如判斷專案是否值得授權）時，上述的機率分布格式最有價值。

小型任務：使用 Agile 的 Story Points 更合適。Story points 之所以誠實，是因為它們：

  • 不承諾時間框架——只描述任務間的相對成本
  • 使用的數字是任意的但相對的
  • 例如：Login story 被定為 3 points，Deposit story 感覺沒有 Login 兩倍難，所以定為 5 points
  • 機率分布已經內嵌在 story points 裡：它們不是日期或時間，只是 points；它們不是承諾，只是猜測
  • 每個 iteration 結束時加總完成的 points，用這個數字來預估下個 iteration 能完成多少

CTO 期望的是描述不確定性的誠實估算，不是對日期的承諾。

You Must Say NO（你必須說不）#

說不的義務#

程式設計師能說的最重要的話之一就是「不！」——在對的時間、對的情境下說出來，可以為雇主省下大量金錢，避免可怕的失敗和尷尬。

這不是讓你到處說不的執照。我們是工程師，我們的工作是找到通往「是」的路。但有時候「是」就是不可能。我們是唯一能判斷這件事的人，所以當答案真的是不的時候，說不是我們的責任。

面對壓力#

場景：老闆要你週五前完成一項任務。你仔細考慮後，發現沒有合理的機會能在週五前完成。

  • 你必須回去跟老闆說「不行」
  • 聰明的做法是同時說「但我可以在下週二前完成」
  • 但你必須堅定：週五就是不行

管理者可能不喜歡聽到「不」——他們可能反駁、對質、甚至對你大吼。情緒對抗是某些管理者使用的工具。你不能屈服。

特別小心「你能不能至少試試看？」這個策略。聽起來很合理，對吧？但其實不合理——因為你已經在盡力了。沒有什麼新的做法能把「不」變成「是」，所以說「我試試看」就是一個謊言。

sequenceDiagram
    participant 老闆
    participant 程式設計師

    老闆->>程式設計師: 我需要你週五前完成這個功能
    程式設計師-->>程式設計師: 仔細評估工作量...
    程式設計師->>老闆: 不行，但我可以在下週二前完成
    老闆->>程式設計師: 週五之前一定要完成！
    程式設計師->>老闆: 我理解壓力，但週五真的不行
    老闆->>程式設計師: 你能不能至少試試看？
    程式設計師->>老闆: 不，我已經在盡力了。說「我試試看」等於說謊

Continuous Aggressive Learning（持續積極學習）#

軟體產業的變動極其劇烈。我們可以爭論這是否應該如此，但我們無法否認事實就是如此。因此，我們都必須是持續積極的學習者。

學什麼？#

  • 你今天用的程式語言，5 年後可能不再使用
  • 你今天用的框架，明年可能就換了
  • 程式設計師常被建議每年學一門新語言——這是好建議
  • 選一門你不熟悉風格的語言：
    • 從未寫過動態型別語言？學一門
    • 從未寫過宣告式語言？學一門
    • 從未寫過 Lisp、Prolog 或 Forth？學它們

什麼時候學？#

  • 如果雇主提供時間和空間——盡量利用
  • 如果雇主不提供——你得用自己的時間
  • 準備好每個月花數小時在學習上
  • 是的，你有家庭義務、有帳單要付、有生活要過——但你也有一個專業，專業需要維護和保養

Mentoring（指導）#

教學的責任#

軟體業對程式設計師的需求似乎永無止境。全球程式設計師的數量正以驚人的指數速度增長。大學能教的有限，而且很多大學教得並不好。

因此，教導新程式設計師的工作落在我們身上——那些已經工作了幾年的程式設計師。

教學的好處#

教學看起來很難，但它帶來巨大的回報：學習最好的方式就是教學，沒有什麼方法能比得上。所以如果你想學某樣東西，去教它。

具體做法#

如果你已經寫了 5 年、10 年、15 年的程式，你有大量的經驗和人生教訓可以傳授給剛入行的新人：

  • 帶一兩個新人，引導他們度過最初的 6 個月
  • 坐在他們旁邊，幫他們寫程式碼
  • 跟他們說你過去的失敗和成功故事
  • 教他們紀律、標準和倫理
  • 教他們這門手藝（craft）

CTO 期望所有程式設計師都成為 mentor。期望你投入心力，幫助他人學習。

Backward Quality The Ethics Forward