※ 引述《school5566 (千年大嫌者)》之銘言： : 小弟入行不久還算新手 : 請問各位平常如果遇到問題 : 就是專案做到卡住啦 一般那些問題可以問同事主管? : 因為我常常遇到卡住去問直屬主管 : (不是我故意問他 是經理說可以來問他的) : 結果每次都不管我 還會念說工程師自己要解決問題啊 : 不要一個口令一個動作啊 這個東西不該問啊 : 可是新人孤立無援真的很辛苦 : 請問一般什麼問題是可以問的? : 好比說框架官方文件看不懂 或是一個函式看不懂怎麼用? : 前人的程式碼看不懂 bug解不掉 或是根本不知道專案怎麼做下去之類的? : 可是他剛進公司卻又跟我說卡住就趕快問不要拖 浪費時間之類的 : 結果問他又不理我... : 什麼可以問什麼不能問啊?還是其實都可以只是單純就被主管搞而已? 我以前在學校修課時，覺得要竭盡所能自己解決問題，等到真的確定自己解決不了的問題，才去詢問同學或老師。結果往往是我自己長時間解決問題的過程中，就徹底失去信心，而課程進度往前飆，也不再有心去回頭發問。於是問題就愈積愈多擺在那邊，沒解。 所以問題應該還是要問的。但應該怎麼問？什麼時候問？ 出了社會就決定轉行的第一份工作，有個前輩帶我，有問題我會盡快發問，而他也會在每次 code review 時教我更好的寫法。那時候我還不會用版本控制，也常常分不清 delegate 模式的主客體。但回想那一個月後我成長的幅度，遠勝過進公司前的三個月自學。 過了那一個月後，前輩就說自己很忙，也幾乎不再 code review，從此只關心我的時程進度，很少過問實作細節。所幸已打下基礎，那之後我就能自學與獨立工作。 所以對新手來說，能有人解答問題，是離開新手村最快的方法。 後來前輩外派他國之後，我變成是小組內最資深成員，後續進來幾位新人後，我決定以身作則，發起一種允許可以隨時問問題的文化 —— 但若被問者正在忙碌，會鼓勵他直接表示「正在忙」，而發問者可以決定，要自己繼續嘗試解決或詢問別人。我發現除了分享經驗與討論解法之外，也經常發生的現象是，被問者忙完回頭關心發問者，發現他已經自己解決問題了；或是發問者還在闡述問題時，就自己想到解法了（而被問者可能都還沒聽懂問題）。 「應該怎麼問問題」其實是一種團隊文化，又因個人而異，很難有客觀標準。發問的品質當然有技巧有方法，這點在素昧平生的網路上特別受到重視，但其實依據不同社群又有不同的發問文化，而在公司裡這種面對面的團隊合作模式，其實很適合鼓勵直接互動、減少溝通摩擦。但這當然又因不同公司組織文化而異。 但更重要的是，你需要理解問問題只是「解決問題」的一種手段，公司真正在意的只有解決問題，而不要執著在鑽研什麼能問、什麼不能問。如果接手了某功能要改很趕的功能，那你可以考慮提議轉給當初實作的前輩做，開發效率可更快，自己再主動接其他不難或不趕的功能，或是你可以請求該前輩簡單解釋交接，又或是自己靜下心來花上一天，好好把程式碼讀懂。 有太多種可能的解法，在不同團隊不同時機點，適用狀況都很難說，我覺得唯一準則是你感覺自身的學習有沒有在「前進」。假若主管老是罵你不會自己解決問題，你可能很不服氣而開始戮力自學成才，這也是一種好事；若主管極度包容你，經常幫你解決問題，以致你誤以為自己適合個人主義盛行的資訊業，那也很可能是壞事。 -- 我最近寫了一個叫作「工作咖啡館」的 iOS App https://goo.gl/iBWJSs 我朋友拖拖拉拉也生出了 Android 版叫作「CaffeeTrip」 https://goo.gl/HnUQWQ --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 219.85.42.133 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1495548087.A.38C.html