Photo by Juan Rojas on Unsplash

安安大家好!!千呼萬喚始出來(其實只有我自己在喚),終於有時間寫下這系列最後一篇文章了 ,距離上一篇都快要一個月了哈哈!😂。

不免其俗地,這邊先附上前兩篇的連結:

這篇主要會分享一下當主管到現在的一些感受,以及這幾年瘋狂寫程式下來的一些心得。

比如說「我個人認為要進步的話,應該要保有什麼心態」、「個人開發以及團隊開發的差異」,然後也想順便分享一下面試的心得。

還有體重的變化。

先從剛到台北的時候說起吧,上一篇文章最後有提到要來台北帶團隊,想當然,第一步就是要先建立團隊了。

這裡順便提一下,由於當時我也是管理初心者(就是剛進入遊戲,一出村莊就會不小心被咬死那種),因此一開始我們是雙主管制度的,就是有兩個主管的意思,避免一個人太累。

那剛開始,最讓我不安的,我想就是面試了。

很奇怪吧?我明明是面試官,是有什麼好害怕的?

因為沒有什麼經驗,害怕的不外乎就是:「我應該要問什麼?」、「會不會面到一半無話可說?」、「怎麼決定要不要錄取?」,而且實際上,也真的有幾次面試面到一半腦袋一片空白,場面就這樣乾了一陣子。

經過幾次經驗之後,我冷靜下來,並且像一休和尚一樣在頭上畫圈圈,畫了三圈之後頭頂冒出一顆燈泡然後大喊:「我知道了!『其實我只要知道我想要什麼樣的團隊,並且朝這個方向去面試就好了』」。

於是我開始思考並且得出了幾個找人的方向:

  1. 以能力為主,個性態度什麼的普普就好了,只要不要寫 code 寫到一半會站起來大叫都還可以接受。
  2. 以個性態度為主,能力只要不要到完全不懂,並且願意努力學習,也可以配合公司工作就好。
  3. 能力好態度佳,什麼都好。
  4. 長得漂亮的女生。

第四點是開玩笑的不要當真。

然後找的人也會影響團隊的樣子,我個人分類的話大概有以下幾種團隊樣貌:

1.【競爭類型的】:個人績效至上,用績效督促每個人成長。

  • 優點:每個人會對自己做的東西很要求,
  • 缺點:不會亂寫 code,缺點是團隊合作意識可能沒這麼好,因為我如果幫助你可能會導致我績效下降,而你績效上升了。

這種類型的我覺得就是以能力為主,反正大家感情也不會說到太好,少一點勾心鬥角就很好了。

2.【團隊合作型的】:不以個人績效為主,大家互相幫忙才是最好的。

  • 優點:大家感情會很好,互相幫忙,氣氛也比較歡樂。
  • 缺點:對自己的程式碼要求會比較低,覺得會有人幫自己擦屁股,個人成長會比較慢,我要花很多時間擦屁股。

這個找人的方向就是以個性態度為主,要找那種好相處的,年紀也是考量之一,大家的年紀最好不要差太多(10歲以上),而且至少有一個女生,女生我覺得是團隊重要的潤滑劑(我是用很嚴肅的態度講的喔!)。

總而言之,考量種種因素之後,我還是希望有一個氣氛不錯的團隊,大家感情都不錯可以互相幫忙這樣,只要有基礎,其他的進來再磨練,因此我選擇了第二種

事實上這個方向也比較好成立,因為要在新創公司找到那種有衝勁、以團體為重的,要馬是新鮮人、不然就是剛轉職的新手工程師,而且現在剛轉職要當前端工程師的人,不是我要說,真的是好多啊!!選擇多自然就比較好找了。

看履歷

既然要找人就免不了要看履歷表了,自從自己開始看履歷以後,才真正能體會到以前老師或是哪個公務機關輔導就業的人員一直說的:「履歷一定要把重點放前面,或是用粗體字不同顏色的字」。

為什麼這麼說呢?一開始看履歷的時候覺得新鮮,每一句都會好好看完,但是看到後面(尤其是我在忙的時候),打開信箱有幾十封履歷,根本沒時間全部看完,更別說很多開頭都是:「我家有誰有誰有誰...」。

說真的有的寫了一大篇又沒分段的,看也只有看下面的經歷跟作品而已,然後沒作品的就幾乎都沒看了,因為面試到現在,那些技能寫一大堆的很多也不是真的懂,只要有摸個兩三下就寫上去了,也不太準,看作品或是經歷還比較有參考價值。

不過以上只是我個人的心得,可能其他人不是這樣,所以大家可以參考參考就好了。

基本上以這個方面去找人,也算是有一個不大不小的團隊了,中間過程就不贅述,基本上現在團隊人數不加我是:8個人。

學習方面

既然找的人能力方面都是以有基礎就好,自然就需要訓練了,這裡說說我觀察下來的一些結果。

以我個人方面的話,我是準備滿多新人文件的,進來就是先把文件都看過,文件包括了:「如何建構環境、Git 規範、前端規範、Vue 規範(我們寫 Vue)之類的等等」,還在持續新增中。然後有問題也都可以問我,我也會花滿多時間去教的(如果我會的話XD),我個人認為我是花滿多時間在教人的。

但是,我本來以為只要我盡力教大家能力就會上來,後來我發現很多事情不是我想像的這麼簡單。

除了我覺得我自己實在太累,我還發現有以下幾個我沒有考慮到的點:

  1. 很多人教了之後,他下次換個功能就不會了。
  2. 有人可以教的時候,就會產生依賴,覺得有問題就可以問,自己在開發功能的時候一開始都沒規劃好,遇到事情再問就好。
  3. 寫 code 參考別人的,我覺得很正常,但很多人真的就只是複製過來貼上,沒有思考過,下次輪到自己重頭寫的時候就不知道怎麼開始了。
  4. 團隊合作氣氛雖然好,但對自己寫的東西責任感很低,感覺寫錯了有別人可以擦屁股。

後來我得出了一個結論,最能使人成長的不是別的,就是「壓力」。

這個壓力指的就是:「我如果沒做好這個的話,會怎樣怎樣...」,或者是:「這個功能我應該要多久以內完成,超過的話我會覺得自己能力不夠」。

如果不給自己一點壓力或目標,盲目地在寫程式的話,我個人觀察進步的幅度總是不太理想。

不過我覺得有的人應該是知道這一點,只是沒去執行,就像我們都知道想哭的時候只要倒立眼淚就不會流下來,但想哭的時候也不會真的去倒立(我是沒看過,如果有人認識做過這件事的人的話麻煩介紹給我認識,想當朋友)。

而我個人在管理上也沒做好這點,我覺得我比較心軟一點,給的壓力比較小,這個我自己也還在鞭策自己成長中。

多人開發方面

以前端來說.我自己經歷過幾種開發團隊的規模:1人、2人、3人到現在8人。

團隊規範

我個人覺得團隊開發最重要的一點就是 Coding Style 了,如果一個團隊沒有做好規範的話那真的是很可怕的事情,這也是為什麼我要寫一堆文件的原因,我個人是就算一個人開發也會把該加的規範加上去,參與多人開發的時候也比較習慣。

分工方面

我覺得分工也是一大難題,以前在開發通常都是頁面為主,比如說:「你做首頁,我做登入」,但有時候會遇到一個問題就是這次開發的就只有四頁,要怎麼讓八個人去分?

所以後來就把維度縮小,很多功能以組件去分,之後再組起來,也比較不容易有衝突。

技術迭代

一個人開發的時候,只要自己負擔得了,想用什麼技術就用什麼技術,但在多人團隊就不一樣了,不是你想寫什麼就可以寫什麼的。

我個人的準則是想導入的人要學會一定程度以上的知識,而且要說服大家為什麼要用這個,然後教導大家至少能夠基礎實作,不要拖到專案進度就可以。

這裡很重點是說要會一定程度的原因是,你不能說:「我這次新專案想用 Xstate,但我不太會,想在新專案練習看看」,如果連你自己都不太會了,為什麼大家要配合你,如果因為用了這個新技術然後進度開天窗怎麼辦?

所以正常想用一些新技術應該是在自己的 side project 練習完之後才提出來。

啊忘了說,後來得力同事回南部,主管剩下我一個人了,真的是滿累的XD

以上大概就是我當主管的一些小小心得了。

總結

雖然這幾年瘋狂在寫程式很累,但我覺得滿值得的,因為我從一個害怕會不會找不到工作的人,變成一個可以安穩過生活的人,也不會再讓家人擔心了,而且寫程式也滿有趣的啦!

只是我覺得非本科系必須多花時間去補足基本的知識,比如說我可能會花一些時間去理解像是:OSI 模型、什麼是 TCP/UDP、揮發記憶體跟非揮發記憶體之類的等等,但其實年紀漸漸大了有變得比較愛讀書,所以去學習這些對我也不算是什麼困擾就是了(當工程師之後身體年齡來到50歲)。

總之我覺得轉職工程師在現在是真的滿不錯的,但我覺得想轉職的人不要把這個行業想得太簡單,好像覺得反正我只要上了課就能找到高薪工作,老實說這個行業其實滿難的,以我現在在做的前端,技術更新實在是太快了,如果不時時刻刻跟上的話很快就被淘汰了,雖然我打文章感覺輕描淡寫的,但我也是經歷過無數個痛苦的夜晚 QQ。

以上只是一個菜鳥小主管的心得,如果有人有更好的意見或想法也歡迎提供給我跟我討論喔!!

啊忘了說最重要的,體重一定要注意一下,不要因為壓力大就一直吃。

60 Kg→ 75Kg的男人上。

--

--