新人加入新創如何避免踩雷
新人加入大公司如何避免踩雷
老實說 有答案？
新創 和 大公司 不管是環境 或者 能發揮的影響力 或者 風景..etc 都完全不一樣
人生這麼短暫 都看看不好？
在新創練功完去大公司被電
難道大公司練功完去新創不會被電???
但
就如上面說明的 環境需求一堆都在不一樣的基準點 那討論誰電誰 有意義？
因為你可以找到一個例子 我也可以找到一個反例 那就代表你的論述是不一定會成立
最後討論dirty code的問題
『dirty code 存在 取決於 目前業務端的情況和屬性 』
對於連自己客戶是誰都還不確定的新創而言 dirty code 我認為是有必要存在的
但不是100%的code base都是dirty code 而是有時候你必須要睜一隻眼閉一隻眼
我覺得 你既然要來新創 你必須要來了解新創的本質
怕熱 就不要進廚房
這是心態沒有調整好的問題
新創最重要的是什麼？ 是生存，是找到客戶付錢 好讓公司和員工活下去
我發現很多從大公司過來的主管或資深工程師
很下意識的把他們之前在大公司的習慣帶過來
例如 開發流程系統化 系統設計要嚴格 ...etc
但
創過業 或 待過早期創業團隊的人 應該都會知道
老闆知道前面有三條路 但真正是哪條 他自己也不完全確定
所以根據客戶的需求更動 或者 甚至整坨功能打掉 在新創圈 屢見不鮮
在這種需求快速變動的情況下 做嚴格的系統設計 有時會造成 需求調整時的巨大成本
所以就會發生 BD會怪工程那麼慢 工程會怪BD在那邊亂改需求
到頭來 根本原因 就是那些主導工程策略的人 自己不專業 還不自知
什麼樣業務規模 取決於下什麼樣的工程決策
沒有BD面 管你系統設計在棒 根本毫無意義
所以不要怪老闆 就是要快 dirty code也無所謂
因為他看的事情是生存問題
工程本來就是盡量跟BD面 配合 而不是起衝突
出社會也滿多年了 很多事情 不管你在哪一個scale的公司
你面對事情 的心態絕對是最重要的 互相理解 互相站在對方的立場去想
努力做對的事 少抱怨
看到太多人 出社會很多年 自省的能力也沒有培養起來 靠北靠母 都是They的錯
然後這種人 最後 你會發現 很明顯的就是自然而然 會在這個列車上
被多數人決定 放逐的人
結論
想加入大公司就去大公司 想加入新創就去新創
這世界的規則 就是
有些人特別幸運 有些人特別賽
考慮再多 老天爺一個突然安排 你還是無法控制
把自己的心態調整好 把 順利 / 不順 當作人生的風景 你只是過客
你會快樂多一些

dirty code 比較快我認為只是找藉口掩蓋自己能力不足而已沒什麼大小之分 只有強弱而已

沒有CICD 怎麼可能快得起來 沒有測試 你debug花的時間你有辦法評估？

你如果是要做B2B的生意，軟體品質太爛在業界怎麼生存？如果是被政府監管的行業，軟體品質更要重視，quick and dirty都最後還是要付出代價

這東西也沒辦法量化 每個人快得方式不一樣 大家都很快不過快然後 其他指標呢

有文件大家也確認規格沒問題後 做起來才會快啊 所以我

省下的時間就是技術債，就跟大家買房通常會貸款一樣

說大家快得方式不一樣 沒有訂好短期驗收目標的東西我不知道能多快 我是很慢啦

就算是 CRUD 前端一樣要先知道怎麼接 沒文件只能通靈那你的這種新創 我沒加入過 只能說辛苦了我也好奇變動這麼快的模式 在業界很常見嗎

新創需要的是快速迭代，不是隕石開發，如果需求一直毀滅那BD真的廢

變動如此快 反正也只能是老闆來扛起最後責任 那我避免加入這種公司

專案一直被隕石的，這個新創八成只是接案，哪裡有錢往哪跑

接案就不能算新創了吧 我以為新創是有新的商業模式

然後會覺得CICD/測試是慢，根本就是寫程式經驗很菜

我的回覆大部分是針對推文啦Dirty code 快 能夠快多久？

回Moon大，接案公司也可能是新創可能是要開發商品但沒啥資金燒只好接案過活看啥時有錢開發的公司

阿後來公司有做起來嗎抱歉我是回此文 po

沒，我已經逃出來了

新創感覺要加入拿到 A 輪後的 開始有穩定商業模式東西品質開始要求 不然 dirty code 我覺得對職涯發展蠻傷的但一切都是薪資問題 想到自己始終是打工仔就懷疑人生就你加入這種超早期新創的經驗 有拿到超過 1% 的期權嗎後來有行權嗎非常感謝分享

認同原po，我也是有相同感覺！

新創其實應該找即戰力,本身對feature就有過去的domainknowledge,而不是找菜鳥寫一堆dirty code,在那邊說文化如此如果新人進入新創就是學到dirty code,那以後只要新人問大公司還是新創該怎麼選,新人一率大公司因為讓新人寫dirty code是為了公司生存,但對新人職涯並不利

前期需求會不斷變動，又爛又快才是正確的，寫再好都可能要砍掉重寫所以要學著邊寫邊重構，當然壓力扛不住就是亂寫，之後穩定後閒閒沒事寧願看股票也沒心情填坑

公司面怎樣是老闆考量,員工要考量的是自己的職涯跟建議別人時,對方的職涯規劃我的話中哪裡有質疑為什麼這時期的新創寫dirty code對不對我的那邊就是寫下你的結論,新創這個時期就是dirty code再來新創做大這件事情回歸台灣新創成功上市比例有多高案例不少,但看整體比例會是多高？

我目前只待過新創 不同意你的意見特別是我們新創被併購後 更是不同意現在新創被併購 有資源有人 結果拖慢整體進度的人就是我們帶著這種dirty code time to market 但管理方法還在line用記事本 心智圖截圖法需求的老闆現在併購 有jira 有ci cd 工程師也多 結果開個ticket現在還要請人開 不合理主觀的需要求狂發 明明有一堆埋點工具不用老是聽幾使用者意見就帶著團隊花大把時間”去試”晚點回一片好了

十個新創九個雷可以調查一下新創的裁員比率有多高

完全同意這篇 我剛進來半年左右認為應該要把規矩訂好 架構寫好 但待了快一年之後 發現完全如同這篇所講。不過我現在還是先儘量以能架構化為主 如果真的沒辦法就 hard code 或有點髒也沒關係。這時 mongo 是個很好用的東西了 xd

我比較想知道開發途中有需求變更時，文件會怎樣維護如果頻繁的維護做白工的機率會很大吧

文件多多益善，解程式碼問題才會順手寫測試改業務程式碼

寫 test 可以確保你寫的東西可靠，速度慢我覺得是錯覺，終究你都要想辦法測你寫的東西，形式不同而已。

不過會寫dirty code的很大機率不用自己接後續維護多吃幾次自己拉的屎後就會改進了

原po提的可以理解，但可惜的是很多case也是用這“說法”但實際上確不符合原po講的情境

可理解但大家是不是忘了 dirty code 就是債而債是會拖累下次的開發速度的也許下次快 下下次呢 三個月後再回來改相關 code 呢如果公司快速成長又沒文件當初寫的人也走了那麼新進成員在開發效率上勢必會被拉慢

認同 dirty code有時只是時間成本的妥協 沒有一定對錯

有個極端例子就是均一教育平台雖然已經不算新創了但債爆到前陣子要上前後端社團徵求志工處理

技術債本就是要還的 某些情況你不貸就直接倒 你貸不貸

處理的債的時間也是成本問題新創哪有不忙

dirty code 哪裡有快, 是只能 dirty 來快的程度造成

新創有個特性，就是隨時會 pivot ，爛 code 的技術債常常根本不用還，一 pivot 就整坨刪除。關於文件的維護，最好的方式就是沒有文件，然後做到程式碼即文件，註解該寫就寫，commit log 認真寫，這樣就很夠了。

dirty code要看程度，不會要求完美，但基本的一定要有

經驗/能力不足才覺得dirty快的起來

dirty code不是不行,但不能一直用dirty code

dirty code的確很快 但只建立在不用還技術債的情形上

看 dirty 程度吧 有時候類似邏輯又還想不到整合 主管也會說先就保留兩個版本 以後 feature 穩定再 refact

中肯文

不好意思給了個反推，自己待新創的經驗是code quality太差反而到後期沒辦法快速迭待，也沒辦法快速scaleup. 重要的是MVP的觀念，如何只做最重要的feature,盡可能把有限的資源做最大化而不是犧牲品質

如果能學會用標點符號更好

你戳破某些人的幻想泡泡了 XD

推 andykao，和我的經驗一樣，爛 code 一開始看起來很快，但實際上根本沒辦法應付不斷新增和變動的需求。沒 CICD 和自動化測試也是，爛 code 改 A 壞 B 是家常便飯，每天修 bug 就飽了。

寫Dirty code很好啊,TMD別叫我接著去維護就OK

嗯 我發現我有點誤會原po了 推回來

code常因為新創面向市場會被廢棄掉的話, 那的確多個CICD沒幫助一些極端情況不得不然

Dirty Code也分寫的好不好的 寫的好就是之後要改很容易不然一堆Hard code 最好是之後要改比系統化的容易

每個人的dirty code都不同啊XD 有些比dirty還慘

推。個人想法這篇其實重點不在細節執行面，比較像是在討論新創不同發展階段下的文化也好組織需求也好新創很多時候其實是在做POC概念驗證，這時候的重點不在你用多漂亮的方法達到目標功能，而是這個功能符不符合目標價值，在這種情況下其實只要產品能動不要有大問題先驗證功能能夠滿足需求滿足價值，再來討論怎樣優化才有意義。 所以重點其實不是程式或方法髒不髒，而是如何盡可能用最小的資源去驗證價值只是用最小資源的情況下"通常"程式或方法會比較髒而已

推

推

開發好像很快，結果脆弱的要死，技術債又一堆，越走越慢

這篇好！原原po不爽就噓略失風度，小小格局有限。