做軟件開發20年，我學到的20件事
本文已獲得原作者Justin Etheredge的翻譯授權 原文鏈接
寫在前面
你即將讀的這篇文章會給你很多建議，向前輩學習對於獲得成功是很有幫助的，但我們經常會忘記很重要的一點，就是幾乎所有的建議都是有其特定場景和上下文的，但當人們給出建議的時候卻很少帶着上下文。 一家一直以來以“收費低”而獲得成功，並經營了二十年的公司可能會給出的建議是“你只需要多收些錢！”。 “你需要把所有應用都構建成微服務”這個建議可能來自於一個靠快速構建的單體應用獲得成千上萬客户，在開始遇到規模問題時轉向微服務的團隊。
如果不理解上下文，這些建議就毫無意義，甚至是有害的。如果這些人早些時候聽從了自己的建議，那結果如何也很難講。我們很可能處在自己經歷的頂峯，但卻在用現在的視角看待別人的問題。
首先我想介紹一下我的建議從哪兒來，我職業生涯的前半段是一名軟件工程師，為各種小型企業和初創企業工作，然後進入諮詢行業，並在一些非常大的企業工作。後來自己創建了Simple Thread，團隊從2人發展到25人。10年前，我們主要與中小型企業合作，現在與大大小小不同的企業合作。
我的建議來自於這些人： 1. 幾乎總是在小而精幹的團隊中，必須用很少的資源做很多事情。 2. 重視可工作軟件而不是特定的工具。 3. 在維護多個系統的同時，一直有新的項目要啟動。 4. 把工程師的生產力看得比大多數其他因素都重要。 我過去20年的經歷塑造了我對軟件的看法，並引導我形成了一些信念，我試圖將這些信念精簡併整理成一個列表，希望你會覺得它對你有所幫助。
我的列表
1.“我依然知道的不夠多”
“你怎麼會不知道BGP是什麼?“ “你從來沒聽説過Rust嗎?”。我們很多人經常聽到過類似的話。很多人喜歡軟件開發的一個重要的原因是我們是終身學習者，軟件開發中，無論你從哪個方向看，都有廣闊的知識前景在各個方向發展，並且每天都在擴大。這意味着與其他職業中花費幾十年的人相比，你即使已經花費了數十年，但可能仍然有巨大的知識斷層，有很多新知識需要學習，你可能因為擔心不能勝任而陷入焦慮。你越早意識到這一點，你就能越早擺脱這種時常的焦慮，從而放平心態，樂於向別人學習以及教授他人。
2.軟件最難的部分是構建正確的東西
我知道這已經是陳詞濫調了，但是還是有很多軟件工程師不相信這一點，因為他們認為這會貶低他們所做的工作。我個人認為這是無稽之談。相反，它強調了我們工作環境的複雜性和非理性，這更突出了我們所面臨的挑戰。你可能可以設計出全世界技術上最牛的東西，但卻沒有人願意使用它，這種事經常發生。設計軟件主要是一種傾聽活動，我們經常不得不一半是軟件工程師，一半是心理學家，一半是人類學家。在這個設計過程中投資自己，無論是通過專門的用户體驗團隊的成員還是通過簡單的自學，都會帶來巨大的回報。因為構建錯誤軟件的成本可不僅僅是浪費了工程師的時間。
3.最好的軟件工程師會像設計師一樣思考
優秀的軟件工程師會深入考慮他們代碼的用户體驗。他們可能不會用這些術語來考慮它，而是考慮它是外部API、編程式API、用户界面、協議還是任何其他接口;優秀的工程師會考慮誰會使用它，為什麼會使用它，如何使用它，以及對這些用户來説什麼是重要的。牢記用户的需求才是好的用户體驗的核心。
4.最好的代碼是沒有代碼，或者不需要維護的代碼
任何職業的人解決問題的過程中都會在自己擅長的方面犯錯誤，這是人的本性。大多數軟件工程師在編寫代碼免不了會犯錯誤，尤其是當還沒有可行的非技術性解決方案時。工程團隊總是傾向於在已經有很多輪子的時候重新發明輪子。有很多原因讓你自己重新做一個輪子，但一定要警惕有毒的“Not invented here”綜合症，不能閉門造車，妄自尊大，儘量複用和尋找非技術性解決方案。
5.軟件是達到目的的一種手段
任何軟件工程師的主要工作都是交付價值。很少有軟件開發人員能理解這一點，更少人能內化它。真正的內在化會帶來一種不同的解決問題的方式，以及一種不同的看待工具的方式。如果你真的相信軟件是屈從於結果的，你就會準備好真正找到“適合這項工作的工具”，而這個工具可能根本不是軟件。
6.有時候你不得不停止磨刀，開始切東西
有些人傾向於一頭扎進問題中，然後開始編寫代碼解決問題。有些人卻傾向於花大量時間研究和調查，但卻讓自己陷進問題中。在這種情況下，給自己設定一個最後期限，然後開始探索解決方案。當你開始解決這個問題的時候，你會很快學到更多的東西，這將引導你迭代形成一個更好的解決方案。
7.如果你不能很好地把握全局的可能性，你就無法設計出一個好的系統
這是我在每天的工作中不斷努力的事情。與開發者生態保持同步是一項巨大的工作，但瞭解開發者生態中的可能性卻是至關重要的。如果你不瞭解在一個給定的生態系統中什麼是可能的，什麼是可用的，那麼你就不可能設計出一個合理的解決方案來解決所有的問題，除非是最簡單的問題。總而言之，要警惕那些很長時間沒有編寫任何代碼的系統設計者。
8.每個系統最終都很糟糕，克服它吧
比雅尼·斯特勞斯特魯普（Bjarne Stroustrup）有一句話是這樣説的: “世界上只有兩種語言，一種是人們抱怨的語言，另一種是沒人用的語言。”。這也可以擴展到大型系統。不存在“正確”的架構，你永遠無法償還所有的技術債務，你永遠無法設計出完美的界面，你的測試總是太慢。這不是個能讓事情變得更好的藉口，而是一種讓你看問題的方式。少擔心優雅和完美；相反，要努力持續改進，創建一個你的團隊喜歡並可持續提供價值的環境。
9.沒人去問“為什麼”
抓住任何機會去質疑那些“一直以來都是這樣做的”假設和方法。有新隊員加入？那就注意他們在哪裏感到困惑，他們問了什麼問題。有一個沒有意義的新功能需求？確保你理解了目標，以及是什麼驅動了這種功能的需求。如果你得不到一個明確的答案，繼續問為什麼，直到你明白。
10.我們應該更加關注如何避免0.1x程序員，而不是尋找10x程序員
10倍的程序員其實是一個愚蠢説法。認為一個人可以在一天內完成另一個有能力、勤奮、同樣有經驗的程序員可以在兩週內完成的任務是愚蠢的。我見過程序員拋出10倍的代碼量，然後你必須用10倍的時間來修正它。一個人成為10倍程序員的唯一方法就是將他與0.1倍程序員進行比較。有些人浪費時間，不尋求反饋，不測試他們的代碼，不考慮邊界情況等等。我們更應該關心的是讓0.1x程序員遠離我們的團隊，而不是找到神祕的10x程序員。
11.高級工程師和初級工程師之間最大的區別之一就是他們對事情應該如何發展形成了自己的觀點
沒有什麼比高級工程師對他們的工具或如何構建軟件一無所知更讓我擔心的了。我寧願有人給我一些強烈的反對觀點，也不願他們沒有任何觀點。如果你正在使用你的工具，並且你並不喜歡或討厭它們，那麼你就需要體驗更多。您需要探索其他語言、庫和範式。沒有什麼方法比積極地尋找別人如何用不同的工具和技術來完成任務能更快地提升你的技能了。
12.人們不是真的想要創新
人們經常談論創新，但他們通常尋找的是廉價的勝利和新奇的東西。如果你真的在創新，改變人們做事的方式，那麼大部分的反饋都是負面的。如果你相信你正在做的事情，並且知道它真的會改善事情，那麼就做好長期鬥爭的準備。
13.數據是系統中最重要的部分
我見過許多對數據完整性要求很高的系統。在這樣的系統中，任何發生在關鍵路徑之外的事情都會創建部分數據或髒數據。將來處理這些數據可能會成為一場噩夢。請記住，您的數據可能比代碼庫存在的時間更長。把精力花在保持它的有序和清潔上，從長遠來看它會得到很好的回報。
14.尋找技術”鯊魚“
許多留下來的老技術是”鯊魚“，而不是”恐龍“。他們能夠很好地解決問題，並在技術不斷快速變化的今天生存了下來。只有在有一個很好的理由的情況下，再去替換它們。這些工具不會華而不實，也不會令人興奮，但是它們可以完成工作，避免很多不必要的不眠之夜。
15.不要把謙卑誤認為無知
有很多軟件工程師在沒有被提問的時候，是不怎麼發表意見的。永遠不要以為別人沒有他們的觀點擺在你面前，你就覺得他們沒有什麼觀點。有時候最吵的人恰恰是我們最不想聽的人。與你周圍的人交談，尋求他們的反饋和建議。你會有意外收穫。
16.軟件工程師應該定期寫作
軟件工程師應該定期寫博客，寫日誌，寫文檔，去做任何保持書面溝通技能的事情。寫作可以幫助你思考問題，並幫助你與團隊和未來的自己更有效地溝通。良好的書面溝通能力是任何軟件工程師都需要掌握的最重要的技能之一。
17.保持流程儘可能精簡
如今，每個人都想變得敏捷，“敏捷”就是把事情分成小塊，學習，然後迭代。如果有人試圖把更多的東西塞進去，那他很可能是在賣東西。想想你有多少次聽到來自你最喜歡的技術公司或大型開源項目的人在吹噓他們的Scrum流程有多棒?在你知道你需要更多的東西之前，請依靠流程。相信你的團隊，他們會完成任務。
18.軟件工程師，像所有人一樣，需要有歸屬感
如果你把某人和他的工作成果分開，他就不會那麼在乎他的工作。我認為這幾乎是同義反復。歸屬感是跨職能團隊工作得如此出色的主要原因，也是DevOps變得如此流行的原因。這並不全是關於交接和低效的問題，而是關於從開始到結束去參與和享受整個過程，並直接負責交付價值。讓一羣充滿激情的人完全擁有設計、構建和交付一個軟件(或者其他任何東西)的所有權，奇妙的事情就會發生。
19.面試對於判斷一個團隊成員是否優秀幾乎毫無價值
面試最好是試着瞭解對方是誰，以及他們對某一特定專業領域有多大興趣。試圖弄清楚一個團隊成員會有多好是徒勞的努力。相信我，一個人有多聰明或多有知識也不能很好地表明他們將是一個優秀的團隊成員。沒有人會在面試中告訴你，他們會不可靠，會罵人，會誇誇其談，或者從不準時出席會議。人們可能會説他們在這些事情上有“信號”……“如果他們在第一次面試時就問請假，那麼他們就永遠不會在那裏了!” 但這些都是胡扯。如果你使用這樣的信號，你只是在猜測，並將優秀的候選人拒之門外。
20.始終努力構建一個更小的系統
有很多的力量將推動你預先建立更大的系統。預算分配，無法決定哪些功能應該被削減，希望交付系統的“最佳版本”。所有這些事情會迫使我們過度建設。你應該與之抗爭。在構建系統的過程中，你會學到很多東西，最終迭代得到的系統將比你最初設計的系統要好得多。令人驚訝的是，這很難説服大多數人。