Re: [討論] 對技術沒熱情是不是不適合這行？

看板Soft_Job作者 (版主請投我一票!)時間1年前 (2022/06/15 15:04), 1年前編輯推噓20(23推 3噓 166→)
留言192則, 23人參與, 1年前最新討論串3/10 (看更多)
新創最愛用「新技術」 能賺錢 好用 穩定 為什麼要用新技術？ 那是因為 舊技術賺錢的公司都在前面 你拿舊技術怎麼跟前面比 當然要拿新技術才能要到錢 穩定 快速上線 才是王道 新技術能活下去的沒幾個 因為出問題 找不到人家解 除非技術是自己創新研發 不是網路上挖來研究的 ※ 引述《PRCXi (中華人民共和國主席)》之銘言： : 小弟文組資策會轉職仔，入行剛滿六年 : 前五年靠著學校名字進了兩間知名大公司，今年初跳槽到一間新創 : 在前兩間公司的時候步調比較慢，而且教學文件非常完整，甚至還教學有影片 : 而使用的技術也是5~10年前左右的那種，遇到問題、BUG網路都一大票資料 : 這五年來也過得沒什麼壓力，我也自認為自己技術有一直在成長 : 至少在公司裡的程式問題除了MIS、SRE那方面的我都能應付、解決 : 今年初到了現在這間新創後，整個步調都超級快 : 除了新人蜜月期兩週外每天都是超高壓的工作環境 : 除了CTO、TL都要求大家走最新的框架外，程式架構也是我之前都沒碰過的 : 因為不熟，每天的進度報告我都是進度落後的那個 : 之後我開始用下班時間看技術文件，自己嘗試跟著實作，每天弄到12點多 : 兩個多月過去了，我開始發現自己好像不太喜歡這種東西 : 看技術文件也常常五分鐘後就開始覺得無聊、不想看，完全沒有在前公司學習的那種感 覺 : 前天跟主管一對一談話中，主管也說他感覺不到我對技術的熱忱 : 覺得我是一個比較被動接受的人，要我考慮一下往後的職涯想怎麼走 : 加上昨天聽到前同事在說，前公司新進來的新人說我當初留下的扣很爛，想全部翻掉 : 讓我更加覺得自己的技術很爛，前五年好像都是自我感覺良好 : 想請問各位大大，我現在入行六年還沒破百(目前年薪9X) : 技術差加上對技術沒熱情，是不是真的轉行比較好？ : 謝謝各位的回覆！！ 我會考慮找自己適合的公司or銀行IT試試看 : 另外補充說明一下 : 會有轉行念頭的最大原因是前天跟主管的對談 : 主管提到對技術沒有熱忱很難在這行走得遠，加上我算大齡(31)又有一些年資 : 不能一直待在junior的位置，要想往後升上去絕對避不開自己鑽研新技術 : 他說如果真的沒興趣就要好好想想職涯未來的規劃 : 聽完之後我是真的很迷惘，才會有該不該及早停損的念頭 : 再加上又聽到自己之前的扣被嫌成像一坨屎，算是最後一根稻草吧 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 37.19.205.185 (日本) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1655276682.A.EE8.html
推
06/15 15:32, 1年前 , 1F
推
06/15 15:32, 1F
推
06/15 15:36, 1年前 , 2F
推 要夠炫炮才能騙到創投
06/15 15:36, 2F
→
06/15 15:52, 1年前 , 3F
有的時候能拿到創投就是成功
06/15 15:52, 3F
推
06/15 16:28, 1年前 , 4F
現在資金緊縮，用最小的成本把東西開出來讓人買單比什麼
06/15 16:28, 4F
→
06/15 16:28, 1年前 , 5F
都重要，要炫砲的話自己去community，不要拿全體投資人跟
06/15 16:28, 5F
→
06/15 16:28, 1年前 , 6F
員工去陪你炫
06/15 16:28, 6F
推
06/15 16:51, 1年前 , 7F
確實
06/15 16:51, 7F
→
06/15 17:24, 1年前 , 8F
賺不賺錢應該是商業模式。新舊技術大多是工程師的偏好而
06/15 17:24, 8F
推
06/15 17:56, 1年前 , 9F
雀食
06/15 17:56, 9F
→
06/15 19:24, 1年前 , 10F
新舊技術是工程師的偏好，跟公司獲利無關
06/15 19:24, 10F
推
06/15 19:28, 1年前 , 11F
會有新的技術多半是為了解決某些問題，但隨著迭代過程，可能
06/15 19:28, 11F
→
06/15 19:28, 1年前 , 12F
被淘汰
06/15 19:28, 12F
新技術只能找兩個人 舊技術能找到十個人 成品都一樣 使用者UX也感覺不出技術差異 為什麼一定要新技術 況且新技術擁有者如果離職 後面維護成本更高 ※ 編輯: chengcti (37.19.205.185 日本), 06/15/2022 20:19:54
推
06/15 20:57, 1年前 , 13F
所以說跟公司賺不賺錢沒有差。有些系統舊的技術就是不好
06/15 20:57, 13F
→
06/15 20:57, 1年前 , 14F
用，那當然用新的0.0
06/15 20:57, 14F
→
06/15 22:03, 1年前 , 15F
新技術就是解決或改善舊技術問題 用舊技術會越來越少
06/15 22:03, 15F
噓
06/15 22:50, 1年前 , 16F
如果自己搞不成熟的新東西炫砲導致之後維護困難+找不到人
06/15 22:50, 16F
→
06/15 22:50, 1年前 , 17F
，這樣就得不償失
06/15 22:50, 17F
→
06/15 23:42, 1年前 , 18F
新技術會出現是因為舊技術在某些場景有局限
06/15 23:42, 18F
→
06/15 23:43, 1年前 , 19F
但不代表新技術能取代舊技術表現良好的場景
06/15 23:43, 19F
→
06/15 23:45, 1年前 , 20F
重點是先搞清楚問題 (why)，然後是怎麼解決 (how)
06/15 23:45, 20F
→
06/15 23:45, 1年前 , 21F
最後才是用什麼技術解決 (what)
06/15 23:45, 21F
→
06/15 23:46, 1年前 , 22F
java 沒有取代 C/C++，node / python / golang
06/15 23:46, 22F
→
06/15 23:47, 1年前 , 23F
也沒取代 java
06/15 23:47, 23F
推
06/15 23:54, 1年前 , 24F
有時候也覺得 很奇怪 明明舊有的語言 架構也能解決問題 但卻
06/15 23:54, 24F
→
06/15 23:54, 1年前 , 25F
硬要導入新的語言框架的人 除了滿足自己的技術癖外 還能有啥
06/15 23:54, 25F
→
06/15 23:54, 1年前 , 26F
好處……
06/15 23:54, 26F
→
06/15 23:55, 1年前 , 27F
履歷好看的好處啊 顆顆
06/15 23:55, 27F
→
06/15 23:57, 1年前 , 28F
啊 還有個情況，已經沒在維護更新的舊技術的確該淘汰
06/15 23:57, 28F
→
06/16 00:03, 1年前 , 29F
然後一堆人說用新技術是為了填補舊技術的缺少 老實說 我從改
06/16 00:03, 29F
→
06/16 00:03, 1年前 , 30F
機器碼 組合語言 C／C++ 一路玩到PHP GO C# 這些高階語言 還
06/16 00:03, 30F
→
06/16 00:03, 1年前 , 31F
真的沒有用C/C++刻不出來的功能跟框架 我的認知新語言技術其
06/16 00:03, 31F
→
06/16 00:03, 1年前 , 32F
實很大一部分是讓後入者也能快速進
06/16 00:03, 32F
→
06/16 00:03, 1年前 , 33F
入實現功能而已 對於有現有框架的應該優先再框架內解決問題
06/16 00:03, 33F
→
06/16 00:03, 1年前 , 34F
不能就自己擴展 再不行才會是導入新架構技術 幾年前有個不大
06/16 00:03, 34F
→
06/16 00:03, 1年前 , 35F
專案一共用了5種語言 3種數據庫 再加上zookeeper Kafka 一整
06/16 00:03, 35F
→
06/16 00:03, 1年前 , 36F
個挑戰團隊成員的天份 反正我走後沒聽過有後面的人可以跟我
06/16 00:03, 36F
→
06/16 00:03, 1年前 , 37F
一樣和這個主管一起這樣玩的… 但我真的覺得這樣很無聊……
06/16 00:03, 37F
→
06/16 00:11, 1年前 , 38F
在什麼時候導入新技術也是門學問，需要點實務歷練
06/16 00:11, 38F
還有 114 則推文
→
06/18 15:03, 1年前 , 153F
免疫
06/18 15:03, 153F
→
06/18 15:20, 1年前 , 154F
呃，使用 NoSQL 不代表沒有注入問題耶…
06/18 15:20, 154F
→
06/18 15:35, 1年前 , 155F
NoSQL會被注入除非NoSQL有漏洞或者寫的人亂寫
06/18 15:35, 155F
→
06/18 15:45, 1年前 , 156F
好喔…
06/18 15:45, 156F
→
06/18 15:48, 1年前 , 157F
你說的沒錯，其實關聯式資料庫會被注入也是因為這個原因呢
06/18 15:48, 157F
→
06/18 15:48, 1年前 , 158F
：)
06/18 15:48, 158F
→
06/18 15:57, 1年前 , 159F
關聯式需要parse querystring nosql定義的好根本沒注
06/18 15:57, 159F
→
06/18 15:58, 1年前 , 160F
入的可能 當然sql搞一堆事前工作都可以 只是nosql更
06/18 15:58, 160F
→
06/18 15:58, 1年前 , 161F
容易免疫
06/18 15:58, 161F
→
06/18 22:54, 1年前 , 162F
但是 NoSQL 在某些場景一樣沒辦法取代 RDBMS 啊
06/18 22:54, 162F
→
06/18 22:55, 1年前 , 163F
重典還是場景，和適合的工具
06/18 22:55, 163F
→
06/19 14:22, 1年前 , 164F
這就有點矛盾了 不過功能可以獨立出來
06/19 14:22, 164F
→
06/19 22:57, 1年前 , 165F
排斥新技術的人會認為RDBMS是世界上最好的方式 不懂那些新
06/19 22:57, 165F
→
06/19 22:57, 1年前 , 166F
創年輕人搞什麼NoSql 根本在圈錢的
06/19 22:57, 166F
→
06/19 22:58, 1年前 , 167F
不穩定又很少人會 到底要浪費時間去導入他幹嘛？
06/19 22:58, 167F
→
06/19 23:02, 1年前 , 168F
之前吃喜酒一家大公司的工程師說他們用小烏龜SVN用的出神入
06/19 23:02, 168F
→
06/19 23:02, 1年前 , 169F
化 也寫了很多自動化工具 他們認為工具不重要 重點是實作出
06/19 23:02, 169F
→
06/19 23:02, 1年前 , 170F
來跟商業邏輯 我跟他講GIT branching 之類的功能 他把我當
06/19 23:02, 170F
→
06/19 23:02, 1年前 , 171F
成低能兒 一直重複說工具不重要 能實作出來就好
06/19 23:02, 171F
→
06/19 23:05, 1年前 , 172F
說穿大家都是工程師啦 技術這種東西是很實在有一說一 有二
06/19 23:05, 172F
→
06/19 23:05, 1年前 , 173F
說二的 兩個技術工具在那 肯定有其好壞優缺點的 說出不重要
06/19 23:05, 173F
→
06/19 23:05, 1年前 , 174F
都可以這種話 我是無法接受
06/19 23:05, 174F
→
06/19 23:07, 1年前 , 175F
現實條件當然不可能百一分之一百理想 每次有資源都能用最佳
06/19 23:07, 175F
→
06/19 23:07, 1年前 , 176F
實踐 但我們就是應該知道什麼是對的盡力去做 也謙虛地去了
06/19 23:07, 176F
→
06/19 23:07, 1年前 , 177F
解新技術在講什麼 而不是因為我會舊的 新的不重要 騙錢的 B
06/19 23:07, 177F
→
06/19 23:07, 1年前 , 178F
uzz word
06/19 23:07, 178F
→
06/21 02:44, 1年前 , 179F
注入這個問題的根源是把不可信的input當command parse
06/21 02:44, 179F
→
06/21 02:45, 1年前 , 180F
跟是RDBMS還是NoSQL一點關係都沒有，如果SQL全都是寫死的
06/21 02:45, 180F
→
06/21 02:47, 1年前 , 181F
input只以參數方式傳一樣不可能有注入問題
06/21 02:47, 181F
→
06/22 00:39, 1年前 , 182F
SQL隨應用情景不會都是寫死的 依照規則寫好基本上就
06/22 00:39, 182F
→
06/22 00:40, 1年前 , 183F
如同NoSQL語言擴充寫死一樣
06/22 00:40, 183F
→
06/22 00:51, 1年前 , 184F
樓上還是拿 AWS Dynamo/Mongo Injection 這些關鍵字爬一下
06/22 00:51, 184F
→
06/22 00:51, 1年前 , 185F
文吧
06/22 00:51, 185F
→
06/22 18:45, 1年前 , 186F
這就NoSQL本身的問題 XD
06/22 18:45, 186F
→
06/22 19:16, 1年前 , 187F
會有這些注入問題就是 ssccg 大說的，兩者差異只是發生位置
06/22 19:16, 187F
→
06/22 19:17, 1年前 , 188F
的問題，使用 SQL 容易發生在 SQL statement parsing 階段
06/22 19:17, 188F
→
06/22 19:17, 1年前 , 189F
，而 NoSQL 更慘是會發生在執行階段。
06/22 19:17, 189F
→
06/22 19:17, 1年前 , 190F
除此之外，NoSQL 是 Not Only SQL 而不是完全沒有…
06/22 19:17, 190F
→
06/23 23:29, 1年前 , 191F
你不容易控制別人怎麼輸入 但可以控制你底層的實作
06/23 23:29, 191F
→
06/23 23:29, 1年前 , 192F
XD
06/23 23:29, 192F
‣ 更多 chengcti 的文章
文章代碼(AID): #1YgOIAxe (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 3 之 10 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共10篇)
‣ 更多 chengcti 的文章
文章代碼(AID): #1YgOIAxe (Soft_Job)