作者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/m.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