[[427794]]

近日，新聞網站 Hacker News 一個帖子可謂火爆，該貼內容講的是一位有 20 年軟件經驗的工程師，學到的 20 件事。

如果你在科技領域工作多年，有什么對后來人要說的話?這篇文章中包含 20 條建議，許多建議都是來自他人的一些經驗總結。文章作者 Justin Etheredge 工作經歷可謂豐富，他的職業生涯中前半部分是軟件工程師，為各種小型企業和初創公司工作，然后進入咨詢行業并在許多真正的大型企業中任職。之后 Justin Etheredge 職業發展良好，團隊從 2 人發展到 25 人。10 年前，Justin Etheredge 主要與中小型企業合作，現在他們與大型和小型企業合作。

這 20 條建議主要來自以下這些人的經驗總結：

• 那些幾乎總是在小的、精益的團隊中工作的人，因為他們能用很少的資源做更多的事情;
• 那些重視工作軟件開發而不是特定工具的人;
• 那些一直都在開展新的項目，而且還要兼顧維護一些其他系統的人;
• 那些將工程師的生產力當作第一要務，置于其他工作之上的人。

Justin Etheredge 表示，自己在過去 20 年的經歷塑造了他對軟件的看法，并產生了一些信念，他試圖將這些信念縮減為一個可管理的列表，希望這些建議能給別人帶來價值。

Justin Etheredge 的 20 條經驗分享

1. 我還是什么都不懂

我們中的大多數人可能都會頻繁聽到類似這樣的話，「你怎么會不知道什么是 BGP?你從沒聽說過 Rust?」我們中的許多人喜歡軟件的原因是因為我們是終身學習者，在軟件領域，無論你朝哪個方向發展，都有廣闊的知識視野向各個方向傳播，并且發展方向每天都在擴展。這意味著你可以在職業生涯中度過幾十年，但與在看似相似的角色上也花了幾十年的人相比，軟件領域的人仍然存在巨大的知識差距。你越早意識到這一點，你就可以越早擺脫冒名頂替綜合癥，而是樂于向他人學習和教導他人。

2. 軟件最困難的部分是構建正確的內容

大多數軟件工程師不相信這一點的原因是因為他們認為這貶低了自己的工作。然而相反的是，恰恰是這一點突出了軟件工程師工作環境的復雜性和非理性，這進一步加劇了軟件工程師的挑戰。你可以設計出在技術上最令人驚嘆的東西，然而糟糕的是，最后沒人愿意使用它。這種事情無時無刻不在發生。設計軟件主要是一種傾聽需求的活動，通常我們必須兼任軟件工程師、聆聽者和人類學家的身份。專注于這個設計過程，無論是通過專門的 UX 團隊成員還是通過簡單的自我教育，都將帶來巨大的回報。

3. 最好的軟件工程師需要像設計師一樣思考

偉大的軟件工程師會深入思考他們所寫代碼的用戶體驗。例如外部 API、編程 API、用戶界面、協議還是其他接口， 優秀的軟件工程師會考慮誰將使用他們的研究、為什么使用它、如何使用以及對這些用戶來說什么是重要的。牢記用戶需求才是良好用戶體驗的核心。

4. 最好的代碼是沒有代碼，或者是不需要維護的代碼

編程人員需要會編程。大多數人都會在自己擅長的方面犯錯，這是人的本性。很多軟件工程師經常在編寫代碼方面犯錯，尤其是當非技術解決方案不明顯時。無需人員維護的代碼也是如此。當很多算法已經存在時，工程團隊很容易想要開辟新的方法，這是一個平衡的行為。

有很多理由讓你重新發明輪子，但需要注意的是「非原創」并不在其中。

5. 軟件是達到目的的一種手段

軟件工程師的主要工作是交付價值， 但很少有軟件開發人員了解這一點，甚至有更少的軟件開發人員將其內在化。真正內在化會導致解決問題的不同方式，以及查看工具的不同方式。如果你真的相信軟件是服從于結果的，你就會準備好真正找到適合工作的工具，而這可能根本不是軟件。

6. 為自己設定截止日期

有些人傾向于深入問題并開始編寫代碼，而有些人只想研究理論，沒有著手代碼，進而讓自己陷入困難的漩渦。在這些情況下，為自己設定一個截止日期，然后開始探索解決方案。當你開始解決問題時，你會很快學到更多，這將引導你迭代到更好的解決方案。

7. 如果你不能很好地把握可能發生的一切，你就不能設計一個好的系統

與開發者生態系統進展保持一致是一項巨大的工作，了解生態系統中哪些是至關重要的，如果你不了解給定生態系統中哪些是可能的，哪些是可用的，那么除了能發現最簡單的問題之外，你不可能為所有問題設計一個合理的解決方案。總而言之，你要警惕那些很長時間沒有編寫任何代碼設計系統的人。

8. 每個系統都會很糟糕，你需要克服

Bjarne Stroustrup 有一句名言：只有兩種語言，即人們抱怨的語言和沒人使用的語言。這一名言可以擴展到大型系統。如果沒有正確的軟件架構，你永遠無法償還所有的技術債務，你永遠無法設計出完美的界面。盡量少擔心系統的優雅和完美， 相反，要努力持續改進你的系統，并創建一個團隊喜歡在其中工作的適宜系統，并可持續地提供價值。

9. 多問為什么

抓住任何機會進行詢問。例如「有新的團隊成員加入嗎?注意他們在哪里出現混淆以及他們問的什么問題。有一個沒有意義的新功能請求?」等等這些看似不起眼的問題。確保自己了解目標以及推動此功能需求的因素。如果你沒有得到明確的答案，請繼續問為什么，直到明白為止。

10. 程序員大神都是傳說

尋找工作效率能達到 10 倍的程序員是不可取的。那些所謂的一個人可以在 1 天內完成另一個程序員(有能力、努力工作、同樣有經驗的)在 2 周內完成的想法是愚蠢的。假如程序員拋出 10 倍數量的代碼，那么你需要 10 倍數量的精力修復它。一個人成為 10 倍程序員的唯一方法是將他們與 0.1 倍程序員進行比較。一個浪費時間、不尋求反饋、不測試代碼、不考慮邊緣情況等的人…… 我們應該更關注的是讓 0.1 倍的程序員遠離我們的團隊，而不是尋找神話般的 10 倍程序員。

11. 工程師需要更多的建議

最讓人擔心的是沒有人對高級工程師構建的軟件提出意見，相反的，他們寧愿希望有人提出強烈的反對意見，也不愿別人根本沒有意見。如果你正在使用某個工具，你需要更多的體驗才能知道這個工具的優勢和劣勢，對于劣勢，你可能需要探索其他語言、庫和范式才能解決。除了積極尋找別人是如何使用不同的工具和技術完成任務之外，沒有什么方法能更快地提升你的技能。

12. 你根本不懂什么是創新

人們經常談論創新，但他們通常尋找的是廉價的勝利。如果你真的在創新，并改變了人們做事的方式，那么你應該期待負面的反饋。如果你相信你正在做的事情，并知道它真的會改善一些事物，那么你需要準備好迎接一場長期的戰斗。

13. 數據是系統中最重要的部分

對于許多程序員來說，數據是系統中最重要的部分。在這樣的系統中，發生在黃金路徑之外的任何操作都會產生臟數據。將來處理這些臟數據可能會變成一場噩夢。請記住，數據可能會比代碼庫存在時間更長。花精力保持數據的有序和清潔，從長遠來看，你會得到很好的回報。

14. 尋找技術「鯊魚」

一直存在的舊技術可看作「鯊魚」，而不是「恐龍」。這些舊技術很好地解決了問題，以至于在不斷快速變化的技術世界中幸存下來。但是請不要隨意替換這些技術，只有在有充分理由的情況下才替換它們。這些技術不會花哨，也不會令人興奮，但它們會在很多情況下完成工作。

15. 不要誤以為謙卑就是無知

很多軟件工程師不會發表意見，除非被要求才會提出意見。不要以為別人不發表自己的觀點就沒有什么可補充的。有時候，最聒噪的人恰恰是我們最不想聽的人。和你周圍的人交談，尋求他們的反饋和建議。你會慶幸你這么做了。

16. 軟件工程師應該定期記錄研究

軟件工程師應該定期寫博客、寫日記、寫文檔，多做那些保持書面溝通技巧的事情。寫作可以幫助軟件工程師思考問題，并幫助自己與團隊更有效地溝通。良好的書面溝通是任何軟件工程師都需要掌握的最重要的技能之一。

17. 讓過程盡可能的精簡

如今，每個人都想變得敏捷，但敏捷是通過構建小塊的東西，然后學習、迭代完成的。如果有人想把更多的東西塞進去，這是不可取的。在工作中，你很少聽到科技公司或大型開源項目吹噓他們的 Scrum 流程有多棒?在工作中保持精益求精。

18. 軟件工程師需要有主人翁的感覺

如果你讓某人遠離他們的工作成果，他們就不會那么關心自己的工作。這就是為什么跨職能團隊工作得如此出色，以及為什么 DevOps 變得如此流行的主要原因。這不僅僅是關于交接和低效率，而是關于從頭到尾擁有整個過程，并直接負責交付價值。讓一群充滿激情的人完全擁有設計、構建和交付軟件(或任何真正的東西)的所有權，令人驚奇的事情就會發生。

19. 面試對于說明一個團隊成員的優秀程度幾乎沒有價值

面試的意義在于了解他 / 她是誰，以及他們對于特定專業領域的興趣程度。而面試「原本該有」的意義，試圖了解他們是否能夠成為一個優秀團隊成員的努力都是徒勞的。相信我，一個人的聰明或博學程度和他是否能夠在團隊中做到貢獻沒有太大關系。沒有人會在面試中告訴你，他們會不可靠、隨便罵人、自負或從不準時出席會議。

有人可能會聲稱他們可以在面試中看出端倪「如果他們在第一次面試中詢問休息時間，那就要小心了。」但這些都是胡說八道。如果你使用這樣的信號作為評判標準，你只是在猜測并拒絕優秀的候選人。

20. 小即是美

有很多力量會促使你預先構建更大的系統。要求更多的預算，無法決定削減哪項功能，希望提供系統的「最佳版本」，所有這一切都在推動我們構建過多，但你應該為反對這種趨勢而戰。構建一個系統地時候，你會學習到很多東西， 這會和你當初的設想大為不同。但對于很多人來說，以最好為目標是很難的。

老程序員的這些建議或許可以為你帶來一些幫助。在成為一名開發者之后，你是否也有踩過的坑，或者總結出來的經驗?

原文鏈接：https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/

【本文是51CTO專欄機構“機器之心”的原創譯文，微信公眾號“機器之心( id: almosthuman2014)”】 

戳這里，看該作者更多好文