不要拒絕面試詢問休假時間的人：20年老程序員總結(jié)的經(jīng)驗(yàn)

視學(xué)算法報道

機(jī)器之心編輯部

任何人都可以寫代碼，但并不是所有人都適合寫代碼。

近日，新聞網(wǎng)站 Hacker News 一個帖子可謂火爆，該貼內(nèi)容講的是一位有 20 年軟件經(jīng)驗(yàn)的工程師，學(xué)到的 20 件事。

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

這 20 條建議主要來自以下這些人的經(jīng)驗(yàn)總結(jié)：

• 那些幾乎總是在小的、精益的團(tuán)隊(duì)中工作的人，因?yàn)樗麄兡苡煤苌俚馁Y源做更多的事情；

• 那些重視工作軟件開發(fā)而不是特定工具的人；

• 那些一直都在開展新的項(xiàng)目，而且還要兼顧維護(hù)一些其他系統(tǒng)的人；

• 那些將工程師的生產(chǎn)力當(dāng)作第一要務(wù)，置于其他工作之上的人。

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

Justin Etheredge 的 20 條經(jīng)驗(yàn)分享

1. 我還是什么都不懂

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

2. 軟件最困難的部分是構(gòu)建正確的內(nèi)容

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

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

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

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

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

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

5. 軟件是達(dá)到目的的一種手段

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

6. 為自己設(shè)定截止日期

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

7. 如果你不能很好地把握可能發(fā)生的一切，你就不能設(shè)計一個好的系統(tǒng)

與開發(fā)者生態(tài)系統(tǒng)進(jìn)展保持一致是一項(xiàng)巨大的工作，了解生態(tài)系統(tǒng)中哪些是至關(guān)重要的，如果你不了解給定生態(tài)系統(tǒng)中哪些是可能的，哪些是可用的，那么除了能發(fā)現(xiàn)最簡單的問題之外，你不可能為所有問題設(shè)計一個合理的解決方案?？偠灾?，你要警惕那些很長時間沒有編寫任何代碼設(shè)計系統(tǒng)的人。

8. 每個系統(tǒng)都會很糟糕，你需要克服

Bjarne Stroustrup 有一句名言：只有兩種語言，即人們抱怨的語言和沒人使用的語言。這一名言可以擴(kuò)展到大型系統(tǒng)。如果沒有正確的軟件架構(gòu)，你永遠(yuǎn)無法償還所有的技術(shù)債務(wù)，你永遠(yuǎn)無法設(shè)計出完美的界面。盡量少擔(dān)心系統(tǒng)的優(yōu)雅和完美， 相反，要努力持續(xù)改進(jìn)你的系統(tǒng)，并創(chuàng)建一個團(tuán)隊(duì)喜歡在其中工作的適宜系統(tǒng)，并可持續(xù)地提供價值。

9. 多問為什么

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

10. 程序員大神都是傳說

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

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

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

12. 你根本不懂什么是創(chuàng)新

人們經(jīng)常談?wù)搫?chuàng)新，但他們通常尋找的是廉價的勝利。如果你真的在創(chuàng)新，并改變了人們做事的方式，那么你應(yīng)該期待負(fù)面的反饋。如果你相信你正在做的事情，并知道它真的會改善一些事物，那么你需要準(zhǔn)備好迎接一場長期的戰(zhàn)斗。

13. 數(shù)據(jù)是系統(tǒng)中最重要的部分

對于許多程序員來說，數(shù)據(jù)是系統(tǒng)中最重要的部分。在這樣的系統(tǒng)中，發(fā)生在黃金路徑之外的任何操作都會產(chǎn)生臟數(shù)據(jù)。將來處理這些臟數(shù)據(jù)可能會變成一場噩夢。請記住，數(shù)據(jù)可能會比代碼庫存在時間更長?；ňΡ３?jǐn)?shù)據(jù)的有序和清潔，從長遠(yuǎn)來看，你會得到很好的回報。

14. 尋找技術(shù)「鯊魚」

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

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

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

16. 軟件工程師應(yīng)該定期記錄研究

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

17. 讓過程盡可能的精簡

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

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

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

19. 面試對于說明一個團(tuán)隊(duì)成員的優(yōu)秀程度幾乎沒有價值

面試的意義在于了解他 / 她是誰，以及他們對于特定專業(yè)領(lǐng)域的興趣程度。而面試「原本該有」的意義，試圖了解他們是否能夠成為一個優(yōu)秀團(tuán)隊(duì)成員的努力都是徒勞的。相信我，一個人的聰明或博學(xué)程度和他是否能夠在團(tuán)隊(duì)中做到貢獻(xiàn)沒有太大關(guān)系。沒有人會在面試中告訴你，他們會不可靠、隨便罵人、自負(fù)或從不準(zhǔn)時出席會議。

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

20. 小即是美

有很多力量會促使你預(yù)先構(gòu)建更大的系統(tǒng)。要求更多的預(yù)算，無法決定削減哪項(xiàng)功能，希望提供系統(tǒng)的「最佳版本」，所有這一切都在推動我們構(gòu)建過多，但你應(yīng)該為反對這種趨勢而戰(zhàn)。構(gòu)建一個系統(tǒng)地時候，你會學(xué)習(xí)到很多東西， 這會和你當(dāng)初的設(shè)想大為不同。但對于很多人來說，以最好為目標(biāo)是很難的。

老程序員的這些建議或許可以為你帶來一些幫助。在成為一名開發(fā)者之后，你是否也有踩過的坑，或者總結(jié)出來的經(jīng)驗(yàn)？

原文鏈接：

https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/

??THE END?

轉(zhuǎn)載請聯(lián)系機(jī)器之心公眾號獲得授權(quán)

投稿或?qū)で髨蟮溃篶[email protected]

點(diǎn)個在看 paper不斷！