Re: [討論] 怎麼跟自以為是的同事相處

看板Soft_Job作者 (最後的六年級生)時間1年前 (2022/10/27 01:02), 1年前編輯推噓14(14030)
留言44則, 20人參與, 1年前最新討論串7/10 (看更多)
※ 引述《leo5916267 (封膜獵人)》之銘言: : 也許在軟體也蠻容易遇到類似個性的同事 : 我們是新創公司,我進去前已就有一個前端工程師,他從0建構了整個產品A : 我是產品B的前端,剛好我們產品線不急,被拉去支援他們 改版 : 但在合作上就覺得跟他相處很不舒服 : 可能是把我當競爭對手吧? ^^^^^^^^^^^^^^ 不要做這種假設,很多programmer 選擇這行就是因為他們對人技巧不好、但好死不死又 適合寫程式 除非你觀察到產品A一直找不到其他前端,或者新加入的前端離職率很高,否則我們沒有 客觀事實 這種情況下除非你是主管,那你可以用自由心證去決定他對人的態度在公司算不算是 Toxic,但不是的話,那就不要在心裡做這種假設,這很容易雙方相互升級的 : 喜歡用高姿態/批判的方式codereview, : 而我對他提出寫法的意見,才提開頭一句 : 就霹靂啪拉回了十句,順帶挑我程式毛病,我覺得更像是用公事來打壓別人 : 就講不得,而整個團隊都對他很頭痛,但又要依賴他做事情,很多文件需求都沒寫清楚 以上可以舉例嗎?因為敘述裡面都是形容詞,沒有實際案例很難判斷 : ,很多事情都綁在他身上,而且專案架構維護性蠻差的,我看了整整一個月才懂他的 ^^^^^^^^^^^^^^^^^^^^ 新創公司很多時候會這樣,維護性很差在新創公司視情況也不奇怪 : 思路,大概就是小孩子拿AK的感覺 ^^^^^^^^^^^^^^^^ 在你給出一個sample code 之前,這說法有點武斷,而即使code quality 真的很糟, 在某些情境下這也是許可的 我還在台灣的時候,常常一早到公司打開IDE git pull完,會看到在美國的技術主管 或CTO半夜直接commit 進master的Code,他們有時候會改到我正在作業的地方 而這種突然加進來的程式碼,常常是scala寫的串了十幾行一堆map fold zip 的操作, 幾乎不做exception handling、沒有nullity check、沒有logging、變數命名極其糟糕 、完全不寫測試、有許多複製貼上、沒有comment 如果我不講context,大概很多人這時候會覺得這環境很糟、我們技術水平很差在亂搞吧? 但情況是他們常常是在連續十幾個小時的工作後,要硬把一個功能做出來然後馬上demo 給VC 或要好的客戶看,只要happy path 情境會動就上了 而我的工作這時候就是把那段程式碼重構、整理成團隊該有的水平 我會去聯絡前端把系統跑起來看看,確認美國那邊在我們睡覺的時候到底加了什麼功能, 確實搞清楚這段邏輯到底在幹嘛、Slack 上把我認為他在幹嘛寫清楚跟原作者確認,然後 如果有bug、有缺、還是有其他會雞飛狗跳的東西,那就是我那天的工作 這就是我們當時的分工,其實沒有人特別提,但在壓力與刺激下就是自然變成這樣了 : 我們做事不得不都要照的他的方式做事,但他又很自我中心,跟他配合心力大概4成是處理情緒問題4成才是程式問題 : 我網路上找過類似的關鍵字 : 攻擊性強的同事 : 自以為是的同事 : 他的性格滿符合上面相關搜尋找到的描述 : 不知道各位前輩是怎麼應對的 : 我現在是當練EQ,大概還要半年改版完忍忍 : 程式部分就消極應對,我有好的想法就跟別人討論,在他的專案只用他寫過的方式做 我不確定你們的新創公司現在在什麼階段?如果是正在極速衝刺,而他是主力,那或許 你就得像我當年那樣,去做那個看到前鋒衝出去了,就趕快掩護射擊搞火力支援的人 這當然講求默契與互信 也許你可以試看看拿你負責的專案問問他有沒有什麼建議,如果他還是非常刺、然後 很多酸言酸語,那也許他就真的很Toxic,但我們版上的沒有看到實際案例是很難評斷的 -- 在灣區打工的中年外籍碼農,有誰想在台灣組研發團隊做美國市場的,歡迎聊聊 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.194.158.240 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1666803762.A.545.html ※ 編輯: zanyking (123.194.158.240 臺灣), 10/27/2022 01:03:33

10/27 12:40, 1年前 , 1F
聽起來很奇怪... 如果只是要Demo 怎麼會直接commit進mast
10/27 12:40, 1F

10/27 12:40, 1年前 , 2F
er 這CTO跟技術主管是雷吧..
10/27 12:40, 2F

10/27 12:45, 1年前 , 3F
樓上 思路很簡單啊 合併到master手下就一定要去修
10/27 12:45, 3F

10/27 12:46, 1年前 , 4F
當然正常人不會這樣搞XD
10/27 12:46, 4F

10/27 12:47, 1年前 , 5F
好吧... 我要是遇到這種的應該先跑 太可怕了..
10/27 12:47, 5F

10/27 12:47, 1年前 , 6F
比喻成漫畫家與助手就會很合理
10/27 12:47, 6F

10/27 12:48, 1年前 , 7F
寫程式會誤以為要塊陶 但老闆能溝通最重要
10/27 12:48, 7F

10/27 12:48, 1年前 , 8F
最怕寫垃圾還不准重構的
10/27 12:48, 8F

10/27 12:49, 1年前 , 9F
這篇的比較像原型機還沒打磨
10/27 12:49, 9F

10/27 12:50, 1年前 , 10F
肯讓你花時間補測試的老闆就很棒了
10/27 12:50, 10F

10/27 12:50, 1年前 , 11F
滿多??只會把責任丟給QA,然後浪費RD後面的時間
10/27 12:50, 11F

10/27 13:12, 1年前 , 12F
清理那些屎山屎海的代碼真的有些吃力不討好…
10/27 13:12, 12F

10/27 14:48, 1年前 , 13F
不做多餘的假設是對的 但也沒必要因此讓步或客氣
10/27 14:48, 13F

10/27 14:48, 1年前 , 14F
工作十幾個小時硬上功能這不是理由.開分支,demo build,
10/27 14:48, 14F

10/27 14:49, 1年前 , 15F
這都不是很困難的事情.
10/27 14:49, 15F

10/27 14:53, 1年前 , 16F
code 會動就好這在demo 階段可以理解,但連開demo分支都
10/27 14:53, 16F

10/27 14:55, 1年前 , 17F
懶,那我只能說軟工工法都假的,老闆爽才是真的
10/27 14:55, 17F

10/27 15:19, 1年前 , 18F
對公司來說賺錢才是真的,這說法無可厚非啦……
10/27 15:19, 18F

10/27 18:07, 1年前 , 19F
唯一建議,想通老闆的思路會讓你在工作上更順心一點
10/27 18:07, 19F

10/27 18:11, 1年前 , 20F
推一樓~直接進master有點抖...
10/27 18:11, 20F

10/27 18:23, 1年前 , 21F
敢進master表示用的人不多吧
10/27 18:23, 21F

10/27 18:35, 1年前 , 22F
推這篇,以前我也很重視軟工,但當你在更高的角度看,
10/27 18:35, 22F

10/27 18:35, 1年前 , 23F
特別是新創,快速的呈現結果給 stakeholder ,比什麼都
10/27 18:35, 23F

10/27 18:35, 1年前 , 24F
重要
10/27 18:35, 24F

10/27 19:03, 1年前 , 25F
也有可能本來那個就是demo用的repo
10/27 19:03, 25F

10/27 20:13, 1年前 , 26F
即使有context我還是覺得很糟。工作環境也很糟。
10/27 20:13, 26F

10/28 06:39, 1年前 , 27F
新創工作方式本來就很亂,想要安穩就別跟風去新創
10/28 06:39, 27F

10/28 07:54, 1年前 , 28F
push
10/28 07:54, 28F

10/28 08:05, 1年前 , 29F
別說startup,一些agency也是求快,結果code base很亂。
10/28 08:05, 29F

10/28 18:38, 1年前 , 30F
拿新創來當擋箭牌,其實有點想噓
10/28 18:38, 30F

10/28 18:56, 1年前 , 31F
一個可能合理的情形是,要展示 "已經有" 那個功能,所以
10/28 18:56, 31F

10/28 18:57, 1年前 , 32F
要 commit 到 master 佈到正式機上
10/28 18:57, 32F

10/28 18:57, 1年前 , 33F
放到今天看會有其它做法,例如 github action 可以用分
10/28 18:57, 33F

10/28 18:58, 1年前 , 34F
支名稱當條件決定佈署到哪裡,但若是 2015 之前就可理解
10/28 18:58, 34F

10/29 01:30, 1年前 , 35F
對的,時間是2014那時候,現在有更好的做法不需要這樣
10/29 01:30, 35F

10/29 13:53, 1年前 , 36F
奇怪的工作模式
10/29 13:53, 36F

10/29 17:44, 1年前 , 37F
請他們不要進master,開一條demo branch大家都開心
10/29 17:44, 37F

10/29 17:45, 1年前 , 38F
真的覺得那些code很重要的話 在merge master修conflict
10/29 17:45, 38F

10/29 17:45, 1年前 , 39F
修掉以後再回master 或者dev branch
10/29 17:45, 39F

10/30 19:39, 1年前 , 40F
適合不適合寫程式在很多公司是很主觀的看法 別人拿一
10/30 19:39, 40F

10/30 19:41, 1年前 , 41F
些你很不佔優的點來講怎麼講都是對的 我都覺得自己很
10/30 19:41, 41F

10/30 19:42, 1年前 , 42F
平實寫東西儘量考量平衡點都是一種很適合寫程式的表
10/30 19:42, 42F

10/30 19:43, 1年前 , 43F
現 又不會主動刁別人 要講一些不好聽也不會大庭廣眾
10/30 19:43, 43F

10/30 19:43, 1年前 , 44F
10/30 19:43, 44F
文章代碼(AID): #1ZMMWoL5 (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文
完整討論串 (本文為第 7 之 10 篇):
文章代碼(AID): #1ZMMWoL5 (Soft_Job)