作者stillboy (joey)
看板Soft_Job
标题Re: [心得] 加入新创如何避免踩雷
时间Sat Apr 10 16:15:49 2021
新人加入新创如何避免踩雷
新人加入大公司如何避免踩雷
老实说 有答案？
新创 和 大公司 不管是环境 或者 能发挥的影响力 或者 风景..etc 都完全不一样
人生这麽短暂 都看看不好？
在新创练功完去大公司被电
难道大公司练功完去新创不会被电???
但
就如上面说明的 环境需求一堆都在不一样的基准点 那讨论谁电谁 有意义？
因为你可以找到一个例子 我也可以找到一个反例 那就代表你的论述是不一定会成立
最後讨论dirty code的问题
『dirty code 存在 取决於 目前业务端的情况和属性 』
对於连自己客户是谁都还不确定的新创而言 dirty code 我认为是有必要存在的
但不是100%的code base都是dirty code 而是有时候你必须要睁一只眼闭一只眼
我觉得 你既然要来新创 你必须要来了解新创的本质
怕热 就不要进厨房
这是心态没有调整好的问题
新创最重要的是什麽？ 是生存，是找到客户付钱 好让公司和员工活下去
我发现很多从大公司过来的主管或资深工程师
很下意识的把他们之前在大公司的习惯带过来
例如 开发流程系统化 系统设计要严格 ...etc
但
创过业 或 待过早期创业团队的人 应该都会知道
老板知道前面有三条路 但真正是哪条 他自己也不完全确定
所以根据客户的需求更动 或者 甚至整坨功能打掉 在新创圈 屡见不鲜
在这种需求快速变动的情况下 做严格的系统设计 有时会造成 需求调整时的巨大成本
所以就会发生 BD会怪工程那麽慢 工程会怪BD在那边乱改需求
到头来 根本原因 就是那些主导工程策略的人 自己不专业 还不自知
什麽样业务规模 取决於下什麽样的工程决策
没有BD面 管你系统设计在棒 根本毫无意义
所以不要怪老板 就是要快 dirty code也无所谓
因为他看的事情是生存问题
工程本来就是尽量跟BD面 配合 而不是起冲突
出社会也满多年了 很多事情 不管你在哪一个scale的公司
你面对事情 的心态绝对是最重要的 互相理解 互相站在对方的立场去想
努力做对的事 少抱怨
看到太多人 出社会很多年 自省的能力也没有培养起来 靠北靠母 都是They的错
然後这种人 最後 你会发现 很明显的就是自然而然 会在这个列车上
被多数人决定 放逐的人
结论
想加入大公司就去大公司 想加入新创就去新创
这世界的规则 就是
有些人特别幸运 有些人特别赛
考虑再多 老天爷一个突然安排 你还是无法控制
把自己的心态调整好 把 顺利 / 不顺 当作人生的风景 你只是过客
你会快乐多一些
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.160.145.196 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1618042552.A.F46.html
1F：→ MoonCode: dirty code 比较快我认为只是找藉口掩盖自己能力不足而 04/10 16:42
2F：→ MoonCode: 已 04/10 16:42
3F：→ MoonCode: 没什麽大小之分 只有强弱而已 04/10 16:44
dirty code比较快 没啥好争议
要做完整的规划和分析 花的时间就是比较多 慢工出细活
除非你本身已经做过此feature很多遍
至於强弱问题 不如说抉择问题
4F：→ nekosgr93: 蔡逼八刚进新创也觉得应该要跟大公司一样有严格的开发 04/10 16:46
5F：→ nekosgr93: 流程 04/10 16:46
6F：→ nekosgr93: 要有测试 04/10 16:46
7F：→ nekosgr93: 要建CICD 04/10 16:46
8F：→ nekosgr93: 要clean code 04/10 16:46
9F：→ nekosgr93: 後来才终於醒了 04/10 16:46
10F：→ nekosgr93: 品质都是假的 04/10 16:46
11F：→ nekosgr93: 投资人的钱钱才是真的 04/10 16:46
12F：→ nekosgr93: 除非老板很有钱或有富爸爸 04/10 16:46
13F：→ nekosgr93: 不然你还在慢慢建流程老板明天资金就烧完了 04/10 16:46
14F：→ nekosgr93: 建立文化那是在赚钱後才该做的事 04/10 16:46
15F：嘘 MoonCode: 没有CICD 怎麽可能快得起来 没有测试 你debug花的时间 04/10 16:47
16F：→ MoonCode: 你有办法评估？ 04/10 16:47
你未来需求会更改的情况下 你写testing的目的是？
CI/CD或者一些基础的自动化或style规范 并不在我讨论设计系统的范畴
再者 dirty code 可能在某些情况下 还比较好debug
比起那种没写好的多重依赖 是爽多了
17F：→ nekosgr93: CICD测试也是要有人去写有人去维护 04/10 16:48
18F：→ nekosgr93: 大家谈自动化都很简单 04/10 16:48
19F：→ nekosgr93: 可是自动化也是有人要去做的 04/10 16:48
20F：→ nekosgr93: 对於人力资源很吃紧的新创来说是最不应该优先做的事 04/10 16:48
21F：嘘 hegemon: 你如果是要做B2B的生意，软体品质太烂在业界怎麽生存？如 04/10 16:50
22F：→ hegemon: 果是被政府监管的行业，软体品质更要重视，quick and dir 04/10 16:50
23F：→ hegemon: ty都最後还是要付出代价 04/10 16:50
程式码写的脏 跟 产品会不会动 这件事情是两回事
相信h大在台积电的时候也应该可以完全理解
那这样说起来M , m 那些程式码 不就贻笑大方了 XD
24F：嘘 MoonCode: 这东西也没办法量化 每个人快得方式不一样 大家都很快 04/10 16:51
25F：→ MoonCode: 不过快然後 其他指标呢 04/10 16:52
业务面先起来 一切好说 否则你把文件搞起来 需求变了 公司倒了 文件要干嘛
26F：→ nekosgr93: 就像大家都知道文件很重要 04/10 16:52
27F：→ nekosgr93: 规格很重要 04/10 16:52
28F：→ nekosgr93: 但实际上谁要去写 04/10 16:52
29F：→ nekosgr93: 谁要去维护更新呢 04/10 16:52
30F：→ nekosgr93: 如果你平常忙写feture忙解bug都来不及了怎麽可能有时 04/10 16:52
31F：→ nekosgr93: 间去管那些 04/10 16:52
32F：→ nekosgr93: 只能说不同公司规模大小做法不同罗 04/10 16:53
33F：→ MoonCode: 有文件大家也确认规格没问题後 做起来才会快啊 所以我 04/10 16:53
34F：推 lova: 省下的时间就是技术债，就跟大家买房通常会贷款一样 04/10 16:54
35F：→ MoonCode: 说大家快得方式不一样 没有订好短期验收目标的东西 04/10 16:54
36F：→ MoonCode: 我不知道能多快 我是很慢啦 04/10 16:54
技术债 不可能避免 你只可能尽量减少 省下来的时间是帮业务面争取时间
然後我有说 不用基本的spec吗 XD
※ 编辑: stillboy (1.160.145.196 台湾), 04/10/2021 17:05:31
37F：→ nekosgr93: 以新创来说需求变动很快的 04/10 16:55
38F：→ nekosgr93: 你花一天写好的文件可能隔天就通通改掉或甚至不要了 04/10 16:55
39F：→ MoonCode: 就算是 CRUD 前端一样要先知道怎麽接 没文件只能通灵 04/10 16:56
40F：→ MoonCode: 那你的这种新创 我没加入过 只能说辛苦了 04/10 16:56
41F：→ MoonCode: 我也好奇变动这麽快的模式 在业界很常见吗 04/10 16:57
机率不高。 而且我也强调 要有基础的spec
42F：推 alihue: 新创需要的是快速迭代，不是陨石开发，如果需求一直毁灭 04/10 16:58
43F：→ alihue: 那BD真的废 04/10 16:59
理想情况 当然不想要陨石 但17 live刚开始几年 都是陨石度过
强的BD 可遇不可求
44F：→ MoonCode: 变动如此快 反正也只能是老板来扛起最後责任 那我避免 04/10 16:59
45F：→ MoonCode: 加入这种公司 04/10 16:59
那你可能适合加入大公司 或者 已经找到确定需求的 高速成长的新创公司
但其实很多时候也在摸索
46F：→ alihue: 专案一直被陨石的，这个新创八成只是接案，哪里有钱往哪跑 04/10 17:00
47F：→ MoonCode: 接案就不能算新创了吧 我以为新创是有新的商业模式 04/10 17:00
48F：推 alihue: 然後会觉得CICD/测试是慢，根本就是写程式经验很菜 04/10 17:05
这样讲太过武断 一直陨石 某种程度很可能是BD的问题 跟接案无关
※ 编辑: stillboy (1.160.145.196 台湾), 04/10/2021 17:13:42
49F：推 MoonCode: 我的回覆大部分是针对推文啦 04/10 17:22
50F：→ MoonCode: Dirty code 快 能够快多久？ 04/10 17:23
没量过 但我只知道 不写dirty code 要把一个feature里里外外 想通想透 并设计好
时间成本会远大於写dirty code
我说这样 不代表我支持写dirty code
非常时期非常手段 取舍问题
※ 编辑: stillboy (1.160.145.196 台湾), 04/10/2021 17:28:01
51F：推 newhandfun: 回Moon大，接案公司也可能是新创 04/10 17:29
52F：→ newhandfun: 可能是要开发商品但没啥资金烧只好接案过活看啥时有 04/10 17:29
53F：→ newhandfun: 钱开发的公司 04/10 17:29
54F：→ MoonCode: 阿後来公司有做起来吗 04/10 17:29
有的有 有的没有 但早已经离开新创圈了
55F：→ MoonCode: 抱歉我是回此文 po 04/10 17:31
56F：推 newhandfun: 没，我已经逃出来了 04/10 17:31
57F：→ MoonCode: 新创感觉要加入拿到 A 轮後的 开始有稳定商业模式 04/10 17:32
补充一下 很多新创一开始的策略都是
接案(现金流) -> 去养自己想做的产品
除非你是富爸爸 後面有金主 不然 基本上没有稳定现金流 会是很可怕的
※ 编辑: stillboy (1.169.170.171 台湾), 04/10/2021 17:35:51
58F：→ MoonCode: 东西品质开始要求 不然 dirty code 我觉得对职涯发展 04/10 17:33
59F：→ MoonCode: 蛮伤的 04/10 17:33
60F：→ MoonCode: 但一切都是薪资问题 想到自己始终是打工仔就怀疑人生 04/10 17:34
所以以你的需求 你应该要近的反而是 大公司 or 有规模以上的高速成长新创
在那边 你才可能得到你要的东西
选择比努力重要
※ 编辑: stillboy (1.169.170.171 台湾), 04/10/2021 17:40:09
61F：→ MoonCode: 就你加入这种超早期新创的经验 有拿到超过 1% 的期权吗 04/10 17:41
62F：→ MoonCode: 後来有行权吗 04/10 17:41
没超过1% 没行权。
年轻时，加入新创不是for money
而是觉得很cool 不想加入大公司当螺丝钉 想做出大贡献
每个人的理由都不同
想清楚就好
※ 编辑: stillboy (1.169.170.171 台湾), 04/10/2021 17:47:04
63F：→ MoonCode: 非常感谢分享 04/10 17:48
64F：推 MoonCode: 04/10 17:50
65F：推 dmlan1842: 认同原po，我也是有相同感觉！ 04/10 17:57
※ 编辑: stillboy (1.169.170.171 台湾), 04/10/2021 18:19:12
66F：→ discipile: 新创其实应该找即战力,本身对feature就有过去的domain 04/10 18:15
67F：→ discipile: knowledge,而不是找菜鸟写一堆dirty code,在那边说文化 04/10 18:17
68F：→ discipile: 如此 04/10 18:17
有钱 富爸爸的新创可以
但没钱的很难 很多甚至都希望你自配电脑 能省则省
而且即战力资深 愿不愿意加入一家默默无名的公司 又是另外一个大难题
找菜鸟写dirty code 接案 有现金流 能验证商业模式 才有变更好的可能
先活着 再谈梦想
※ 编辑: stillboy (1.169.170.171 台湾), 04/10/2021 18:22:23
69F：→ discipile: 如果新人进入新创就是学到dirty code,那以後只要新人问 04/10 18:22
70F：→ discipile: 大公司还是新创该怎麽选,新人一率大公司 04/10 18:23
71F：→ discipile: 因为让新人写dirty code是为了公司生存,但对新人职涯并 04/10 18:23
72F：→ discipile: 不利 04/10 18:23
同上面，如果不想写dirty code就该避免加入这个时期的新创
对新人而言 他的确可能在这个时期写了dirty code
而如果幸运的话，
随着业务的发展 业务开始稳定 他有机会慢慢把自己的程式码开始重构
而且重构起来会更有心得 而且成就感更大 如果工程Team开始长大
开始找人 有机会带人 并做出更大的贡献
这种例子 也不算少
73F：→ leo5916267: 前期需求会不断变动，又烂又快才是正确的，写再好都 04/10 18:26
74F：→ leo5916267: 可能要砍掉重写所以要学着边写边重构，当然压力扛不 04/10 18:26
75F：→ leo5916267: 住就是乱写，之後稳定後闲闲没事宁愿看股票也没心情 04/10 18:26
76F：→ leo5916267: 填坑 04/10 18:26
※ 编辑: stillboy (1.169.170.171 台湾), 04/10/2021 18:36:01
77F：→ discipile: 公司面怎样是老板考量,员工要考量的是自己的职涯跟建议 04/10 18:29
78F：→ discipile: 别人时,对方的职涯规划 04/10 18:30
考量自己这件事情本身没有问题
但是如果要做出更具影响力的贡献
懂的牺牲 站在整个团队甚至公司的角度
去评估这个决策是否合宜
※ 编辑: stillboy (1.169.170.171 台湾), 04/10/2021 18:38:20
79F：→ discipile: 我的话中哪里有质疑为什麽这时期的新创写dirty code对 04/10 18:38
80F：→ discipile: 不对 04/10 18:38
理解错误 已修正有争议的那一行
81F：→ discipile: 我的那边就是写下你的结论,新创这个时期就是dirty code 04/10 18:38
82F：→ discipile: 再来新创做大这件事情回归台湾新创成功上市比例有多高 04/10 18:39
低到不行。
但上市的这个条件我觉得有点严苛 XD
※ 编辑: stillboy (1.169.170.171 台湾), 04/10/2021 18:45:21
83F：→ discipile: 案例不少,但看整体比例会是多高？ 04/10 18:41
84F：嘘 Ghamu: 我目前只待过新创 不同意你的意见 04/10 18:47
85F：→ Ghamu: 特别是我们新创被并购後 更是不同意 04/10 18:47
86F：→ Ghamu: 现在新创被并购 有资源有人 结果拖慢整体进度的人就是我们 04/10 18:50
87F：→ Ghamu: 带着这种dirty code time to market 但管理方法还在line用 04/10 18:50
88F：→ Ghamu: 记事本 心智图截图法需求的老板 04/10 18:50
89F：→ Ghamu: 现在并购 有jira 有ci cd 工程师也多 结果开个ticket现在还 04/10 18:52
90F：→ Ghamu: 要请人开 不合理主观的需要求狂发 明明有一堆埋点工具不用 04/10 18:52
91F：→ Ghamu: 老是听几使用者意见就带着团队花大把时间”去试” 04/10 18:52
92F：→ Ghamu: 晚点回一片好了 04/10 19:10
93F：推 May75504: 十个新创九个雷 04/10 20:42
94F：→ May75504: 可以调查一下新创的裁员比率有多高 04/10 20:44
95F：推 kewang: 完全同意这篇 我刚进来半年左右认为应该要把规矩订好 架构 04/10 20:54
96F：→ kewang: 写好 但待了快一年之後 发现完全如同这篇所讲。不过我现在 04/10 20:54
97F：→ kewang: 还是先尽量以能架构化为主 如果真的没办法就 hard code 或 04/10 20:54
98F：→ kewang: 有点脏也没关系。这时 mongo 是个很好用的东西了 xd 04/10 20:54
99F：→ lazarus1121: 我比较想知道开发途中有需求变更时，文件会怎样维护 04/10 21:12
100F：→ lazarus1121: 如果频繁的维护做白工的机率会很大吧 04/10 21:13
101F：→ nekosgr93: dirty code就看有没有自觉了 04/10 21:25
102F：→ nekosgr93: 如果是对code品质有要求的我相信就算现在要为了mvp赶 04/10 21:25
103F：→ nekosgr93: 出来也一定会觉得浑身不舒服想要修的更clean 04/10 21:25
104F：→ nekosgr93: 那在产品还没有变得过大之前就会想办法慢慢的补技术债 04/10 21:25
105F：→ nekosgr93: 了 04/10 21:25
106F：→ nekosgr93: 而且我觉得dirty code也不是新创专利 04/10 21:25
107F：→ nekosgr93: 很多大公司老专案的code也是脏到不行而且员工还会觉得 04/10 21:25
108F：→ nekosgr93: 能run就好了没事不要去改他 04/10 21:25
109F：推 labbat: 文件多多益善，解程式码问题才会顺手写测试改业务程式码 04/10 21:30
110F：→ red0210: 写 test 可以确保你写的东西可靠，速度慢我觉得是错觉， 04/10 22:09
111F：→ red0210: 终究你都要想办法测你写的东西，形式不同而已。 04/10 22:09
112F：→ lazarus1121: 不过会写dirty code的很大机率不用自己接後续维护 04/10 22:12
113F：→ lazarus1121: 多吃几次自己拉的屎後就会改进了 04/10 22:13
114F：推 sssh9300662: 原po提的可以理解，但可惜的是很多case也是用这“说 04/10 22:43
115F：→ sssh9300662: 法”但实际上确不符合原po讲的情境 04/10 22:43
116F：→ soccer103: 可理解但大家是不是忘了 dirty code 就是债 04/10 22:51
117F：→ soccer103: 而债是会拖累下次的开发速度的 04/10 22:52
118F：→ soccer103: 也许下次快 下下次呢 三个月後再回来改相关 code 呢 04/10 22:52
119F：→ soccer103: 如果公司快速成长 04/10 22:54
120F：→ soccer103: 又没文件当初写的人也走了 04/10 22:54
121F：→ soccer103: 那麽新进成员在开发效率上势必会被拉慢 04/10 22:54
122F：推 CoverMind: 认同 dirty code有时只是时间成本的妥协 没有一定对错 04/10 22:55
123F：→ soccer103: 有个极端例子就是均一教育平台 04/10 22:55
124F：→ soccer103: 虽然已经不算新创了但债爆到前阵子要上前後端社团徵求 04/10 22:55
125F：→ soccer103: 志工处理 04/10 22:55
126F：→ CoverMind: 技术债本就是要还的 某些情况你不贷就直接倒 你贷不贷 04/10 22:57
127F：→ soccer103: 处理的债的时间也是成本 04/10 22:57
128F：→ soccer103: 问题新创哪有不忙 04/10 22:57
129F：嘘 sharku: dirty code 哪里有快, 是只能 dirty 来快的程度造成 04/10 23:23
130F：推 accessdenied: 新创有个特性，就是随时会 pivot ，烂 code 的技术 04/10 23:27
131F：→ accessdenied: 债常常根本不用还，一 pivot 就整坨删除。关於文件 04/10 23:27
132F：→ accessdenied: 的维护，最好的方式就是没有文件，然後做到程式码即 04/10 23:27
133F：→ accessdenied: 文件，注解该写就写，commit log 认真写，这样就很 04/10 23:27
134F：→ accessdenied: 够了。 04/10 23:27
135F：→ nekosgr93: 公司没钱只请得起水电学徒请不起水电师傅那工程弄得丑 04/10 23:39
136F：→ nekosgr93: 一点也是没有办法的罗 04/10 23:39
137F：→ nekosgr93: 看学徒有没有自觉想弄的更完美一点 04/10 23:39
138F：→ nekosgr93: 不然就是等公司赚钱了请师傅来大修 04/10 23:39
139F：→ nekosgr93: 虽然我觉得会被呛说没钱就不要出来开公司 04/10 23:39
140F：推 jack0204: dirty code要看程度，不会要求完美，但基本的一定要有 04/11 00:17
141F：→ sharek: 经验/能力不足才觉得dirty快的起来 04/11 00:47
142F：→ viper9709: dirty code不是不行,但不能一直用dirty code 04/11 00:55
143F：→ nekosgr93: 我觉得有个重点是 04/11 00:59
144F：→ nekosgr93: 不是因为dirty所以才快 04/11 00:59
145F：→ nekosgr93: 是因为快(加上没钱)所以才dirty 04/11 00:59
147F：推 vi000246: dirty code的确很快 但只建立在不用还技术债的情形上 04/11 01:02
148F：→ nekosgr93: 应该没有任何一个正常的工程师会想写义大利面的 04/11 01:03
149F：推 mirror0227: 看 dirty 程度吧 有时候类似逻辑又还想不到整合 主管 04/11 01:55
150F：→ mirror0227: 也会说先就保留两个版本 以後 feature 稳定再 refact 04/11 01:55
151F：推 taipoo: 中肯文 04/11 02:31
152F：嘘 andykao1213: 不好意思给了个反推，自己待新创的经验是code qualit 04/11 09:32
153F：→ andykao1213: y太差反而到後期没办法快速迭待，也没办法快速scale 04/11 09:32
154F：→ andykao1213: up. 重要的是MVP的观念，如何只做最重要的feature, 04/11 09:32
155F：→ andykao1213: 尽可能把有限的资源做最大化而不是牺牲品质 04/11 09:32
156F：推 tvbic: 如果能学会用标点符号更好 04/11 11:33
157F：推 UniFish: 你戳破某些人的幻想泡泡了 XD 04/11 11:41
158F：推 brianhsu: 推 andykao，和我的经验一样，烂 code 一开始看起来很快 04/11 13:49
159F：→ brianhsu: ，但实际上根本没办法应付不断新增和变动的需求。没 CIC 04/11 13:49
160F：→ brianhsu: D 和自动化测试也是，烂 code 改 A 坏 B 是家常便饭，每 04/11 13:49
161F：→ brianhsu: 天修 bug 就饱了。 04/11 13:49
162F：推 hongsiangfu: 写Dirty code很好啊,TMD别叫我接着去维护就OK 04/11 14:03
163F：推 Ghamu: 嗯 我发现我有点误会原po了 推回来 04/11 14:20
164F：推 atpx: code常因为新创面向市场会被废弃掉的话, 那的确多个CICD没帮 04/11 18:30
165F：→ atpx: 助 04/11 18:30
166F：→ atpx: 一些极端情况不得不然 04/11 18:31
167F：→ cha122977: Dirty Code也分写的好不好的 写的好就是之後要改很容易 04/11 22:05
168F：→ cha122977: 不然一堆Hard code 最好是之後要改比系统化的容易 04/11 22:07
169F：推 ZakuSIN: 每个人的dirty code都不同啊XD 有些比dirty还惨 04/13 17:40
170F：推 travelmat: 推。个人想法这篇其实重点不在细节执行面，比较像是在 04/14 07:45
171F：→ travelmat: 讨论新创不同发展阶段下的文化也好组织需求也好 04/14 07:46
172F：→ travelmat: 新创很多时候其实是在做POC概念验证，这时候的重点不在 04/14 07:48
173F：→ travelmat: 你用多漂亮的方法达到目标功能，而是这个功能符不符合 04/14 07:48
174F：→ travelmat: 目标价值，在这种情况下其实只要产品能动不要有大问题 04/14 07:49
175F：→ travelmat: 先验证功能能够满足需求满足价值，再来讨论怎样优化 04/14 07:50
176F：→ travelmat: 才有意义。 所以重点其实不是程式或方法脏不脏，而是 04/14 07:51
177F：→ travelmat: 如何尽可能用最小的资源去验证价值 04/14 07:52
178F：→ travelmat: 只是用最小资源的情况下"通常"程式或方法会比较脏而已 04/14 07:53
179F：推 twin2: 推 04/14 10:08
180F：推 OldDaiDai: 推 04/14 18:11
181F：→ abraxas: 开发好像很快，结果脆弱的要死，技术债又一堆，越走越慢 04/15 09:05
182F：推 kongyeah: 这篇好！原原po不爽就嘘略失风度，小小格局有限。 04/15 17:34