譯文：我在20年的軟體工程師生涯中學到的20件事
在Simple Thread看到Justin Etheredge寫的一篇文章，覺得很多分享要點都寫得恰到好處、拳拳到肉，因此將文章翻譯成中文分享在此，供給大家賞析。
重要，請先閱讀
您即將閱讀一篇充滿建議的博客文章。從前人的經驗中學習對於成功至關重要，但我們常常忘記一個重要的附帶條件。幾乎所有的建議都是有情境的，然而很少有建議附帶了足夠的情境。
你只需要提高價格！這是一家已經經營了20年，花了多年的時間以太低的價格吸引客戶並取得成功的公司所說。
你需要將一切都建成微服務！這是一家迅速建立了單體應用，吸引了數千客戶，然後在擴展問題出現時轉向微服務的公司所說。
如果不了解情境，這些建議是毫無意義的，甚至更糟，有害的。如果那些人早期遵循了他們自己的建議，他們自己很可能會因此受害。要擺脫這個陷阱是困難的。我們可能是經驗的結晶，但我們是透過現在的視角來看待它們的。
因此，為了讓您對我的建議有一些情境了解，我前半生是一名軟體工程師，曾在各種小型企業和初創企業工作，然後我進入了諮詢領域，在一些非常大型的企業工作。然後我開始了Simple Thread，我們從一個2人的團隊發展成為一個25人的團隊。10年前，我們主要與中小企業合作，現在我們與大型和小型企業合作。
我的建議來自一位...
- 幾乎總是在小型，精益團隊中工作，在這些團隊中，我們必須用很少的資源完成很多工作。
- 價值實現的軟體過於特定的工具。
- 經常開始新的專案，但也必須維護多個系統。
- 價值工程師的生產力勝過大多數其他考慮因素。
過去20年的經驗塑造了我對軟體的看法，並導致我形成了一些信念，我嘗試縮減成一個可管理的清單，希望您會發現有價值。
清單開始
1. 我仍然不太懂很多事情
你怎麼可能不知道什麼是BGP？ 你從未聽說過Rust？ 我們中的大多數人可能常常聽到這些說法。我們之所以喜歡軟體，是因為我們是終身學習者，在軟體領域，不管你往哪個方向看，都有廣闊的知識領域不斷擴展。這意味著你可以在你的職業生涯中度過數十年，仍然與那些在看似相似的角色中度過數十年的人相比，有著巨大的知識差距。越早意識到這一點，你就越早能夠擺脫內心的冒充感，並樂於從他人那裡學習和教導他人。
2. 軟體中最難的部分是建立正確的事情
我知道這在某種程度上已經成了陳詞濫調，但大多數軟體工程師不相信它的原因是他們認為它貶低了他們的工作。個人而言，我認為這是荒謬的。相反，它突顯了我們必須在其中工作的環境的複雜性和不合理性，這加劇了我們的挑戰。你可以設計世界上技術上最令人印象深刻的事物，然後卻沒有人想使用它。這種情況經常發生。設計軟體主要是一種聆聽的活動，我們常常需要成為一部分軟體工程師，一部分心靈讀者，一部分人類學家。投資於這種設計過程，無論是通過專門的使用者體驗團隊成員還是簡單地自我教育，都將帶來巨大的回報。因為如何真正計算建立錯誤軟體的成本？它遠不止失去的工程時間。
3. 最優秀的軟體工程師像設計師一樣思考
優秀的軟體工程師深入思考他們代碼的使用者體驗。他們可能不以這些術語思考，但無論是外部API、程式API、用戶界面、協議還是任何其他界面，優秀的工程師考慮誰將使用它，為什麼會使用它，它將如何使用，以及對這些使用者來說什麼是重要的。將使用者的需求牢記在心實際上是良好用戶體驗的核心。
4. 最佳的代碼是無代碼，或不必維護的代碼
我只想說代碼寫手會寫代碼。你問任何行業的人如何解決問題，他們都會傾向於做他們擅長的事情。這只是人類的天性。大多數軟體工程師在非技術解決方案不明顯的情況下，總是傾向於編寫代碼，尤其是不需要維護的代碼。當已經有很多輪子存在時，工程團隊傾向於想要重新發明輪子。這是一個平衡的過程，有很多原因可以自己開發，但要小心有害的非自家研發症候群。
5. 軟體是達成目標的手段
任何軟體工程師的主要工作是提供價值。很少有軟體開發人員理解這一點，甚至更少的人內化了這一點。真正內化這一點會導致解決問題的不同方式，以及對工具的不同看法。如果你真的相信軟體是達成結果的工具，你將準備好真正找到適合工作的正確工具，這個工具可能不是軟體。
6. 有時你必須停止磨刀，開始解決問題
有些人傾向於立即著手解決問題並開始編寫代碼。而其他人則傾向於想要不斷進行研究，陷入分析困境。在這些情況下，為自己設定一個截止日期，並開始探索解決方案。當你開始解決問題時，你將迅速學到更多，這將引導你不斷改進，找到更好的解決方案。
7. 如果你對可能性的範圍不瞭解，你無法設計一個好的系統
這是我在負責的職責越來越遠離軟體工程的日常工作時經常遇到的問題。跟上開發者生態系統的進展是一項龐大的工作，但了解可能性是至關重要的。如果你不了解在特定生態系統中可能發生什麼以及可用的資源，那麼除了最簡單的問題外，你將無法設計出合理的解決方案。總結一下，要謹慎對待那些長時間沒有編寫過代碼的人設計系統。
8. 每個系統最終都會變差，接受這一點
Bjarne Stroustrup有一句話：只有兩種語言：人們抱怨的語言和沒人使用的語言。這也可以適用於大型系統。沒有正確的架構，你永遠無法還清所有的技術債務，你永遠無法設計出完美的界面，你的測試始終會太慢。這不是不改進的藉口，而是一種給予你觀點的方式。不要過於擔心優雅和完美；相反，努力不斷改進，創造一個讓你的團隊樂於工作並可持續提供價值的可用系統。
9. 沒有人問足夠多次的為什麼
利用任何機會質疑那些事情一直以來都是這樣做的假設和方法。有新的團隊成員加入嗎？注意他們在哪些地方感到困惑以及提出了什麼問題。有一個看似不合理的新功能請求嗎？確保你了解目標以及驅使對這個功能的需求是什麼。如果你沒有得到清晰的答案，就繼續問為什麼，直到你理解為止。
10. 我們應該更關注避免0.1x的程式設計師，而不是尋找傳說中的10x程式設計師
10x程式設計師是一個愚蠢的神話。某人在一天內可以生產出另一個能幹、勤奮、經驗相似的程式設計師在2周內才能完成的工作，這種想法是愚蠢的。我見過的程式設計師寫10倍的代碼，然後你不得不10倍地修復它。某人之所以能成為10x程式設計師，只是因為將他們與0.1x程式設計師進行了比較。浪費時間、不請教意見、不測試代碼、不考慮邊界情況等等...我們應該更關心如何不讓0.1x程式設計師加入我們的團隊，而不是尋找神話中的10x程式設計師。
11. 資深工程師和新手工程師之間最大的區別之一是他們對事物應該如何運作已形成看法
沒有什麼比一個資深工程師對工具或軟體建構方式沒有任何看法更讓我擔心了。我寧願有人提出我強烈不同意的意見，也不願意他們毫無意見。如果你使用工具，但對它們沒有多種方式的愛或恨，那麼你需要更多經驗。你需要探索其他語言、庫和範式。幫助提升技能的方法之一是積極尋求了解其他人如何使用不同的工具和技術來完成任務。
12. 人們實際上並不真正想要創新
人們經常談論創新，但他們通常尋求的是便宜的勝利和新奇。如果你真的進行創新，改變了人們做事的方式，那麼預計將會得到大多數負面反饋。如果你相信你所做的事情，並且知道它真的會改善事情，那麼請為長期戰鬥做好準備。
13. 你的數據是系統中最重要的部分
我見過許多系統，其中希望是數據完整性的主要機制。在這種系統中，任何偏離黃金路徑的事情都會產生部分或骯髒的數據。未來處理這些數據可能會變成一場噩夢。只要記住，你的數據可能會長期存在，花點精力保持其井然有序和乾淨，這將在長期內得到豐厚的回報。
14. 尋找技術上的鯊魚
那些長期存在的老技術，它們不是恐龍，而是科技鯊魚。它們能夠非常出色地解決問題，以至於在科技世界經常發生迅速變化的情況下仍然存活下來。不要對這些技術下反對的賭注，只有在你有非常充分的理由時才替換它們。這些工具不會華而不實，也不會令人興奮，但它們能夠在不需要熬夜的情況下完成工作。
15. 不要將謙虛誤解為無知
有很多軟體工程師不會主動表達意見，除非被問及。永遠不要假設只因為某人不在你面前大聲表達他們的意見就表示他們無所附加。有時最吵雜的人恰恰是我們最不願意聽的人。與身邊的人交談，尋求他們的反饋和建議。你會感到高興的。
16. 軟體工程師應該定期撰寫
軟體工程師應該定期撰寫部落格、日誌、撰寫文件，總之，做一切需要他們保持書面溝通技能磨練的事情。寫作有助於思考問題，並有助於更有效地與團隊和未來的自己進行溝通。良好的書面溝通是任何軟體工程師必須掌握的最重要技能之一。
17. 保持流程盡可能簡潔
如今每個人都想要成為敏捷，但敏捷是指以小塊方式建立事物，學習，然後進行反覆。如果有人試圖強加更多東西，那麼他們可能在兜售某些東西。這並不是說人們不需要負責或需要幫助以這種方式工作，但你是否聽說過來自你最喜歡的科技公司或大型開源項目的人如何吹噓他們的Scrum流程有多出色？在你確定需要更多之前，保持流程簡潔。相信你的團隊，他們會交付的。
18. 軟體工程師，如同所有人類，需要擁有感
如果你將某人與他們的工作成果分開，他們對工作的關心程度將會降低。我幾乎將這視為自明的事實。這是跨功能團隊工作得如此順利的主要原因，也是DevOps變得如此流行的原因。這不僅僅是關於交接和效率，而是關於從頭到尾擁有整個過程，並對交付價值負有直接責任。讓一群熱情的人完全擁有設計、建立和交付軟體（或任何東西）的權利，將會產生驚人的成果。
19. 面試幾乎無法評估一個人是否是一個出色的團隊成員
面試更好地用於了解一個人是誰，以及他們對某一專業領域有多感興趣。試圖弄清楚他們是否是一個優秀的團隊成員是一項無效的工作。相信我，一個人是否聰明或知識豐富也不是衡量他們是否是優秀團隊成員的好指標。沒有人會在面試中告訴你他們將不可靠、傲慢、自大，或不會按時參加會議。人們可能會聲稱他們對這些事情有信號… 如果他們在第一次面試中詢問休假時間，那麼他們將永遠不會出現！ 但這些都是胡說八道。如果你使用這些信號，你只是在猜測，並拒絕了優秀的候選人。
20. 始終努力構建一個更小的系統
有許多因素會推動你一開始就建立更大的系統。預算分配、難以決定應該刪減哪些功能、以及渴望交付系統的最佳版本，所有因素都會極大地推著我們去我們建立過多的東西。你應該對此加以抵制。在建立系統的過程中，你會學到很多，最終你會將其演進成一個比你一開始設計的更好的系統。這對大多數人來說出奇地難以接受。