近日，HackNews 上的一則帖子引發了眾多網友的熱議和共鳴。人們討論的焦點，BTI360 公司的軟件工程師 Joel Goldberg 在去年 12 月臨退休之際，向自己的團隊成員分享了他 45 年軟件編寫生涯中的種種收獲和教訓經驗。

具體地，他分享了關于知識學習、編寫代碼、團隊相處準則、職業規劃等諸多方面的心得，相信會為廣大軟件行業從業者帶來一些啟發。

以下是 Joel Goldberg 的分享內容：

回首過往在軟件行業的四十多年時間，變化之大令我震驚。我的職業生涯開始時還在使用穿孔卡片，如今退休卻已身處云計算時代。雖然經歷了種種變化，但幫助我度過整個職業生涯的很多原則卻始終沒有變過，它們依然具有意義。在臨退休之際，我想與大家分享自己作為軟件工程師所領會到的一些感悟。

警惕知識「詛咒」

當你知道某些事情的時候，則幾乎想象不到自己不清楚這些事情會是什么樣子。這就是知識「詛咒」，同時它也是無盡誤區和低效率的根源。那些能夠適應復雜境況的聰明人更容易陷入這種「詛咒」。

如果你對知識「詛咒」不加防范，則有可能在所有形式的交流中持錯誤立場，包括寫代碼。你所從事工作的專業性越強，則越有可能以外行無法理解的方式進行交流。所以，要與知識「詛咒」作抗爭。努力理解你的受眾，嘗試著想象一下第一次學習正在交流的事情是什么感覺。

六項基礎準則

技術總是在變，但軟件開發的一些基礎方法卻始終未變。以下是我認為未來很長一段時間都將保持不變的六項基礎準則：

• 團隊協作：好的團隊構建好的軟件，但不要認為團隊協作理所當然，每個人都應參與其中；
• 信任：團隊間的信任能夠促進發展，努力成為一個值得自己和他人信賴的人；
• 交流：真誠主動地交流，避免陷入知識「詛咒」；
• 尋求共識：花費時間帶領整個團隊走上同一條「跑道」，有不同意見充分討論以找到最佳解決方案；
• 自動化測試：經過良好測試的代碼使得團隊滿懷信心快速開展下一步行動；
• 干凈、易于理解和可導航的代碼和設計：要將接管自己代碼的繼任工程師當成自己的客戶，確保他們在閱讀、維護和更新代碼時不會遇到任何麻煩。

簡單法則

對抗復雜情況是一件永遠不會結束的事情，所以解決方案要盡可能地簡單。我們可以「不懷好意」地假設維護自己代碼的繼任者沒有你聰明。

當沒有什么東西可以刪除，而不是沒有什么東西可以添加的時候，設計師才意識到自己達到了完美。-Antoine de Saint-Exupery

尋求理解為先

美國著名管理學大師 Stephen Covey 的 7 個習慣之一是：首先尋求理解，然后再被理解。這項準則比任何其他建議更幫助了我成為好的聆聽者和工作伙伴。如果你想要影響他人并與其高效地合作，則首先需要理解他們。在試圖讓他人明白自己的想法之前要積極主動地聆聽并理解他們的感受、想法和觀點。

[[374988]]

小心被套牢

行業中總是會出現可能會變革軟件構建方式的下一代高效產品，如計算機輔助軟件工程（CASE）工具、COTS、Peoplesoft 和 SAP 等企業資源規劃產品甚至是 Ruby 等。這些產品都聲稱，如果人們接受了它們的整體開發理念，則會大幅度降低成本和時間。然而事實并不總是如人們預料那般順利，前期成本可能會很大，你受到的限制也依然很多?！副惶桌巍惯^去常常出現在供應商層面，但現在框架層面也出現了這種情況。無論哪個層面，高昂的沉沒成本都意味著改變的壓力很大，新事物也并不總是更好的。

當不適合某個角色時要勇于承認并改變

在職業生涯的某些階段，你可能會發現自己并不適合某些角色。這種不適合并不是性格上的缺陷，而是一個你不應忽視的問題。解決這種困境的方法不止一種：你可以繼續提升自己或者改變角色。關鍵要有自知之明，要意識到自身處境并讓自己脫離這個不利于發展的角色。工作中不快樂對任何人都沒有好處。

當我在通用汽車工作時，企業文化是這樣的：如果你不想著管理更多人或者負責更大更復雜的項目，那么你就是失敗者。對于多數人來說，這是一條苦不堪言的職業發展道路。

在 EDS 時，企業文化不是這樣，管理崗位人員是流動的。從策略規劃師等權限更大的崗位上下來從事項目管理或項目開發人員等權限更小的崗位并不是一件丟人的事。我就利用了這種人員的流動性，從技術金字頭頂端的角色回歸到了普通的項目開發人員。對此，我從不后悔。