Re: [討論] 系統越開發越多,負責的東西越來越多
合理啊,進來這麼久了
對於程式碼和領域的掌握度,一定比幾年前的自己好上許多吧
一樣的工作量以前要做兩個禮拜,現在可能三天就做完了
當然要能做更多的事情
不然公司為什麼要給你更多薪水?
聽起來你待的公司應該是做自有產品,不是做一次性外包案
一個repo動輒要維護三五年以上,有很多技術債正常
沒人用的code才會沒有技術債
如果你待夠久,同期可能也都走得差不多了
陳年舊code的坑,搞不好八成是你留下的
要說誰有能力讓東西變更好,除了你也沒別人了
如果覺得太多事情只有你能完成,其他人都幫不上忙
那代表團隊的知識傳承根本沒做好
新人覺得環境很糞,做起來沒成就感
陣亡率也高
再補人進來只是惡性循環
找人的時間成本八成也是落到你身上,花你的時間去面試跟訓練
平常該寫的文件就寫
能分享的知識就分享
該丟出去的事情就丟
短期解決不了的神奇邏輯,補個註解跟文件連結
不要讓自以為聰明的新人改掉,最後爆炸還是你來修
解issue開個線上meeting讓其他成員一起看你怎麼找問題解問題
這些都做好,賺了credit又讓其他成員能分擔你工作
公司正常營運下本來就會一直有新功能進來
只有賺不了錢的公司才會在那邊一直refactor
很多工程師都抱怨老闆只管賺錢,整天丟隕石不管code quality
問題是身為資深成員的你,可否提出數據說明工程宅們整天在吵的code quality到底跟業務的關係在哪
是不是做同樣規模的feature要花的時間越來越多
是不是release後常常出問題要修
是不是客人抱怨的頻率越來越高
是不是工程部門離職率越來越高
數據拿出來,我不信老闆或PM不關心
大家都知道legacy很屎
但你有沒有能力提出一套可執行、可分工、可控制影響範圍、可以切milestone逐步進行的改進計畫
這才是資深成員的真正價值
小朋友工程師才會整天吵clean code,整天說要把舊系統打掉重來
年資越深越不能只專注在寫自己的code
不然領導層對你期望越來越大,你卻還用新人的心態自己蠻幹,會越做越累也是必然的
--
推
你這回文很像在教訓我,大可不必
這程度的回覆都聽不下去,那也沒什麼能說的了
推認真 蠻有道理的
完全同意 講的很對
看2樓原Po那種不受教的態度 感覺會走到今天的局面不意外
更不意外的是接下來二三十年都會是同樣局面不斷重複上演
可以拿到更多薪水為前提
你這篇的確很好,但前提是拿的薪水有足夠及同事們有意願
參與改善,至少你要是個小leader喊的動人呀
確實,有些人說重構其實是重寫
花的功完全不一樣
講的好像上班有空寫文件
你們公司沒時間寫嗎?
推個 希望有機會聽到進一步分享how
On提出數據說服主管/管理層 開發是越來越耗時間
認同 雖然我只是菜雞
要怎麼跟上頭說開發越來越久跟code quality有關
老實說資深員工就只是寫比較久而已 要他能扛架構扛管理扛資
源分配 真的太難了 最近剛被拉上去 心有戚戚焉
建議挺好的 但有點理想化
管理學是實務科學 缺乏現場情況會比較概念性一點
原PO不想聽訓想取暖去FB就好
超中肯
這篇文很合理啊,而且工作文件難度下班寫?
我怎麼覺得你提的比較像管理層要做的事啊
後面的部分
管理層負責做決策,執行細節不可能靠他們訂,越往上越是如此 工作一陣子你會發現其實管理層知道的資訊跟能做的事沒有你想的那麼多 以原po為例我假設他待夠久,技術細節又熟,在team內應該是有聲量的 每間公司的R&R不同,但通常決策層就是要扛責任 你推鍋給下面的人是沒有用的,只會顯得自己無能 所以資深成員的意見就會顯得很重要 大部分人還是想把事情做好,只是想法不同 有些人覺得code能動就好,髒髒的沒關係 (實際上很多情況確實是這樣) 你覺得要多花一點時間把整理,那就把成本跟效益拿出來說服人 就算沒推成,大家也會覺得「哦這個人講話是講證據的」 我還是想把重點放在解決問題 「這明明就是XXX該做,為什麼他們都不做」 抱怨完問題還是沒解決,你還是一樣累,環境還是一樣糟 有去了解別人的阻力是什麼嗎? 沒人推動為什麼不從你先開始推動呢? 改變別人很難,但讓自己從小事開始做很簡單 當然我假設原po待的是正常公司 如果不是的話那這篇也可以不用看,趕快換工作吧
*難道下班寫
推
我之前也很熱衷重構
結果就是弄完後,老闆會要你把業務交接別人
然後換一個屎坑讓你繼續重構
想取暖在自己朋友圈講就好了,這篇講了一大堆東西,你
只跟人家戰態度,不就正好說明你欠矯正的就是心態?
推
推
這篇滿實在的啊 玻璃心大可不必
推
推,文章精簡實用
推建設性的建議
只想聽自己想聽的何必發文
優文
推
推
現實就是下一個來接的新人會整個打掉重做
好文章。
我之前也認為不套架構不行,但後來經過一番掙扎,發現
敝團隊還沒人跑掉。
換而言之,就是這些東西不夠爛。所以主管叫我放他去,
不要管code quality也是合情合理。
不到黃河心不死,不見棺材不掉淚
推
好實在
46
首Po在公司待了好幾年,開發的系統越來越多。每個開發時都要搞懂一些新的業務邏輯,上線後 還要後續維護,有問題還要幫忙解決。 但我常常在想,人力沒變,但我身上的loading卻越來越重,現在的我比三年前的我多負責 了一堆系統問題,這樣是合理的嗎? 大家的公司都是這樣的嗎?21
(恕刪) : 問題是身為資深成員的你,可否提出數據說明工程宅們整天在吵的code quality到底跟業 : 務的關係在哪 : 是不是做同樣規模的feature要花的時間越來越多 : 是不是release後常常出問題要修32
推 yangs0618: 推個 希望有機會聽到進一步分享how 10/28 07:58 → yangs0618: On提出數據說服主管/管理層 開發是越來越耗時間 10/28 07:59 → panbanana: 要怎麼跟上頭說開發越來越久跟code quality有關 10/28 08:18 幾個很簡單的學術名詞就能說明,我相信大家也知道 耦合性 如果我改A模組,B模組就需要跟著改 (這還是B模組沒有牽連其他模組的情況下)17
微服務似乎可以改善一點這方面的問題 系統開發有點像是公司還很小的時侯 當你公司還很小的時侯 某個職員要當客服 又要兼倉管 又要兼銷售 所以這個職員可以拿到各種不同的數據
爆
Re: [心得] 如果可以, 真的建議不要再去創業公司了看到這篇好幾天了,想想還是也來分享一點個人經驗 我自己在業界的資歷沒有很久,也不是本科出身。 從十幾年前玩 open source 專案,誤打誤撞一路寫 code 到現在, 後來去國立資工所洗了一下 XD 所以現在也號稱本科了 研究所畢業後進入稍有規模的新創,後來也待了大公司。31
Re: [心得] AmazingTalker/台灣樂天市場 面試心得AmazingTalker CTO 回覆面試心得 (此為 AmazingTalker 人資部門代為轉發) 感謝版友分享在AmazingTalker的面試心得,也感謝各位大大的關心。 在招募過程中,我們一直檢討,並作出相應調整和改善。 當天面試過程不著墨太多。38
Re: [討論] 工作時一天coding的時間我覺得you對programming(台灣title比較浮誇 RD)有些misunderstand 實際上真正需要brain storming的時間 可說是少之又少 真的要BS也輪不到你這種菜鳥來BS BS出來最後也是滿口BS 程式開發是不斷iteration 確實是會有構想階段沒錯(看高度 程度越低就越不需要動腦)17
Re: [問卦] 人人都會寫code,工程師飯碗不保?所以才看的出素質高低啊! 有些程式維護起來累得半死,不寫註解、全域變數亂宣告、變數何處被改都不知道、沒有 物件導向觀念,程式一堆複製貼上、一堆函式參數亂丟、 一堆無意義迴圈、一堆奇奇怪怪的判斷,很愛自己亂幹邏輯、 程式碼排版雜亂不堪…8
Re: [閒聊]遊戲開發者抱怨現在程式碼誇張膨脹「可能有99%的內容都是這文就講幹話而已 尤其是拿大公司來舉例更是幹話 大部分大公司通常都是經歷過好幾段成長時期才會成為大公司 可能某系列作好幾代 可能做了好幾款作品8
Re: [討論] 同一個程式碼段落超過一人以上在修改不一定,可能合理可能很 suck 要看規模、工作流程、有沒有人控場、默契 自己的經驗是分工做得好的地方通常會定義 ownership 「這塊 code 是拎北/拎母的,要改要先問」 積極的 owner 會對 code 要長成怎樣有明確的想法並前進7
Re: [請益] 該辭職嗎?到哪都會遇到垃圾系統 還沒聽過哪家公司沒有垃圾code, legacy code, 歷史包袱的... 如果你的主要考量是這個系統太爛不想改他 那我會建議不要離職. 因為不管你走到哪,都會遇到一樣的問題3
Re: [心得] 如果可以, 真的建議不要再去創業公司了最近公司的狀況讓我有點理解原po的想法 但這應該都是個案啦 只是剛好近期也遇過兩位這樣的人 都是在新創工作&後來新創都收了&一人開發 有時候這種新創就真的不是要做多大的東西3
Re: [討論] 用AI寫code產生的疑問幾個未來可能的 cases: 當工程師工作開始都提早完成了,會有以下幾種發展 1-0: 裝忙不要被老闆發現 or 更早下班 1-1: 老闆接更多工作 1-2: 砍人,更少工程師做更多工作