在〈為程式碼變動做出解釋〉時，有引用了 fx777一句 的話，這句話再借我用一次：

工程師的工作是解決問題，其次才是寫程式。

是的，身為程式設計師的我們，應該是要解決問題，而不是當一個生產線上的製造工人，別人說要什麼，我們就給什麼。如果只會針對別人提出要什麼，並且寫程式把他實作出來，雖然偶爾的確解決的問題，但有時候卻會變成寫出來了，對方卻說這不是他要的，又開始提別的需求。這到底是為什麼呢？

因為有時候客戶（或是產品負責人、主管等）提的只是他想解決問題的做法，而不是他想解決什麼問題。然而他提出的做法，卻不一定真的能解決他的問題。所以比較好的作法應該是，透過客戶提的做法作為起始點，與客戶一起追朔到他是為了什麼目的而提出這個做法的，結合程式設計師的專業，是否有更好的做法或建議可以提供，讓彼此能夠直接接中要害，解決問題。

舉一個簡單的情境，在 UI 上，客戶可能會常常跟我們說，想要一個漢堡的選單按鈕（hamburger menu），背後隱含的可能是只想要 RWD 的設計，去解決跨裝置瀏覽的問題，但因為客戶對於網站設計這部分不懂，甚至不知道 RWD 的這個術語，所以才用片面的說詞、一部份的做法，去解決他想解決的問題。這時候我們就應該詢問他是不是想要讓網頁都可以跨裝置瀏覽，那除了漢堡外是不是有其他方案可以在現在的網站上解決這個問題。或是除了漢堡包外，我們是不是也應該增加那些需求。

身為一個專業程式設計師，除了透過程式編寫提供實作能力以外，也要能給予對這個領域知識不熟的客戶諮詢。承前述，有時候客戶甚至不清楚自己要的是什麼，而只是就對這領域的一隻半解，嘗試用他暸解的話語和我們溝通。我們這時候不該去嬉笑或是不耐對方的不理解或是錯誤的認知，畢竟這不是他們的領域，他們也努力地表達過了。相對的，我們應該要用他能理解的溝通方式，陪他們找出他們想解決的問題，協助將這些問題寫成需求，以及建議的實作方式。這樣才是最節省雙方的時間，而不是把珍貴的時間浪費在需求修修改改、做了又砍、砍了又做這種無意義的過程中

在完成一個可用的軟體之前，其實耗費最多的時間通常不是寫程式，而是在溝通。因為只要我們能把需求溝通明確，並且透過定期的展示確認問題有沒有被解決，實際實作的時間是不會有太多浪費的，而且也能獲得成就感。最怕的就是好不容易寫好的軟體，被客戶說不符合需求，導致胎死腹中，或是造成兩方爭執。因此，開發軟體時，身為程式設計師的我們應該要暸解目的去實作，而不是暸解要什麼去實作。