Re: [請益] senior該是什麼樣子的?新人怎麼進階?
最近在onboarding兩個團隊新成員
也正好從Lead SE變成Engineering Manager
所以我想我可以提供兩種不一樣的視點
首先從Lead SE的觀點出發
我對junior的期望是可以獨立工作並且持續學習
- 被指派的tickets可以如期完成 (我們是用Scrum)
- 寫出來的code不是會動就好 必須是在給定範圍內的最佳解
Ex: 可以O(n)解決的東西請不要在PR裡面給大家看到O(n^2)
- 知道團隊內的工具使用方式與convention
- 知道怎麼問問題
問對問題的通常學習成長的很快
我對senior的期望包含以上所有加上
- 對整套系統有完整的了解
Ex: 當bug出現時第一時間就可以指出可能是哪裡出問題
- 能夠清楚的定義components間的關係與介面
並且知道自己寫出來的code是要給別人用的
(single responsibility, reusability, scalability, etc.)
- 有能力將UX design變成一包可deploy的containers
這裡不是要senior通包所有工作
而是senior需要知道整個大架構與流程
開發過程才不會顧此失彼
- 可以回答來自junior的問題
基本上我們會hire的人都有不錯的底子
但從我正在onboarding的兩個juniors身上觀察到的是
1) 容易想太多
Ex: 可以用變數的方式在兩個methods中傳遞的資訊
變成先寫進資料庫然後再讀出來用
(我同事問我為什麼review PR到拳頭都握起來了...)
多跟其他人討論不要悶著頭苦幹
2) 有問題不問
這個很糟糕
我知道有少數人很討厭別人問問題 但是大多數人是很樂意回答的
有疑問請不要用猜的 問就對了
所以說溝通能力真的很重要
接下來從Engineering Manager的觀點來說
不管是junior或senior 我的期望很簡單
拜託不要在sprint的倒數第二天跟我說
"ticket(s)沒辦法完成因為有blocker(s)"
其他都好談
=========
最後廣宣一下
https://www.plytic.com
這是我趁著聖誕節假期弄出來的系統
主要功能是找出PTT使用者的所有發文與推文記錄
希望在2020前可以讓整套系統變成熟幫助大家抓五毛 :p
技術部分是React + RoR + Postgres + docker-compose
歡迎各界批評指教
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 172.58.187.13
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1549735385.A.2EF.html
推
02/10 02:49,
5年前
, 1F
02/10 02:49, 1F
推
02/10 03:41,
5年前
, 2F
02/10 03:41, 2F
推
02/10 05:43,
5年前
, 3F
02/10 05:43, 3F
推
02/10 07:23,
5年前
, 4F
02/10 07:23, 4F
推
02/10 09:56,
5年前
, 5F
02/10 09:56, 5F
推
02/10 12:15,
5年前
, 6F
02/10 12:15, 6F
推
02/10 13:07,
5年前
, 7F
02/10 13:07, 7F
→
02/10 13:07,
5年前
, 8F
02/10 13:07, 8F
推
02/10 13:23,
5年前
, 9F
02/10 13:23, 9F
→
02/10 13:23,
5年前
, 10F
02/10 13:23, 10F
→
02/10 13:23,
5年前
, 11F
02/10 13:23, 11F
推
02/10 13:32,
5年前
, 12F
02/10 13:32, 12F
→
02/10 13:33,
5年前
, 13F
02/10 13:33, 13F
在這個資訊流通快速的時代
一個假期可以弄出來的東西實在不敢說有啥高技術含量 也絕不是呼弄大家
高手很多 但能變成大師的屈指可數 其他的都只能稱為工匠
最大的差異在於格局
工匠精進自己的技術 是為了追求華麗 彰顯自己的價值
大師精進自己的技術 是為了化繁為簡 為他人創造價值
當初會開始做Plytic是有感PTT上資訊太多
有時候難辨真假
於是想給大家提供一個簡單好用容易上手的工具
幫助大家做判斷時有所依據
整個開發過程花最多時間是在UX的部份
砍掉重練了三四次 (呼~~~)
要維持簡單真的很難
推
02/10 15:24,
5年前
, 14F
02/10 15:24, 14F
推
02/10 16:23,
5年前
, 15F
02/10 16:23, 15F
推
02/10 17:23,
5年前
, 16F
02/10 17:23, 16F
推
02/10 17:51,
5年前
, 17F
02/10 17:51, 17F
推
02/10 18:01,
5年前
, 18F
02/10 18:01, 18F
推
02/10 18:06,
5年前
, 19F
02/10 18:06, 19F
→
02/10 18:06,
5年前
, 20F
02/10 18:06, 20F
推
02/10 18:33,
5年前
, 21F
02/10 18:33, 21F
推
02/10 20:16,
5年前
, 22F
02/10 20:16, 22F
推
02/10 20:55,
5年前
, 23F
02/10 20:55, 23F
→
02/10 21:59,
5年前
, 24F
02/10 21:59, 24F
可以 而且我會很感激
我們一個ticket一般來說是兩天的工作量
所以倒數第四天說其實給我兩天的時間來排除blocker(s)
推
02/10 22:00,
5年前
, 25F
02/10 22:00, 25F
推
02/11 00:03,
5年前
, 26F
02/11 00:03, 26F
→
02/11 00:05,
5年前
, 27F
02/11 00:05, 27F
是的 用DB儲存資訊建立關係
難的地方在於怎麼用簡單明瞭的方式呈現資訊
※ 編輯: l7th (172.56.3.226), 02/11/2019 03:29:07
推
02/11 04:14,
5年前
, 28F
02/11 04:14, 28F
推
02/11 10:36,
5年前
, 29F
02/11 10:36, 29F
推
02/11 11:48,
5年前
, 30F
02/11 11:48, 30F
推
02/11 14:11,
5年前
, 31F
02/11 14:11, 31F
推
02/11 18:31,
5年前
, 32F
02/11 18:31, 32F
好主意 或許我可以開發API讓有興趣的人整合
推
02/11 19:54,
5年前
, 33F
02/11 19:54, 33F
推
02/12 09:12,
5年前
, 34F
02/12 09:12, 34F
推
02/12 15:01,
5年前
, 35F
02/12 15:01, 35F
目前看不太出來
現在隨時有十個users在使用
peak的時候有超過200 active users
這樣的流量處理起來完全沒問題
我是用現有的Intel i5 NUC + Verizon FiOS gigabit connection
所以沒有額外的支出
有時間我會把整個system architecture畫出來跟大家分享
※ 編輯: l7th (208.54.35.140), 02/13/2019 02:01:09
推
02/13 15:59,
5年前
, 36F
02/13 15:59, 36F
推
02/14 16:25,
5年前
, 37F
02/14 16:25, 37F
推
02/14 16:30,
5年前
, 38F
02/14 16:30, 38F
討論串 (同標題文章)
以下文章回應了本文:
完整討論串 (本文為第 5 之 6 篇):