最近正在製作一些工具加速自己開發網站的速度,能夠製作各種工具輔助自己工作是我還沒成為資深工程師之前一直相信的資深工程師條件之一。
製作工具的概念並不是一定要發布或者公開某些套件才算,針對整個專案製作、選用適合的方案跟工具基本上是身為資深工程師的重要能力之一,
在研討會中害羞的工程師這篇文章中提到了我去參加演討會,上午在演講結束後聽 Ruddy 老師分享 DX(Developer Experience,開發者體驗)時提到,要讓剛加入團隊的工程師快速上手,就是要讓這些資深的人員去探索、鋪路,讓其他人能夠快速地開始工作。
最近我就將工作幾年來的 DevOps 相關經驗,整理成了
GitLab CI 樣板以及每次將 Ruby 或者 Ruby on Rails 專案進行容器化會使用到的進入點(Entrypoint)製作成 RubyGem -
Openbox 來幫助自己在未來的工作更快速,這兩者在每次創立新專案的時候都會需要花上幾小時的時間設定(即使已經標準化),有了這兩套工具時間可以節省到幾分鐘就完成最初的配置。
如同在軟體工程師業界有著十倍速工程師這樣名詞用來形容那些工作效率極佳的工程師,聽起來就是需要非常有天份才有機會成為這樣的人,然而在我自身的經驗中,很多時候就是累積的差異。
過去幾年我很常告訴同事,很多時候並不是我做東西很快,而是我的電腦裡面有著近百個專案的目錄,除了工作上的之外還有各種我自己嘗試的小專案。同時,我也能記得大部分專案的用途跟實驗目的,因此當我遇到某種類型難題的時候我很快就有可以參考的程式碼,接下來只要根據實際的需求調整就能夠快速製作出對應的成品。
製作工具的過程也是這樣,先從大量的實驗開始去驗證想法跟實現的方式,同時再多次的實際應用中觀察規律並且加以熟練運用,最後彙整規則後製作成具備一定彈性(高度抽象化)可以對應特定情況的工具。
基於同樣的規則,我們也可以看出工程師的成長正好也是初期需要大量練習熟悉程式語言和套件,並且在這個過程中累積能夠歸納過去經驗的技巧來選擇適合解決問題的方案,最後到了資深的階段則是能夠基於經驗從抽象的角度去看設計出來的系統,讓系統具備維護和擴充的彈性。
當然,製作工具也不是那麼容易的一件事情,同樣還是需要經過大量的練習。在文章開頭提到 Ruddy 老師分享的經驗中,關於回饋的部分點醒了我一個很重要的觀念,假設這些資深工程師製作了工具,然而卻沒有人能夠很好使用,那麼並不具備意義,因此除了製作工具之外,還需要汲取意見不斷改善,才能夠變成一個好的工具。
這幾年因為職位比較高,所以也會有同事問我「資深工程師」到底需要具備怎樣的條件,然而我依舊很難回答他們。因為很多時候,技術再好也很難成為資深工程師,這些資深的工程師想的總是遠比我們認為的還多、還深,也因此能夠被稱為資深工程師,這大概也是為什麼有些人很快就能夠走在這條路上,有些人卻一直過不了這道門檻的關係。