這個說法其實很合理：我們的工作是思考客戶提出的問題，然後制定解決方案。思考第一，程式碼第二，公司請我們的最終目的不是寫程式碼，而是想出解決方案。
話粗理不粗。
付你薪水不是讓你來思考的，也不是讓你來寫程式碼的，你的目的是交付產品。如果不能交付有效的產品給客戶，那麼你的知識，技能，態度，以及所有能讓人成為高效程式設計師的特性又有什麼意義呢？！
沒有客戶會說：“嗯，如果能用空格代替tab鍵表示縮排，那程式碼將更具可讀性。”也沒有客戶會要求我們使用單向雜湊儲存的密碼，事實上他們可能聽都沒聽說過。沒有客戶會強求我們想出所有可能的架構和平臺，然後擇優選用。更加沒有客戶會問及他們的專案使用的是什麼程式碼標準。
客戶不在乎程式碼，也不在乎架構，更加不在乎整個系統是否臃腫不堪。他們想要的就是解決他們的問題。
真正的難點在於權衡以下這兩個極端：我們的工作就是寫程式碼，亦或是認為，程式碼和產品這兩個條件永遠無法同時滿足。
下面讓我們認識兩位新手程式設計師——Sam和Ted。ps：如有雷同，純屬巧合。
Sam是一名從剛從當地一所大學畢業的新員工，是個標標準準的學霸。她的面試和FizzBuzz測試表現都非常出色，現在她正式開始她的第一天程式設計師生涯工作（被聘用了！）。你，作為專案負責人，指派給她第一個任務。因為她才剛開始，所以任務並不難，你（作為一名有經驗的開發人員）覺得大概一小時時間就能搞定，不過，你基於保守估計，認為她可能需要用一天的時間。
最終她花了一個星期時間！從第二天開始，每次檢查的時候，她都信誓旦旦地說一切進展順利，程式碼會寫得非常完美。最後終於完成了，果然如她所說的那樣：程式碼完美得像藝術品。但是，請注意，她花了一個星期的時間才完成了這項本應該不超過一天的任務。
現在，來說說Ted。
Ted和Sam同一天被錄用。他的面試也很順利，儘管他完成問題的速度非常快。你也給了Ted一個相對簡單的任務：大概需要一天時間。
但是他只花了一小時！在你中午的休息時間，Ted就噌噌噌跑過來交任務了——瞧那驕傲自得沾沾自喜的樣子，彷彿在一個勁說“求表揚，求給贊！”但是一看他的程式碼，就只能呵呵了：很多複製貼上來的程式碼片段，亂七八糟的函式命名，組織混亂，霧裡看花的解釋，等等等等，就像一鍋大雜燴一樣，你不認識我我也不認識你。
你的團隊更屬意誰呢，Sam還是Ted？都不是。這兩個實際上都不能提供真正的產品？他們一樣糟糕：一個思考得太多，另一個則思考得太少。
所以，謹記這一點，付你薪水不僅僅是讓你來寫程式碼的，也不是僅僅只需要思考，你還需要開發出能夠解決問題的產品。
對此，你的看法呢？歡迎各抒己見。
相關閱讀
評論(1)