作者chengcti (版主请投我一票!)
看板Soft_Job
标题Re: [讨论] 对技术没热情是不是不适合这行？
时间Wed Jun 15 15:04:39 2022
新创最爱用「新技术」
能赚钱 好用 稳定
为什麽要用新技术？
那是因为 旧技术赚钱的公司都在前面
你拿旧技术怎麽跟前面比
当然要拿新技术才能要到钱
稳定 快速上线 才是王道
新技术能活下去的没几个
因为出问题 找不到人家解
除非技术是自己创新研发 不是网路上挖来研究的
※ 引述《PRCXi (中华人民共和国主席)》之铭言：
: 小弟文组资策会转职仔，入行刚满六年
: 前五年靠着学校名字进了两间知名大公司，今年初跳槽到一间新创
: 在前两间公司的时候步调比较慢，而且教学文件非常完整，甚至还教学有影片
: 而使用的技术也是5~10年前左右的那种，遇到问题、BUG网路都一大票资料
: 这五年来也过得没什麽压力，我也自认为自己技术有一直在成长
: 至少在公司里的程式问题除了MIS、SRE那方面的我都能应付、解决
: 今年初到了现在这间新创後，整个步调都超级快
: 除了新人蜜月期两周外每天都是超高压的工作环境
: 除了CTO、TL都要求大家走最新的框架外，程式架构也是我之前都没碰过的
: 因为不熟，每天的进度报告我都是进度落後的那个
: 之後我开始用下班时间看技术文件，自己尝试跟着实作，每天弄到12点多
: 两个多月过去了，我开始发现自己好像不太喜欢这种东西
: 看技术文件也常常五分钟後就开始觉得无聊、不想看，完全没有在前公司学习的那种感
觉
: 前天跟主管一对一谈话中，主管也说他感觉不到我对技术的热忱
: 觉得我是一个比较被动接受的人，要我考虑一下往後的职涯想怎麽走
: 加上昨天听到前同事在说，前公司新进来的新人说我当初留下的扣很烂，想全部翻掉
: 让我更加觉得自己的技术很烂，前五年好像都是自我感觉良好
: 想请问各位大大，我现在入行六年还没破百(目前年薪9X)
: 技术差加上对技术没热情，是不是真的转行比较好？
: 谢谢各位的回覆！！ 我会考虑找自己适合的公司or银行IT试试看
: 另外补充说明一下
: 会有转行念头的最大原因是前天跟主管的对谈
: 主管提到对技术没有热忱很难在这行走得远，加上我算大龄(31)又有一些年资
: 不能一直待在junior的位置，要想往後升上去绝对避不开自己钻研新技术
: 他说如果真的没兴趣就要好好想想职涯未来的规划
: 听完之後我是真的很迷惘，才会有该不该及早停损的念头
: 再加上又听到自己之前的扣被嫌成像一坨屎，算是最後一根稻草吧
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 37.19.205.185 (日本)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1655276682.A.EE8.html
1F：推 KaoZen: 推06/15 15:32
2F：推 ogsogsogs: 推 要够炫炮才能骗到创投06/15 15:36
3F：→ odahawk: 有的时候能拿到创投就是成功 06/15 15:52
4F：推 hegemon: 现在资金紧缩，用最小的成本把东西开出来让人买单比什麽06/15 16:28
5F：→ hegemon: 都重要，要炫炮的话自己去community，不要拿全体投资人跟06/15 16:28
6F：→ hegemon: 员工去陪你炫06/15 16:28
7F：推 qwer338859: 确实 06/15 16:51
8F：→ s06yji3: 赚不赚钱应该是商业模式。新旧技术大多是工程师的偏好而06/15 17:24
9F：推 min86615: 雀食06/15 17:56
10F：→ EPGo: 新旧技术是工程师的偏好，跟公司获利无关06/15 19:24
11F：推 EPGo: 会有新的技术多半是为了解决某些问题，但随着迭代过程，可能06/15 19:28
12F：→ EPGo: 被淘汰06/15 19:28
新技术只能找两个人
旧技术能找到十个人
成品都一样 使用者UX也感觉不出技术差异
为什麽一定要新技术
况且新技术拥有者如果离职 後面维护成本更高
※ 编辑: chengcti (37.19.205.185 日本), 06/15/2022 20:19:54
13F：推 s06yji3: 所以说跟公司赚不赚钱没有差。有些系统旧的技术就是不好 06/15 20:57
14F：→ s06yji3: 用，那当然用新的0.0 06/15 20:57
15F：→ alan3100: 新技术就是解决或改善旧技术问题 用旧技术会越来越少 06/15 22:03
16F：嘘 hegemon: 如果自己搞不成熟的新东西炫炮导致之後维护困难+找不到人 06/15 22:50
17F：→ hegemon: ，这样就得不偿失 06/15 22:50
18F：→ tofuflower: 新技术会出现是因为旧技术在某些场景有局限 06/15 23:42
19F：→ tofuflower: 但不代表新技术能取代旧技术表现良好的场景 06/15 23:43
20F：→ tofuflower: 重点是先搞清楚问题 (why)，然後是怎麽解决 (how) 06/15 23:45
21F：→ tofuflower: 最後才是用什麽技术解决 (what) 06/15 23:45
22F：→ tofuflower: java 没有取代 C/C++，node / python / golang 06/15 23:46
23F：→ tofuflower: 也没取代 java 06/15 23:47
24F：推 ku72: 有时候也觉得 很奇怪 明明旧有的语言 架构也能解决问题 但却 06/15 23:54
25F：→ ku72: 硬要导入新的语言框架的人 除了满足自己的技术癖外 还能有啥 06/15 23:54
26F：→ ku72: 好处…… 06/15 23:54
27F：→ tofuflower: 履历好看的好处啊 颗颗 06/15 23:55
28F：→ tofuflower: 啊 还有个情况，已经没在维护更新的旧技术的确该淘汰 06/15 23:57
29F：→ ku72: 然後一堆人说用新技术是为了填补旧技术的缺少 老实说 我从改 06/16 00:03
30F：→ ku72: 机器码 组合语言 C／C++ 一路玩到PHP GO C# 这些高阶语言 还 06/16 00:03
31F：→ ku72: 真的没有用C/C++刻不出来的功能跟框架 我的认知新语言技术其 06/16 00:03
32F：→ ku72: 实很大一部分是让後入者也能快速进 06/16 00:03
33F：→ ku72: 入实现功能而已 对於有现有框架的应该优先再框架内解决问题 06/16 00:03
34F：→ ku72: 不能就自己扩展 再不行才会是导入新架构技术 几年前有个不大 06/16 00:03
35F：→ ku72: 专案一共用了5种语言 3种数据库 再加上zookeeper Kafka 一整 06/16 00:03
36F：→ ku72: 个挑战团队成员的天份 反正我走後没听过有後面的人可以跟我 06/16 00:03
37F：→ ku72: 一样和这个主管一起这样玩的… 但我真的觉得这样很无聊…… 06/16 00:03
38F：→ tofuflower: 在什麽时候导入新技术也是门学问，需要点实务历练 06/16 00:11
39F：推 EricTCartman: @ku72 我还真的有跟这种主管玩过 我大概用了三种语 06/16 00:27
40F：→ EricTCartman: 言+两种资料库 其他人各负责一种 06/16 00:27
41F：→ EricTCartman: 反正上班领钱玩玩东西还不错 06/16 00:28
42F：推 s06yji3: 一个不大的专案用5种语言和3种数据库。如果不是需求的话 06/16 01:35
43F：→ s06yji3: ，那是决策的问题，跟用不用新技术根本没关系。有新技术 06/16 01:35
44F：→ s06yji3: 可以符合需求为什麽要自己造轮子？ 06/16 01:35
45F：推 EPGo: 推 tofuflower 06/16 08:31
46F：推 sssh9300662: 跟赚不赚钱当然有关啊，同样水准的人难找代表你relea 06/16 08:34
47F：→ sssh9300662: se的东西就少，和难补人。问题难解决，系统不稳定， 06/16 08:34
48F：→ sssh9300662: 服务不能用都是 06/16 08:34
49F：→ ku72: 上面有说到重点了 补不到人 然後勉强补了也帮不上忙 06/16 08:44
50F：→ ku72: 然後 用不用新技术一直都是决策问题 而不是技术问题 为什麽 06/16 08:52
51F：→ ku72: 会用到这麽多语言技术 不就是为了不造轮子 但结果其实没更好 06/16 08:52
52F：推 ricestand: 推ku72 06/16 09:09
53F：推 jobintan: 新技术来能用Buzzword骗到VC/PE呀！ 06/16 09:18
54F：→ superpandal: 我是逆着学回去 造轮子意义就是好控制 用别人的要会 06/16 09:41
55F：→ superpandal: 技术细节不然你造的出来的应用大家都造的出来 没什麽 06/16 09:42
56F：→ superpandal: 区别 也很浪费时间 有些机制你想搞出来迎合需求也很 06/16 09:43
57F：→ superpandal: 想吐 实现的特别丑 06/16 09:45
58F：→ superpandal: 还有很多现成的都有坑 坑到你会抓狂 kafka类的如果你 06/16 09:47
59F：→ superpandal: 懂原理都可以自己造一个 06/16 09:50
60F：→ superpandal: 一直追新不代表真的进步 职场每个人都在展现自己觉得 06/16 09:54
61F：→ superpandal: 有信心的一面 也会用这一面来看别人 06/16 09:54
62F：→ superpandal: 自己搞而且不乱搞的话很多面向品质都可以有一定保证 06/16 10:03
63F：推 s06yji3: 先澄清我不盲目追求新技术。但是自己造轮子不代表好维护 06/16 11:48
64F：→ s06yji3: ，甚至可能只有你能维护。同样水准的人难找跟是不是用新 06/16 11:48
65F：→ s06yji3: 技术无关。 06/16 11:48
66F：→ bowin: 再次强调"用最新技术才是好"根本是错误思维 06/16 12:17
67F：推 wulouise: 好控制也是只有自己好控制，出问题也只有自己好解 06/16 12:18
68F：推 ku72: 写程式重点是逻辑跟整体程式的掌握度 基於原本架构下造的轮 06/16 12:28
69F：→ ku72: 子 对於团队内的成员 理解一定是更为容易 至於专写没人看的 06/16 12:28
70F：→ ku72: 懂的code的不在讨论内 但使用新技术 一方面是大家都要重新熟 06/16 12:28
71F：→ ku72: 悉 一方面是程式码撰写规范逻辑适应 再者 新技术面对的是广 06/16 12:28
72F：→ ku72: 泛的使用者 所以会很全面的涵括完整方案 但你很可能只要使用 06/16 12:28
73F：→ ku72: 一小部分 然後当有问题时 到底要等修正还是自己维护修改？所 06/16 12:28
74F：→ ku72: 以我还是觉得 用不用新技术是要完整评估 专案当前阶段 以及 06/16 12:28
75F：→ ku72: 使用成本跟自己开发成本後再决定 直接以新技术当最佳解的真 06/16 12:28
76F：→ ku72: 的很恐怖 06/16 12:28
77F：→ superpandal: 所以我才说不乱搞 而且团队要选什麽不是我小咖能够决 06/16 12:36
78F：→ superpandal: 定 如果已有的轮子这麽好用那当有特殊需求的时候上层 06/16 12:38
79F：→ superpandal: 一天到晚推推乐做什麽 然後叫人跑去二次开发更是夸张 06/16 12:39
80F：推 s06yji3: 这边应该没人觉得新技术才是最好的吧0.0 06/16 12:39
81F：→ superpandal: 那不是该只有专案开发者才能维护的吗? 06/16 12:40
82F：→ Hsins: 有些推文把新技术跟版本更新混淆了... 06/16 12:41
83F：→ Hsins: 对於既有技术的版本更新是应该要掌握的，但似乎很多年长的 06/16 12:42
84F：→ Hsins: 开发人员并未意识到这点… 06/16 12:42
85F：推 s06yji3: 所有框架都是面对广泛的使用者。除非你完全自己造轮子。 06/16 13:07
86F：→ s06yji3: 不然你避免不了框架。新技术只是技术选择的一个选项，对 06/16 13:07
87F：→ s06yji3: 於一个新项目而言不管新或旧技术都需要学习的。 06/16 13:07
88F：嘘 Ghamu: 你这样讲完全错误喔～ 新创因为没钱没资源 唯一能跟大公司 06/16 14:51
89F：→ Ghamu: 拼的就是灵活性 透过能快速导入新技术提升整体效率的优势跟 06/16 14:51
90F：→ Ghamu: 大公司一拼 不然你用旧技术 但没钱没人 那你就死掉了 06/16 14:52
91F：嘘 Ghamu: 而老公司因为老产品已经赚钱了 会趋向保守用就技术维持营运 06/16 14:55
92F：→ Ghamu: 也不可能让用老技术的老屁股一夕之间全部使用有效率电新技 06/16 14:56
93F：→ Ghamu: 老公司可能古代人都用email沟通 很多老人觉得这个很严谨 组 06/16 15:04
94F：→ Ghamu: 组织又大人又多 要改要花好几个月 反观新创几只猫 要用 06/16 15:04
95F：→ Ghamu: slack吗？ 好啊 明天就可以用了 而最一开始团队建置就可以 06/16 15:05
96F：→ Ghamu: 找使用新技术的人组成团队 不像老公司很多人不会新的要转换 06/16 15:05
97F：→ Ghamu: 学习 06/16 15:06
98F：→ Ghamu: 说穿 新的技术有9成都是根基於旧技术的改进 不是石头里蹦出 06/16 15:14
99F：→ Ghamu: 来的 都会比旧的技术优秀 06/16 15:15
100F：推 Ghamu: 作为工程师拥抱新技术是一个重要素养 我以肉身撞墙过拥抱旧 06/16 15:16
101F：→ Ghamu: 技术 真的很惨 新公司都用新技术新框架 觉得以前保守求稳定 06/16 15:17
102F：→ Ghamu: 鄙视新技术根本脑残... 06/16 15:18
103F：→ Ghamu: 花了好多时间做出垃圾 新技术又快又好轻松写意 06/16 15:18
104F：→ superpandal: 新技术不一定不好 但很大机会和某些旧技术一样不好 06/16 19:04
105F：→ superpandal: 因为大而全的思想导致 简单又灵活的东西不是没有 只 06/16 19:04
106F：→ superpandal: 是很少人做 可能怕内卷 公司来讲选什麽不一定有机会 06/16 19:06
107F：→ superpandal: 决定 但对个人来讲绝对选简单好用又安全的 三者并不 06/16 19:06
108F：→ superpandal: 是互斥 06/16 19:07
109F：推 hegemon: 我只看到一堆新创整天说灵活性结果连市场上有什麽选择都 06/16 20:18
110F：→ hegemon: 懒得调查，闭门造车结果发现做出一堆市场上已经一堆人实 06/16 20:18
111F：→ hegemon: 作出来的套件 06/16 20:18
112F：→ hegemon: 效能也没比其他好，可维护性趋近於0，还没有经过业界实战 06/16 20:21
113F：→ EricTCartman: hegemon你搞得我好乱 06/16 20:56
114F：→ EricTCartman: 一下批评用新技术炫炮炫技不成熟 06/16 20:57
115F：→ EricTCartman: 一下又说一堆新创闭门造车不看市场上有啥选择 06/16 20:57
116F：→ EricTCartman: 这边新技术是多新？怎麽定义新技术？是从学界角度 06/16 20:58
117F：→ EricTCartman: 来看, 还是看业界有没有被验证过, 还是看名词流行的 06/16 20:59
118F：→ EricTCartman: 年分 06/16 20:59
119F：→ tofuflower: 技术不分新旧，只分能不能解决商业问题赚钱 06/17 00:28
120F：→ tofuflower: 工程师需要的是分析问题和根据手上资源找到适合的工具 06/17 00:28
121F：→ tofuflower: 同样问题不同公司不同流量不同产业 06/17 00:32
122F：→ tofuflower: 解法天差地远，纠结新旧技术真的不是做产品的重点 06/17 00:32
123F：→ waterwalk: 台湾几乎没有真新创吧 看看创世神那家公司 也是被批斗 06/17 00:43
124F：→ waterwalk: 只能说技术人永远都有歧视链 06/17 00:43
125F：推 hegemon: 十年内，或是虽然出来很久，但是鲜少没有在你需求领域被 06/17 01:21
126F：→ hegemon: 广泛使用的都算新吧. 再来不是做技术供应商却对跟商业逻 06/17 01:21
127F：→ hegemon: 辑不相关的部分自干 06/17 01:21
128F：→ Ghamu: 技术有分新旧 能力资源无法用最佳解可以先偏安在次佳解 06/17 15:29
129F：→ Ghamu: 但要持续往新技术去迈进 不然真的会被时代淘汰 06/17 15:29
130F：→ Ghamu: 商业问题赚钱那是营运行销他们要考虑的 工程师应该着重在 06/17 15:30
131F：→ Ghamu: 技术成长上 能用新的就不要用旧的 旧的技术职缺只会越来越 06/17 15:30
132F：→ Ghamu: 来越少 领的钱越来越少 06/17 15:31
133F：→ Ghamu: 为了配合所谓商业考量都用旧的没效率的技术没意义 商业端赚 06/17 15:34
134F：→ Ghamu: 不赚钱不是技术能控制的 技术端就是把自己强化好随时可跳 06/17 15:34
135F：→ Ghamu: 如果你都是在用旧的技术毫无成长 履历上也不好看吧? 06/17 15:35
136F：→ tofuflower: 履历上看的是你解决什麽问题，不是你用什麽工具... 06/17 16:24
137F：→ tofuflower: 甚至会问你为什麽选用什麽工具解决这个问题 06/17 16:25
138F：→ tofuflower: 我是没试过回答技术就是选新的 06/17 16:26
139F：→ tofuflower: 如果面试官问你为什麽选择用某种 DB 06/17 16:28
140F：→ tofuflower: 他会期待你分析业务场景选择，而不是说选新的 NoSQL 06/17 16:29
141F：→ Hsins: 这问题牵扯很广啦，比如像是 COBOL 这种就很解释楼上的问题 06/17 16:54
142F：→ Hsins: 但 jQuery 这种就还是面试官们能接受的 06/17 16:55
143F：→ EricTCartman: 所以每个人对新旧技术定义都不太一样 06/17 19:00
144F：推 s06yji3: 有些JD上会写哪些技术有加分或是preferred XD 06/17 19:58
145F：→ superpandal: 工具有差异 只是很可能最後都是变成一个大怪兽工具而 06/17 20:21
146F：→ superpandal: 已 工具不同思维也都不同 06/17 20:23
147F：→ superpandal: 新旧工具的不同会有不同习惯者以及利益相关 新创都有 06/17 20:28
148F：→ superpandal: 一些考量不代表旧的没考虑 当然分散风险更加好 06/17 20:28
149F：→ superpandal: 只是纯以工程角度来讲 我看到的是everything sucks 06/17 20:37
150F：→ weitin7011: 就骗钱骗员工伎俩 你怎麽那麽老实 06/18 02:53
151F：→ superpandal: 这里讲的是纯技术 像楼上说的NoSQL其实有好处 就是免 06/18 15:02
152F：→ superpandal: 逸sql注入 06/18 15:03
153F：→ superpandal: 免疫 06/18 15:03
154F：→ Hsins: 呃，使用 NoSQL 不代表没有注入问题耶… 06/18 15:20
155F：→ superpandal: NoSQL会被注入除非NoSQL有漏洞或者写的人乱写 06/18 15:35
156F：→ Hsins: 好喔… 06/18 15:45
157F：→ Hsins: 你说的没错，其实关联式资料库会被注入也是因为这个原因呢 06/18 15:48
158F：→ Hsins: ：) 06/18 15:48
159F：→ superpandal: 关联式需要parse querystring nosql定义的好根本没注 06/18 15:57
160F：→ superpandal: 入的可能 当然sql搞一堆事前工作都可以 只是nosql更 06/18 15:58
161F：→ superpandal: 容易免疫 06/18 15:58
162F：→ tofuflower: 但是 NoSQL 在某些场景一样没办法取代 RDBMS 啊 06/18 22:54
163F：→ tofuflower: 重典还是场景，和适合的工具 06/18 22:55
164F：→ superpandal: 这就有点矛盾了 不过功能可以独立出来 06/19 14:22
165F：→ Ghamu: 排斥新技术的人会认为RDBMS是世界上最好的方式 不懂那些新 06/19 22:57
166F：→ Ghamu: 创年轻人搞什麽NoSql 根本在圈钱的 06/19 22:57
167F：→ Ghamu: 不稳定又很少人会 到底要浪费时间去导入他干嘛？ 06/19 22:58
168F：→ Ghamu: 之前吃喜酒一家大公司的工程师说他们用小乌龟SVN用的出神入 06/19 23:02
169F：→ Ghamu: 化 也写了很多自动化工具 他们认为工具不重要 重点是实作出 06/19 23:02
170F：→ Ghamu: 来跟商业逻辑 我跟他讲GIT branching 之类的功能 他把我当 06/19 23:02
171F：→ Ghamu: 成低能儿 一直重复说工具不重要 能实作出来就好 06/19 23:02
172F：→ Ghamu: 说穿大家都是工程师啦 技术这种东西是很实在有一说一 有二 06/19 23:05
173F：→ Ghamu: 说二的 两个技术工具在那 肯定有其好坏优缺点的 说出不重要 06/19 23:05
174F：→ Ghamu: 都可以这种话 我是无法接受 06/19 23:05
175F：→ Ghamu: 现实条件当然不可能百一分之一百理想 每次有资源都能用最佳 06/19 23:07
176F：→ Ghamu: 实践 但我们就是应该知道什麽是对的尽力去做 也谦虚地去了 06/19 23:07
177F：→ Ghamu: 解新技术在讲什麽 而不是因为我会旧的 新的不重要 骗钱的 B 06/19 23:07
178F：→ Ghamu: uzz word 06/19 23:07
179F：→ ssccg: 注入这个问题的根源是把不可信的input当command parse 06/21 02:44
180F：→ ssccg: 跟是RDBMS还是NoSQL一点关系都没有，如果SQL全都是写死的 06/21 02:45
181F：→ ssccg: input只以参数方式传一样不可能有注入问题 06/21 02:47
182F：→ superpandal: SQL随应用情景不会都是写死的 依照规则写好基本上就 06/22 00:39
183F：→ superpandal: 如同NoSQL语言扩充写死一样 06/22 00:40
184F：→ Hsins: 楼上还是拿 AWS Dynamo/Mongo Injection 这些关键字爬一下 06/22 00:51
185F：→ Hsins: 文吧 06/22 00:51
186F：→ superpandal: 这就NoSQL本身的问题 XD 06/22 18:45
187F：→ Hsins: 会有这些注入问题就是 ssccg 大说的，两者差异只是发生位置 06/22 19:16
188F：→ Hsins: 的问题，使用 SQL 容易发生在 SQL statement parsing 阶段 06/22 19:17
189F：→ Hsins: ，而 NoSQL 更惨是会发生在执行阶段。 06/22 19:17
190F：→ Hsins: 除此之外，NoSQL 是 Not Only SQL 而不是完全没有… 06/22 19:17
191F：→ superpandal: 你不容易控制别人怎麽输入 但可以控制你底层的实作 06/23 23:29
192F：→ superpandal: XD 06/23 23:29
193F：推 internetms52: 新技术不是只有优点，很多时候是缺点还没被发现 08/25 07:56