Ryan Brush

「大師」的迷思#

任何在軟體業待得夠久的人，都聽過這樣的問題：

我遇到了例外 XYZ，你知道是什麼問題嗎？

提問者通常懶得附上 stack trace、錯誤日誌，或任何導致問題的上下文。他們似乎認為你處於另一個層次，能在沒有證據的情況下憑空給出解答。他們認為你是大師（guru）。

軟體社群中的「魔法」期待#

我們預期不熟悉軟體的人會有這樣的問題——對他們來說，系統看起來幾乎是魔法般的存在。但令人擔憂的是，軟體社群內部也看到同樣的現象。

在程式設計中也會出現類似的問題，例如「我在做庫存管理系統，該用 optimistic locking 嗎？」諷刺的是，提問者本人往往比問題的接收者更有能力回答——他們了解上下文、知道需求、讀過不同策略的優缺點。然而他們卻期望你在沒有上下文的情況下給出明智的答案。他們期望的是魔法。

大師只是持續學習的人#

是時候打破這個迷思了。所謂的「大師」也是人，他們用邏輯和系統性分析來解決問題，依靠心智捷徑和直覺。想想你見過最厲害的程式設計師——在某個時間點，那個人對軟體的了解比你現在還少。如果有人看起來像大師，那是因為他們花了數年時間持續學習和精進思考過程。

「大師」只不過是一個聰明且擁有**不懈好奇心（relentless curiosity）**的人。

打破迷思的好處#

• 與比你聰明的人合作時，提供足夠的上下文讓對方能有效發揮能力
• 移除大師迷思，也意味著移除一個感知上的進步障礙——你面對的不是一道魔法屏障，而是一個可以持續進步的連續光譜

不要助長迷思#

軟體界最大的障礙之一，是聰明人故意助長大師迷思——出於自負，或為了提高自己在客戶或雇主眼中的價值。這種態度反而讓聰明人變得不那麼有價值，因為他們不願意幫助同儕成長。我們不需要大師，我們需要願意培養其他專家的專家。