株式会社PRUMでエンジニアをしている人見です。
日々、プログラミング学習や実務の中で
つまずきやすいポイントを整理して発信しています。
PRUMについて気になった方は、
コーポレートサイトもご覧ください。
▶ コーポレートサイト
--- 意識的差異讓你成為能幹的工程師!!【前篇】 ---
在開發現場,你是否聽過這句話?
「不好意思,發生錯誤了。」
在工程師的工作場合這句話非常常見。不過,聽到這句話時,有一點小小讓人在意的地方。
……那就是
這是「報告」嗎?還是「諮詢」呢?
經常會由這句話開始對話,接著前輩會去把狀況問出來,這類互動相當常見。
這次我會整理:
- 在說「發生錯誤了」之後實際發生的事
- 為什麼對話會有點繞遠路
- 只要稍微注意就能改變的傳達方式
把現場常見的互動稍微誇張化,會像下面這樣。
新人
「不好意思,發生錯誤了」
前輩
「在哪裡發生?」
新人
「在儲存處理的部分」
前輩
「錯誤訊息是?」
新人
「NullPointer(空指標)」
前輩
「哪一行?」
這段對話本身並沒有特別怪,只是仔細一看,是一種
前輩在把狀況問出來
的結構。
新人並不是做錯什麼。相反地,前輩或是領導通常都很親切,會說「那我們一起看看吧」來幫忙。但在那之前,常常會開始一段「為了整理狀況而進行的來回問答」。
例如會依序確認:
- 在哪個畫面?
- 做了什麼操作?
- 錯誤訊息是?
- 重現步驟是?
這樣的互動本身並不是壞事。但如果一開始就已經整理到一定程度,對話會短很多。
那麼,為什麼會出現只說「發生錯誤了」就讓對話卡住的情況呢?這裡有幾個可能的理由。
把工作中的對話當成是「傳達事實」的情況。
例如:
- 發生錯誤了
- 完成了
- 做不到
若只停在這裡,對方就無法知道「之後要怎麼處理」。
新人時期可能會考慮自己「要說什麼」,但未必會想到「對方之後要怎麼做」。這其實並不罕見,在教育心理學中接近所謂的「認知負荷(Cognitive Load)」的狀態。
新人需要同時處理很多事情,例如:
- 技術理解
- 錯誤理解
- 程式碼理解
因此很難有餘裕去從對方的視角思考。
【 認知負荷 】
人一次能處理的資訊量是有限的。
有些新進人員會想:
- 再多查一下再問比較好
- 這種事可以問嗎?
- 對方看起來很忙,改天再問吧
有這種顧忌的話,可能會說話說到一半就停下來,不把想說的說完。另外在心理學上有個現象叫做「鄧寇格—克魯格效應(Dunning–Kruger effect)」,意指初學者較難正確評估自己的理解程度。
因此會有「說不定再查一下就懂了」的想法,導致諮詢時機延後。
【 鄧寇格—克魯格效應 】
一般認為初學者較難準確判斷自己的理解程度。
就算在說「發生錯誤了」時,實際上可能是想表達以下其中一項:
- 想要別人幫忙(請協助)
- 想請人確認(請幫我確認)
- 只想知道方向(只要大方向即可)
但新人往往還沒有判斷「哪些資訊是重要的」的基準,因此會出現不清楚自己困在哪裡、不清楚想請對方做什麼,也就是無法把問題語言化的情況。
在軟體開發或學習的語境中,這也常用「心智模型(知識結構)」的差異來解釋。經驗較豐富的工程師會比較自然地整理出對方需要的資訊。
【 心智模型(知識結構) 】
隨著經驗累積,頭腦中的整理方式會改變的印象。
「發生錯誤了。」
從這一句話開始的對話,背後包含了:
・為什麼會出現來回問答
・為什麼資訊會不足
而這些多半並不是「因為是新人所以做不到」,而是因為思考的餘裕或經驗的差異而自然發生的現象。
正因為如此,當你覺得
「總覺得哪裡怪怪的」
「好像有點繞遠路」
能察覺到這種違和感,其實非常重要。能否發現這種違和感,會大幅影響之後的成長速度。
那麼,實際上要怎麼傳達才好呢?
・要整理到什麼程度才夠?
・要怎麼說才能變成「諮詢」?
・要怎麼做才能讓對方比較容易判斷?
我會聚焦在「領導或前輩真正想知道的資訊」,並進一步整理說明。
PRUM 的工程師有超過 95% 是從無經驗錄用起來的。歡迎有興趣的話到公司網站看看。
原文出處:https://qiita.com/hitomin_poke/items/417b4d6f416fb188a30c