1. 程式人生 > 其它 >我帶的實習生,轉正了。

我帶的實習生,轉正了。

你好呀,我是歪歪。

我最近帶了一個實習生。其實說最近,也都整整三個月了,已經在走轉正流程了。

還記得他來的時候,為了和他套個近乎,有一天聊完正事之後,和他拉了拉家常。

然後我說:在我們組裡面,不必拘謹,大家在平時溝通的時候也沒有上下級的關係,敞開心扉,不要有太多顧慮。我們的氛圍是很 open 的,多多溝通。其實你別看我長的老,我年齡也不大,我 94 年的。對了,你哪一年的?

他答:2000年。

那一刻其實有衝擊到我。

因為我驚奇的發現,原來 00 後也慢慢的走入職場了。

他們從我們 90 後手中接下“垮掉的一代”的接力棒後,馬上就要順利的把接力棒交接給 10 後了。

歲月如梭啊!

反饋和思考

他加入團隊之後,遇到一個很好的契機是剛好那個時候接到一個新的需求,為了完成這個需求,我要從 0 開始搭建一個微服務。

我讓他從專案設計階段就參與了進來,最後跟到了專案上線。體驗到了一個專案上線的全流程。

對他而言,是一個契機。

對我而言,其實算是一個挑戰,因為這個專案的整體時間給的不算充裕,分配到開發環節那就是更加緊張了。為了保障進度,當時緊急從專案組裡面抽調了另外兩位同事和我一起專門幹這事,就這樣人力資源還是尤為緊張。任務進度需要按天為單位進行推進。

領導問我:這個實習生你想怎麼安排呢?

我說:讓他和我們一起開發這個專案吧,我來給他分配任務,彙報開發資源的時候算半個人力投入。

其實,我說“半個”人力的時候,自己心裡都在打鼓。因為他並不是通過我面試進來的,加入專案組大概一週多時間,我甚至都還沒見過他寫的程式碼,不知道他的技術能力在什麼水平。

但是從最終的結果上來看,其實他在專案裡的交出的成績單是遠大於半個人力的。

換句話說就是:整體表現是超出預期的。

舉個例子。

我給他拆分一個任務,講清楚需求背景之後,讓他去落地程式碼。

他寫著寫著會發現某個地方是需求沒有考慮到的細節問題。

於是他會很快的反饋給我,同時帶著自己的解決方案,問這樣去實現可不可以。

帶著解決方案的問題反饋。

聽起來是一個很簡單、再自然不過的事情,但是我發現在職場中越是新人做的越好。

而老油條們,包括我自己,其實很多時候都做的不夠好。會去拖、會去掩蓋、會覺得這其實也沒啥大毛病、會去自己找個想當然的方案就改了...

但是我覺得這個簡單的事情背後有好幾層邏輯。

第一層邏輯是:自己發現了問題。

能發現問題,至少說明你對自己寫的這段程式碼的背景有一定程度的瞭解。

只有在需求瞭解到位的基礎上,才能在落地環節自主的去發現問題。

這一層,一般來說大家都可以做到。

第二層邏輯是:發現了問題,到底反不反饋?

不反饋其實從責任劃分的角度,就算出了問題,主要責任不在我呀,當時提需求的時候就沒有考慮到這個問題。

反饋上去了,最後解決起來,增加的是我的工作量。

到這一層,有些同學就會經過激烈的思想鬥爭後決定:時間來不及了,先就這樣吧。不反饋了,不是啥大問題。

千里之堤毀於蟻穴呀。

在專案裡面小問題多了,是會出大問題的。

如果真的是很小的問題,哪怕你打個 TODO 在那裡標識一下呢?防止自己以後也遺忘了。

其實大多數情況下,這樣的問題在測試環節也能被揪出來。

但是如果自己能預判到,為什麼要延遲到測試環節才暴露出來呢?

或者說經過激烈的思想鬥爭後決定:這個地方我知道怎麼改,直接改了就行了,就不和別人商量了,懶得去反饋了。

這裡其實就是大忌,很容易埋坑的。

比如就是一個欄位你不知道從哪裡取值,需求上也沒有明說。但是你可以自己從某個地方取出來,也可以由上游傳遞過來。

於是你決定自己去取就行了,不麻煩上游了。

因為來源有兩處,哪怕在你寫程式碼的當時這兩處來源他們一定是強相等的,但是隨著系統的發展,也許會出現不一樣的情況,而當這樣的情況出現的時候,這裡就是坑。

也許到那個時候,你自己都忘記了,這個值是你去某個地方獲取的,而不是由上游傳遞下來的。

當這真的出現問題的時候,你一查程式碼:這是哪個 sb 寫的程式碼?為什麼不讓上游傳遞進來呢?

然後氣沖沖的一看歷史提交記錄,你就開始默不作聲了。

第三層邏輯是:反饋的時候帶著自己的解決方案。

在我看來,主動反饋是應該必須要做到的事情。

至於能不能帶著解決方案,難說。

因為有的時候由於自己對於全域性的把控不到位,確實是只能發現問題,不能解決問題。

所以,這一點對於新員工或者實習生來說不能強求,但是能做到那便是最好不過的事情了。

比如這個實習生,每次來找我反饋問題的時候,說完問題之後就會說自己想到的方案,問能不能這樣做。

其實很多時候他給的方案並不好,比如他想根據某個返回值去做處理,而我覺得更好的方案應該是基於資料的某個狀態去做,或者說加個資料庫欄位專門來幹這事。

這樣更加符合程式設計的邏輯。

他給的方案不是不能用,是有更好的。

但是,這裡面體現了他自己的進一步思考。

而從實際情況來看,他也提出了很多很好的實現方案,被我採納了。

能帶著解決方案,說明自己有更深一步的思考,挺好。

思考和反饋,不論是什麼階段,都很重要。

我自己有時候都做的不夠好,但是我會這樣常常提醒並要求自己。

再舉個例子

再舉個關於反饋的小例子:

我給他分配完任務後,告訴他什麼時候之前要做好。

在這期間,他會主動告訴我自己做到什麼進度了。如果自己在預期時間之前做不完,他會提前告訴我困難是什麼。

他這樣會讓我及時掌控到整個專案的進度,讓我提前預防風險。

我之前也帶過工作過幾年的同事,有時候任務進度滯後,都是由測試同學反饋上來的,會搞的我很被動。

當然我也應該偶爾去主動詢問進度。

但是在我的邏輯裡面:大多數情況下,你沒說,沒有找我協調,那麼我就認為專案是按照正常的進度在推進的。

我覺得任務如果有風險,提前幾天反饋,可是太重要的事情了,這應該是基本的職業素養。

至於怎麼去定義風險的低中高,從而拿出什麼樣的姿態去應對,那就是另外一項本事了。

同時在整個專案開發的過程中,其實我是不斷在給他施壓的,在有來有回的試探中,我也知道了他的能力還是不錯,有很強的執行力。

所以,在這個專案完成之後,緊接著的另外一個專案中,我給了他一坨關鍵節點上的開發任務,並告訴了他這個開發任務在整個呼叫鏈路上的關鍵意義。

從目前的開發進度上看,他完成的還是很不錯的。

老實說,最開始的時候我就是給他分配了一些“髒活累活”,因為這些事情必須有人做。

做為一個新人或者實習生,即使你有翻天的本領,在我不知道你能力到底如何的情況下,只能從這些簡單的活兒開始試探。

如果要說說不足之處的話,那就是他最終拿出來的程式碼,從功能上來說是可以用的。

但是從程式碼分層、程式碼規範、後續擴充套件、程式設計習慣上來說,還是有所欠缺。

這些問題我從最開始就給他提出來了。

從現在他提交的程式碼上看,有一定的進步,但是還有很大的提升空間。

現在他可能還處於刻意模仿的階段,也許理解不了為什麼程式碼最後的架子是這樣的,反正專案裡面就是這樣寫的。

由於他的程式碼我每次都會重點 review,其實每次 review 都會發現一些編碼結構上的問題。

比如他可能會把一個介面中的物件一路傳遞到 dao 層裡面去;比如他可能會在每次和資料庫互動的地方都寫一個新的 sql 去與之匹配,沒有考慮到複用性;比如他會把非常多的邏輯都放到同一個方法裡面...

我覺得對於剛剛走進工作崗位的學生來說,這是一個必然的過程,他們從自己的 Demo 級別的程式碼,轉變為寫實際工程級別的程式碼,勢必需要一個適應和磨礪的過程,這個事情不是一蹴而就的,就是在反覆的開發實踐中錘鍊出來的東西。

能意識到這個問題,並加以練習和克服,就是成長。

而我發現他刻意模仿,是看到了他也會用一個大的 try-catch 把整個程式碼塊包裹起來,而他早期提交的程式碼並不是這樣的。

我自己有時候偷懶,會用一個大的 try-catch 把整個程式碼塊包裹起來。其實這樣寫出來的程式碼好用,但是不優雅,也不推薦。

異常應該就在需要捕獲的地方捕獲就行,整個方法包裹起來,是一種取巧的方案,說明你對自己寫的程式碼的異常分析沒有絕對的到位,企圖用一種粗暴的方式來兜底。

這樣不好,不好。

所以發現這個問題後我也和他及時溝通了,同時也對自己提出了更高的要求。

在編碼上不能偷懶。不能把一些壞習慣傳遞下去。

所以我開始慢慢意識到,這不僅是一個帶新人的過程,還是一個嚴於律己的好機會。

哦,對了。

我去參加他的轉正答辯會的時候才知道,還有一個導師拉票的環節。

於是我在手機便籤裡面匆匆記錄了幾點:

傳遞

在我的職業生涯中,我遇到過的每一個團隊和每一個團隊裡面的“導師”,對我都非常的好,他們竭盡所能的把自己掌握的好的東西分享給我。

所以我也希望把這一份好的東西一直傳遞下去。

猶記得我當年實習的時候,前端傳進來一個欄位,要最終落到資料庫裡面去,中間涉及到好幾層之間的幾個物件的轉換,我硬是弄了好幾個鐘頭都沒有弄好。

帶我的同事坐在我的旁邊,音樂時不時的從他的耳機裡面傳出來。在當下那個焦急的情緒下,一絲絲的音樂都讓我覺得煩躁。

於是我給他說:能不能先把音樂關了?

他聽出了我的異樣,把音樂關了,然後說:是不是遇到什麼棘手的問題了?

最後還是他手把手教我怎麼解決這個問題。

後來有一次吃飯我給他說起了這個事:我說我覺得那個時候的自己好差勁啊,這麼簡單的事情搞了好幾個小時都沒搞定,最後還得你出馬。

他說:我並不覺得你差勁,而且我也不怕你差勁。我怕的是,你自己吭哧吭哧的搞,搞不定了還不問我。你不問我,我就不知道怎麼幫你。有些事情,是你能力範圍外的事情,你再怎麼使勁,也很難看到收益。有些事情,是你能力範圍內的事情,你應該會而不會的事情,那你應該去精進自己的技能。難的是你怎麼去清晰的識別出這些問題。比如你說的這事,你應該也知道,就是屬於你應該會而不會的事情,那麼你就應該去提升自己的相關技能。你也去做了,現在的你再次遇到那個問題,應該很快就解決了。這就是成長。

我帶過實習生,也帶過工作年限比我高的人。

這一行不像是一些老手藝,需要有人傳承,一代一代的教。

但是這個行業裡面有前人總結出來的一些好的東西,應該傳遞出去。

好了,就寫到這裡吧。