ADZ 學習筆記

Ruby/Rails, Startup, Life

有效率學習一門技術的訣竅 - 當個容易被幫助的人

| Comments

昨天看了一篇關於 語言癌 的文章,還滿有趣的,這或許反映了現在網路越來越即時所造成的問題:「你只要打幾個字按下 Enter 對方就會馬上收到訊息,缺少思考的文字混雜著情緒、無用的資訊、和混亂的邏輯」。

10 幾年前的網路環境,沒有 Facebook、沒有 meetup、沒有完整的技術文件、沒有即時討論程式的地方,只有幾個寫程式的論壇網站,討論的人也相當分散,在那個時候上論壇問一個問題至少要等 4-8 小時甚至隔天才有人回覆,有時還會音訊全無。

在這樣的環境下,來回一次的溝通成本非常高,如果我沒有想盡辦法把問題一次描述清楚,我就要再等 4-8 小時才能再次得到別人的回覆,更別說抓不到重點的問題,可能花一個星期也得不到答案。

我很幸運我經歷過那個網路緩慢的年代,逼著我養成習慣在向別人請教問題前先打開記事本把問題歸納、釐清才送出。直到現在我依然花很多時間去描述我的問題、確保沒有缺少資訊、和清楚的問題核心。

如何問問題

1. 確保資訊完整

記得曾經有個人在 facebook 問 rails deploy 的問題,以下是模擬對話:

A: 問一下喔,我的 rails app 不能 deploy
我: ?
A: deploy 到一半出現錯誤
我: 什麼錯誤?
A: 就一個 exception 什麼的,你有遇過嗎?
我: 你要不要貼 error message 給我看一下
A: 可是我是照 XXX 的文章照做,結果跑到一半就一直出錯
....
....
....

像這樣缺少資訊的問法加上用聊天室的方式詢問,其實就是把自己和對方的時間綁住一起浪費掉,而且不會有任何進展。

如果你的問題包含很多資訊 程式碼錯誤訊息你的思考方向 等等,最好開先開份 evernote 在上面把資訊打完整。最後直接把 link 貼給對方,送出前記得把多餘的資訊、贅詞刪掉後再送出。這樣一來除了可以訓練自己的文字表達能力外,還能讓對方依照自己的時間被動處理、用自己的習慣來消化問題。

2. 尚未歸納的問題不是問題

如果依照 上一篇 的做法,會先有個基本的歸納,把問題拆成很多個小 part,問的問題相對明確好回答。而歸納過後的問題才算是真正的問題,不然其實只是想把責任丟給對方而已。像是有的人會直接問:「購物車怎麼做?」這個問題很模糊也非常多層面,是想了解概念? 還是流程? 還是 schema design? 還是實作哪個部分遇到困難? 每次遇到這種問題我都有種在 try 別人網站的感覺 ... oh 終於找到 injection 點了。

讓別人幫你歸納問題的壞處是,你只是吃到魚、釣竿還是別人的,但學會怎麼歸納後等於是發展出一個比釣竿更有效率的工具。

3. 描述自己的觀點

忘記在哪個地方看過一段話:「問對問題比回答更重要,但問對問題相對困難」這句話我非常認同,越簡單觀點,也會得到越簡單的解法,越複雜的觀點,得到的解法也越複雜。

在問問題中如果能提供更多資訊關於你的想法:為什麼這樣設計? 為什麼使用這個工具? 為什麼採用這個演算法等等、甚至是為什麼要問這個問題? 這些資訊有助於讓別人瞭解你的目的跟思考路徑。

「如果你問別人怎麼養牛,卻不透露你的目的只是要喝牛奶」別人是無法告訴你對「喝牛奶來說、如何養牛不算是個問題

4. 小技巧

使用工具

evernote 只拿來描述問題、搭配 gist 或其他服務外連程式碼、錯誤訊息、圖片等等。

多個問題時

同一個情境下如果有多個問題可以標註 Q1, Q2, Q3,這種描述方式會更明確、訊息往來也會有得對照。

把資訊分類

被請教的對象通常是較為 senior 的人,在了解事情通常會有自己的方式,絕對不會照單全收,而是藉由推理選擇性吸收資訊增加效率,所以最好可以提供 200 字內的摘要描述問題或情境、並分段落標題讓對方容易依照自己的習慣消化問題。

系列文章

  1. 有效率學習一門技術的訣竅 - 閱讀:練習 (1:9)
  2. 有效率學習一門技術的訣竅 - 讓需求引導學習
  3. 有效率學習一門技術的訣竅 - 避開學習障礙
  4. 有效率學習一門技術的訣竅 - 當個容易被幫助的人
  5. 有效率學習一門技術的訣竅 - 突破靠想像力

Comments

comments powered by Disqus