批判性思考并提出合理的論點

批判性思維是使用認知技能獨立思考以做出深思熟慮的決定的能力。投資于這項技能，以提高你的思路清晰。

作為工程師，我們有時會急于立即解決問題，因此感覺就像我們正在取得進展，或者看起來我們正在對利益相關者做出響應。如果我們沒有充分考慮原因和后果，這可能會帶來風險。換句話說，批判性思維是有目的地思考并形成自己的結論。這種以目標為導向的思維可以幫助你專注于根本原因問題，從而避免未來因不牢記原因和后果而出現的問題。

熟練掌握“可轉移”技能

可轉移的技能指的是可以從一個項目帶到另一個項目的技能。

基本原理是任何軟件工程工作的基礎。它們有兩個層面——宏觀和微觀。宏觀層是軟件工程的核心，微觀層是實現（例如技術棧、庫、框架等）。

在宏觀層面上，你學習的編程概念在很大程度上是可以轉移的，不管是什么語言，語法可能有所不同，但核心思想仍然是相同的。這包括：數據結構（數組、對象、模塊、哈希）、算法（搜索、排序）、架構（設計模式、狀態管理）甚至性能優化（例如緩存、延遲加載等）。這些都是你經常使用的概念，對它們進行逆向了解會有很大的價值。

在微觀層面上，您需要學習這些概念的實現。這可能包括：你使用的語言（JAVAScript、Python/ target=_blank class=infotextkey>Python、Ruby 等）、你使用的框架（如 React、Angular、Vue 等）、你使用的后端（如 Django、Rails 等）以及技術你使用的堆棧（例如 google App Engine、Google Cloud Platform 等）。其中涉及的細節對于獲得有效的專業知識可能很有價值，但并不總是可以轉移的。

專注于用戶，其余的將隨之而來

從用戶體驗開始，倒推你需要的技術

史蒂夫喬布斯曾經說過一句名言：“你必須從客戶體驗開始，然后再回到技術。你不能從技術開始，然后試圖弄清楚在哪里銷售它”。

作為工程師，我們太容易從想要使用特定解決方案的地方開始--無論是由于流行、開發者經驗還是個人偏好--并試圖找到一種方法來合理地使用它們。相反，我們應該專注于我們是為誰建立的，他們有什么問題，以及目前可用的選項是如何落空的。

偉大的用戶體驗來自于兩個觀點的結合--客戶和技術。向人們展示你認為他們想要的東西，并注意他們所反饋的內容。企業的成功取決于客戶的滿意度，而客戶的滿意度往往轉化為軟件的用戶體驗。

打造技能的深度與廣度

我非常喜歡 T-Shaped 工程師的想法。這些工程師在一項或少數幾項技能方面是深度專家（T 的豎條），但他們對構建和運行產品所需的許多其他技能（橫條）也都有基本了解。有些團隊喜歡通過一系列不同的專業來輪換團隊成員，以建立更多的 T 型團隊成員。我還發現，在中等規模的團隊中，擁有某個領域的專業技能和技能、多才多藝、善于合作的人，在必要時可以替代其他人，這是很有效的。

通用代碼與特定代碼

為手頭的問題編寫專門的代碼，但要努力發現那些你可以負擔得起的地方，使其成為一個小的通用的代碼。

通常情況下，我們試圖把代碼寫得盡可能的通用，最終卻使那些有效的代碼不能幫助完成問題。相反，專門為這個問題而構建，但試圖發現可以讓它變得更通用的地方，這完全消除了未來沒有考慮到這一點導致不得不再次重構的情況。

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

https://ronjeffries.com/xprog/articles/practices/pracsimplest/

在維護項目中學習

在處理舊系統中的遺留代碼時，任何高級工程師都應該盡量理解留下的代碼和舍棄的代碼之間的區別。軟件行業已經到了一個階段，許多項目都在處理舊的或遺留系統的維護和遷移問題。部分軟件工程師對修改生產中的代碼持謹慎態度，因為他們擔心會引入一個錯誤。但不要假設現有代碼是完全可靠的，隨著時間的遷移，節省時間的做法可能會成為維護的噩夢。

設計文檔的重要性

設計文檔不應該是事后的想法，而應該是軟件工程過程中的一個組成部分。

設計文檔可以幫助你從同行或者對接團隊中獲得共識，來自他人的反饋能使你找出差距并改善設計。設計文檔還能幫助未來新加入團隊的工程師更好的理解當前系統。

拒絕的力量

說“不”比過度承諾更好。在涉及更多工作的情況下，我們大多數人都不善于說“不”。一方面是大家沒有意識到“不”是一種選擇，一方面是我們喜歡這種挑戰。然而，過度承諾是一種責任，而且可能會造成項目延誤。讓對方知道你已經在做什么，并提供一個合理的估計（需要多長時間）是一種尊重的表現。

技術債務

Titus Winters 將技術債務定義為“我們今天擁有的代碼和系統與我們希望擁有的代碼和系統之間的差異”，某些類型的債務比其他類型的影響更大。有些債務可能是由于沒有及早發現的錯誤（疏忽），有些是由于事后了解到的情況，有些是由于技術系統環境的變化（背景）。

堅持優先處理技術債務有時是很難的，因為你不可能總是量化那些沒有表現出來的錯誤或沒有發生的故障。如何防止債務積累？除了構建新功能外，技術主管還應定期在 Sprint 周期中投入時間進行清理和償還債務。審稿人應該意識到推動短期速度實際上可能會導致進一步的問題。經理和主管應該注意批準與現有項目重疊的新項目，除非你確定權衡是值得的（例如，解決現有系統的債務與建立新的東西相比不值得）。最后，監控項目的健康狀況非常重要。