我常常覺得,軟體工程師可能是最能體現「當你手裡只有鎚子,看什麼都會像釘子」的一群人😂

我們在工作中,有時會陷入一種被稱為「路徑依賴」的困境。本文將探討「路徑依賴」在軟體工程師的工作與職涯發展中,所造成的各種影響和受困者會有的具體表現。

或許會讓你感到有點熟悉。

前言:何謂路徑依賴?

路徑依賴」是個社會科學的概念,用來描述一種現象,即一旦人們在某一方面選擇了特定的路徑或方式,他們就可能變得過度依賴這條路徑,並且可能難以改變。

這種依賴性可能源於各種因素,包括習慣、成本、學習曲線等,並可能在多個層面上產生影響,包括個人的行為、團隊的運作,甚至是整個社會的結構和制度。

在這裡,我們將專注於討論「軟體工程師常見的路徑依賴」。以下的內容主要是基於我個人在工作上的觀察,可能會帶有一點偏見,但絕大部分都是基於事實。

何謂軟體工程師的路徑依賴?

文章標題與開頭把「路徑依賴」稱為一種「困境」,這樣的說法可能有失公允

事實上,在大部分情況下,遵循既定的路徑可以顯著提高效率、增加確定性,同時也是我們發展專業的基礎。

所以嚴格來說,本文要討論的,是軟體工程師在工作與職涯中,那些「造成不良影響」的路徑依賴。

這類依賴帶來了一系列問題,例如低效率產出、溝通不順暢,甚至限制了我們的視野。因此,對於軟體工程師來說,了解這些路徑依賴的存在,確實有其必要。

接下來,我將從我自己以及我曾接觸和共事過的軟體工程師身上,舉出四個常見的路徑依賴觀察實例。

而且它們會是「層層遞進」的關係,從底層的工作細節,到上層的個人職涯選擇,我們無不受到「軟體工程師」這個角色的影響(或說「限制」)。

不過礙於篇幅,我們這期只先講前兩個


一、程式註解的路徑依賴

首先,讓我們以「程式註解」為例,看看軟體工程師在為程式碼寫註解時,如何表現出「不良的路徑依賴」。

所謂的「程式註解」,指的是在程式碼中以特定格式或符號添加的文字或說明,用於解釋程式碼的功能、邏輯或用途。

程式註解是為了提供給開發人員或其他讀者(通常是一起開發的工程師)更容易理解和閱讀本段程式碼的附加資訊。它們不會影響程式的執行,但對於增進開發上的溝通與協作效率,有著重要地位,尤其是程式中特別複雜的部分。

註解通常使用自然語言(例如英文、中文)撰寫,而且要力求好讀、好理解

「程式晶晶體」註解

晶晶體是一種流行於臺灣以中文為基底,夾雜英語不成句的單字或片語的表達方式。

某些人在撰寫註解時,容易過度依賴程式碼的「實作細節」表達(比如用 excutemany 大量插入資料至 User Table以 bulk_create 批次建立 obj),而非使用簡潔清晰的自然語言(比如將用戶資料存入資料庫一次性建立大量用戶資料)。

在中文夾雜大量的程式碼片語,堪稱「程式晶晶體」,語意不清、主詞不明,常常讓人無法一望即知。

其實也有完全用自然語言書寫的註解,但你讀起來並不覺得那是「通順」的句子,比較像 10 歲小學生寫的作文。

為什麼會這樣?因為開發者普遍「比較擅長」寫程式,而非文字表達。所以乾脆用寫程式的思路來寫註解——毫無疑問,這樣真的比較輕鬆。

這種在思考與陳述上,嚴重依賴程式碼邏輯的敘事方式,常常導致註解難以理解、重複程式碼的內容(即冗餘的註解),甚至可能產生混淆

從他人角度自我審視:為什麼作者都需要好的編輯?

你可能會認為:「只要提醒對方注意一下,問題就解決了吧?自己的文字是否易懂,應該很容易看得出來吧!」可惜,事實往往不是如此。

對於開發程式的「當事人」而言,即使註解中夾雜了大量不必要的程式細節,自己也常常會深陷其中,難以察覺,甚至覺得看起來很合理!——這就是為什麼作者都需要好的編輯,因為自身的盲點是很難完全發現並避免的

少部分工程師甚至會覺得「我的程式能跑且執行結果正確」就算稱職了。至於註解有沒有寫、寫得好不好,不能算是評價我工作品質的範圍與指標。

這想法不能說毫無道理,只不過,寫程式若只顧自己,終究難登大雅之堂。這些程式碼看起來就像是一個人的自言自語(只要自己有完成任務就好)——它並沒有在溝通

註解只是冰山一角

本段以「程式註解」為例,試圖說明工程師在「撰寫易讀程式碼」的路上常見的路徑依賴(可以說是一種協作上的「阻礙」)。

然而,這種「缺乏溝通意識」所帶來的影響,不僅存在於註解中,也往往貫穿整個程式寫作過程

這種心態的影響實際上遠遠超越了程式碼的範疇,接下來,我們將繼續探討這種心態在「工作表達方式」上所展現的路徑依賴特徵。

二、工作表達方式上的路徑依賴

看完第一個路徑依賴,我想你已經能猜到,這第二個會是什麼模樣了。

很多軟體 PM 在會議中常常會覺得,聽不太懂工程師在說些什麼。而我想說的是,你的感覺是對的!其實我也聽不懂。

既然寫註解、docstring 這種應該要用「簡潔清晰的自然語言」表達的場合,都容易藉由程式邏輯與實作細節含混帶過。那麼軟體工程師在會議中的表達,自然也會受到此「慣性」影響。

以我個人的經驗,工程師在描述自己工作上的要解決的問題、解決方式、可能的方向、已完成的任務等等,非常容易陷入類似的路徑依賴。

其結果就跟前面提到的程式註解一樣,你不會覺得對方是在講「人話」,而像是一種對技術方案、程式邏輯的「輪廓描述」。

至於所要解決的問題、背後的痛點究竟是什麼?選擇的依據為何?常常會直接予以忽略——因為他們滿腦子都是技術思維。

導致重點還沒說清楚,相關細節卻講了一堆,本末倒置。

請說人話

前面提到,不好的程式註解,就像一個人的自言自語。而這樣的表達方式,又何嘗不是如此?導致我們常常需要提醒對方「等等!我想要先知道的是……」

不過平心而論,良好的溝通、表達,對任何人都不容易,都需要一定的練習。

換句話說,要把一件事情講好,絕對需要先構思、自我反芻、察覺他人容易產生的疑問,並且以他人的角度去思考,才能真正做到「說人話」。

只不過軟體工程師基於職業上的特性,在感到表達困難的當下,容易反射性地躲回自己熟悉的技術與專業領域,以求得一定的自適與安全感。

這無疑會讓沒有技術背景的人,感到困惑和隔閡。


小結:讀者意識的欠缺

講完前兩項,本篇要收尾了,我們作個小結。

前兩個路徑依賴凸顯的都是當事人對於「他人很可能會不理解」這個意識的強烈欠缺,以至於常常用一種旁人看來近乎「自言自語」的方式在表達自我。

如果是一個作者,那就是「讀者意識不足」——寫出來的文章只有自己看得懂

所謂的「讀者意識」,指的是作者在寫作時預見到讀者的理解困難,並通過語言表達和組織結構來幫助讀者,使讀者更容易理解的能力。

我很想說「本文只是指出少數軟體工程師在工作上……」,但你我都知道(這裡的「你我」指的是工程師群體),說「少」恐怕是騙人的。

讀者意識的欠缺」在軟體工程師中確實是一個普遍存在的問題。有時候,我們可能過於專注於自己的程式碼和技術細節,而忽略了將這些複雜的概念和思維以易於理解的方式傳達給他人。

我也不敢說自己已經完全擺脫了上述的困境,在「讓自己與自己的工作產出容易被他人理解」這個面向上,我們還可以不斷努力,一直努力。