iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 3
0
自我挑戰組

轉職新手的自學筆記系列 第 3

第二步:學會善用資源與提問

繼昨天在第一步:選擇語言與學習歷程分享自己起步與至今累積的經驗
今日,我想進一步分享自己平常學習求助資源與技巧

目前常見三類資源:

  1. 請教可觸及的人:師長、資深工程師、同儕
  2. 社群平台:臉書社群、線上討論平台
  3. 技術文件:tutorial、開源者的分享

我也將逐一說明自己在尋求這些資源的注意事項與心得

伸手牌對自己學習有限,不如先學會找答案

工程師所培養的是自行解決問題的能力,在遇到困境時,試圖釐清問題與嘗試尋找答案,是一件很重要的事,也是長遠職涯中愈來愈重要的技能;加上現在網路上討論社群愈來愈活躍,像是我們現在撰文的IT邦。因此,有許多基礎問題,發問前建議自行探索。

可先行搜尋的問題:

  1. 拿關鍵字google就能找到答案:盡量用中英文描述自己的問題、加上關鍵字,去搜尋自己看得懂的內容
  2. 是因為自己撰寫不細心所造成的明顯錯誤,包含錯字、縮排、誤用功能:直接複製貼上error在搜尋欄位,總會找到一些類似的討論

我常使用資源與用法:

討論平台
1.stackoverflow:討論品質不錯,多少可找到類似提問
2.GeeksgorGeeks:有完整tutorial與範例
3.github:常有大神分享自己的做法,語碼跟筆記詳實

解題分享
leetcode & hackerrank等平台:

  1. 除了面試,當想磨練基本語法與思考邏輯時,這些平台由深入淺的題目都更有學習目標;尤其leetcode有非常豐富多元的題型,也支援幾乎所有語言的訓練。
  2. 個人覺得最寶貴的是:discussion
    可以選擇你想學習的語言,尋找速度快、效能高的寫法,運氣好的時候,會有非常貼心的人附上註解協助思考,不懂的時候再拿著這些關鍵字繼續google,可以飛快地訓練資料結構與演算法技能
    https://ithelp.ithome.com.tw/upload/images/20200918/20130707uWLVQbSb5s.png
  3. 還有一種我蠻喜歡的用法:用每一種語言寫一遍。
    若你跟我一樣,是個什麼都喜歡學的人,也想更深化語言特性的人,可以透過以不同語言解相同題目來提升敏銳度。概念大概就像你用英文、中文、日文、西文...跟大家問好、自我介紹...
    這些練習不但可以深化能力,最重要的是,可以更了解不同語言的強項,在解決問題時更為彈性。
    舉例來說,為什麼C++效能好?JS的閉包是什麼?什麼是強型別弱型別?物件導向語言特性在實現某些需求的優勢?
    因為這些刺激,都可以徹底最大化在leetcode刷題的效益,本身就是強大的學習網

喜愛的各種文件

為什麼上面說一堆網路資源,還是需要看文件呢?
當你查到互斥、不完整的資訊、需求太小眾時,官方文件成為最保險的判準
官方文件就像查找的字典,在過多雜亂資訊中,也能協助資深者精準找到解答

  • C#微軟的tutorial真的很優秀,還有自己錄影片與練習平台,靜態文件也簡單易懂,是我因為工作自學的重要管道
  • 機器學習TensorFlowPyTorch各有千秋,使用目的與比較網路上有更多行家分享,便不再贅述;sklearn支援許多模型,對其中使用細節與適用情境,都有很詳實說明
  • 網頁w3school對初學者有莫大幫助,而前後端非常複雜的用法、物件樣式等,難以全記在腦中,回來查詢文件也是一種最安全的做法(更別說前端規則常更新,需要確認最新動向)

適時提問的策略

情境

雖然上述有很多資源應該可以自行解答,但有很多情境下,仍然要停損找不到解答的窘境

  1. 耗費太多時間仍沒有好解法:適時求助仍然是一種好的解決方法
  2. 合作專案團隊或公司有一套寫法:除了確認公司文件,也要跟主管、資深員工確認

耗費太多時間仍沒有好解法

每個人習慣不同,我的方法也未必適用全部情境
但我的大原則包含:

  1. 時機:須觀察對方有餘裕。這不是廢話,突然打斷在專注思考自己問題的工程師,十分不禮貌,且對工作成效影響可能比大多數職位還高
  2. 需要呈現的資訊:先具體描述問題跟目的,目前的理解,希望對方的協助。

個人經驗:不要問開放式問題!不要問開放式問題!不要問開放式問題!(很重要一定要說三次
你不是在訪談,是在進行高效率的溝通與期望得到明確答案。頂多有兩三個選項讓對方瞭解,也要適時補充你自己認為的差異跟考量的點。
我平常跟senior提問大概5句左右,若是關於寫法,請一定要有code,不然沒有人聽得懂用口語文字描述的程式問題
尤其現在講求敏捷開發,每天要處理的issue很緊急,如果想深根這個領域,請訓練自己講話有重點跟邏輯(雖然這對每個領域應該幾乎都很重要

朋友可能相對比較不要求小細節,但有效率的溝通,對自己身為提問者幫助更大,也能增加對方願意幫忙的意願,仍然建議掌握上述兩大原則,做一個不白目而成熟的提問者

他人review你的code有疑惑

學校的專案可能大家都沒有很既定的規則,但各層級公司都會有自己的文化

並不是任何自己習慣的方式都能帶入職場
命名規則、是否加標點符號、縮排、註解方式等等這些學生們可能覺得很minor的事,類似在管顧報告中出現錯字、字體不一、忘了加頁碼,嚴重降低業主跟團隊對個人專業度的評價。

我自己的習慣是能當面討論,就當面討論
原因:

  1. 對方已經看不懂你的文字了,註解不可能冗長撰寫自己思路,很多贅述沒有意義
  2. 有時候雙方需要討論出一個共識,公司習慣性的東西需要核對

大原則:

  1. 先調整自己的心態:大家都是為了讓協作更順利,與協助彼此成長,不是有人惡意找碴(大家這麼忙誰想浪費時間刁難
  2. 可理解且有修改必要者先調整:前提是真的理解對方想法,像是很明顯的邏輯錯誤與壞習慣,不足以特別討論
  3. 整理自己撰寫時想法與釐清問題:這個討論本身應該聚焦,若是因為習慣與邏輯不同,需要先梳理自己脈絡,才能協助對方幫助自己

總結:

  1. 善用線上資源,自己先找答案訓練解決問題能力
  2. 提問要精準且高效率,協助自己找到答案
  3. 團隊溝通本重要,若是自己的code須梳理想法,加速彼此溝通

背景介紹
曾經以為自己會成為一名臨床心理師,但過動地先走組織策略,也經手UIUX專案,醫院走一遭後,接受扎實管理顧問訓練,並從數據行銷中感受自己對 data-driven 與 big data 的熱忱,便一路愈來愈 hardcore,大量暴露於產品開發的各種技能,期待未來整合所長,在資訊產業中,有策略的創新足以兼顧企業與使用者價值之產品。


上一篇
第一步:選擇語言與學習歷程
下一篇
淺談 QA Engineer 工作內容
系列文
轉職新手的自學筆記4

尚未有邦友留言

立即登入留言