20 年軟體工程生涯所學到的 20 件事 (摘譯)
最近重閱「20 Things I’ve Learned in my 20 Years as a Software Engineer」有感。
作者是 Justin Etheredge,顧問,Simple Thread 創辦人。
image credit : https://pixabay.com/photos/code-html-digital-coding-web-1076536/
1. I still don’t know very much
我還是不太瞭解
「你怎麼可能不知道 BGP 是什麼?」「你沒聽說過 Rust 嗎?」我們大多數人都聽過類似說法,而且很常。
很多人喜歡軟體,是因為我們持續學習。在軟體領域,無論你往哪個方向,都有遠闊的知識景深。你愈早瞭解這點,就能愈早擺脫冒名頂替綜合症,然後樂於向他人學習和指導。
2. The hardest part of software is building the right things
軟體最難的部分是做出正確的東西
軟體領域常見設計出了世界上最令人印象深刻的技術,但卻沒有人願意使用的情形。軟體設計是一種傾聽互動,經常需要身兼軟體工程師、心理學家,以及人類學家。要學著如何避免建構錯誤軟體的成本,這不僅是損失工程的時間。
3. The best software engineers think like designers
最好的軟體工程師像設計師一樣思考
優秀的工程師會考慮誰會使用、為什麼會使用、如何使用,以及對使用者什麼是重要的。把使用者的需求放在心上,這才是做好使用者體驗的核心。
4. The best code is no code, or code you don’t have to maintain
最好的程式是沒有程式,或者是不需要維護的程式
大多數軟體工程師總是傾向撰寫程式,特別是非技術性解決方案不明確時。工程團隊很容易重新發明輪子,但輪子已經夠多了,我們需要的是平衡。總有很多理由讓我們覺得造輪會成長,但要小心有毒的「弊帚自珍/非我所創」綜合症 (Not Invented Here Syndrome)。
5. Software is a means to an end
軟體是達到目標的手段
任何軟體工程師的主要工作是提供價值,但很少有軟體開發人員理解這一點,甚至更少有人將其內化。
譯補:軟體是達到目標的手段,而不是目標本身。目標是定向的,但手段要可隨時變通。
6. Sometimes you have to stop sharpening the saw, and just start cutting shit
有時你必須停止打磨鋸子,而是直接開始動手
有些人習慣直接跳進問題裡,然後開始寫程式;另一些人則習慣於研究再研究,然後在分析階段陷入癱瘓。請為自己設定期限,然後開始探索解決方案。當你開始解決問題時,你會很快學到更多,這會讓你迭代出更好的解決方案。
7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system
如果你沒有掌握各種可能,你就無法設計出好系統
趕上開發人員的流行生態是一項巨大的挑戰,但瞭解其中的可能性反而更為重要。如果你不瞭解特定生態系統中什麼是可能的、什麼是可用的,你會發現除了基本問題外,無法設計出合理的解決方案。總而言之,對那些很久沒有再寫程式的系統設計者要保持警惕。
8. Every system eventually sucks, get over it
每個系統最終都很糟糕,都會經歷的
Bjarne Stroustrup 有句名言:「只有兩種語言:被抱怨的語言和沒人用的語言」。這句話可以延伸到大型系統:沒有「正確的」架構。
你永遠無法償還所有的技術債、你永遠無法設計出完美的界面、你的測試總是太慢。但這不是一個不把事情做得更好的藉口,而是給你一個視角,不要擔心優雅和完美;相反地,努力持續改進,創造一個可接受的系統,讓你的團隊樂在工作中,可持續地提供價值。
9. Nobody asks “why” enough
沒有人問夠 “為什麼”
把握任何機會質疑 “事情總是一直這麼做” 的假設和方法。有新團隊成員要加入?注意他們在哪裡感到困惑,以及他們問了什麼問題。有無意義的新功能需求?確保你瞭解目標和驅動這個功能的渴望。如果你沒有得到一個明確的答案,繼續問為什麼,直到你明白為止。
10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers
我們應該更專注於避免 0.1x 的工程師而不是尋找 10x 的工程師
10 倍工程師是愚蠢神話。有人能在 1 天內完成另一個有能力、努力工作、有類似經驗的工程師在 2 週內完成的工作,這種想法很愚蠢。我見過工程師程式量是其他人的 10 倍,但你卻要以 10 倍的次數來修改它。一個人能夠成為 10 倍工程師的唯一方法,是你把他們和 0.1x 的工程師相比。要注意那些浪費時間、不尋求反饋意見、不測試自己程式、不考慮邊緣情況的人… 我們應該更關心如何讓 0.1 倍的工程師離開我們的團隊,而不是尋找神話中的 10 倍工程師。
11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
資深工程師和資淺工程師最大的區別之一,是他們對事物發展已成形的看法
沒有什麼比一個對自己的工具或如何建構軟體沒有意見的資深工程師更讓我擔心了。我寧願有人給我的意見是我不同意的,也不希望他們根本沒有想法。如果你正在使用你的工具,而你對它們不愛也不恨,那麼你需要去體驗更多。你需要探索其他程式語言、函式庫和範例程式。沒有什麼方法能比積極尋找別人如何使用與你不同工具及技術來完成任務能更快提升你的技術水平。
12. People don’t really want innovation
人們並不真的想要創新
人們經常討論創新,但通常尋找的都是廉價的勝利和新鮮之事物。如果你真的進行創新,並改變人們做事的方式,就會得到許多負面回饋。如果你相信你正在做的事情,並知道會實質改善,那麼請準備好迎接一場漫長的戰鬥。
13. Your data is the most important part of your system
你的資料是你系統中最重要的
許多系統在發生任何主要路徑之外的事時,都會產生部分或骯髒的資料。未來處理這些資料會成為一場噩夢。請記住,你的資料可能會比你的程式長壽。花點精力保持秩序和乾淨,從長遠來看會有很好的回報。
14. Look for technological sharks
尋找技術上的鯊魚
存活下來的老技術是鯊魚,不是恐龍。它們很好地解決了問題,即使在技術世界快速發生變化中也存活了下來。不要和這些技術打賭,只有在你有非常好的理由時才替換它們。這些工具非華而不實,也不會令人興奮,但它們會完成工作,不會有很多不眠之夜。
15. Don’t mistake humility for ignorance
不要把謙虛誤認為無知
很多軟體工程師,除非被要求,否則不會表達意見。千萬不要以為別人不在你面前發表意見,就認為他們沒有什麼可補充的。有時候,最吵的人是我們最不想聽的人。與你周圍的人交談,尋求他們的回饋和建議。
16. Software engineers should write regularly
軟體工程師應定期寫作
軟體工程師應該定期撰寫部落格、日記、文件,總之做任何需要他們保持書面溝通能力之事。寫作幫助你思考,並促進你與你的團隊和未來的自己更有效地溝通。
17. Keep your processes as lean as possible
盡可能地保持你的流程精簡
如今,每個人都想變得敏捷,但「敏捷」是指小步方式建構事物、學習,然後進行迭代。如果有人嘗試在其中塞進更多東西,那麼他們可能是搭售。這並不是說人們不需要責任或協助來工作,但你有多少次聽到你最喜歡的科技公司或大型開源產品的人吹噓他們的 Scrum 過程有多好?在你知道你需要更多之前,保持對流程的精實。相信你的團隊,他們會交付的。
18. Software engineers, like all humans, need to feel ownership
軟體工程師,和所有的人一樣,需要感受到自主
如果你把一個人從他們的工作成果中抽離,他們就會對他們的工作不那麼關心。這也是跨職能團隊運作良好的主要原因,也是 DevOps 變得如此流行的原因。從頭到尾擁有整個過程,並直接負責交付價值。讓一群充滿熱情的人對設計、建構和交付一個軟體 (或任何東西) 擁有完全的自主,這終將發生令人驚奇之事。
19. Interviews are almost worthless for telling how good of a team member someone will be
面試對於判斷一個人將成為多好的團隊成員幾乎毫無價值
面試最好是用來瞭解某人是誰,以及他們對某一專業領域的興趣如何。嘗試找出他們會成為多好的團隊成員是一個沒有結果的努力。相信我,一個人有多麼聰明或多有知識,也不是一個很好的指標能說明他們會成為一個很棒的團隊成員。沒有人會在面試時告訴你,他們從不可靠、濫用職權、華而不實,或者不按時參與會議。人們可能會聲稱他們在面試時能看出「 訊號」,但這些都是胡說八道。如果你使用這樣的訊號,你只是在猜測和拒絕好的候選人。
20. Always strive to build a smaller system
致力建構一個較小的系統
有很多力量會促使你在前期建構一個更大的系統,不管是預算分配、無法決定哪些功能應該被削減,或渴望提供一個系統的 「最佳版本」。你應該與此抗衡。你在建構一個系統的過程中會學到很多東西,你最終會迭代成一個比你當初設計的更好的系統。令人驚訝的是,這對大多數人來說是個難題。