PTT推薦

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

看板Soft_Job標題Re: [討論] 怎麼跟自以為是的同事相處作者
zanyking
(最後的六年級生)
時間推噓17 推:17 噓:0 →:38

※ 引述《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留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.194.158.240 (臺灣)
PTT 網址
※ 編輯: zanyking (123.194.158.240 臺灣), 10/27/2022 01:03:33

baobomb10/27 12:40聽起來很奇怪... 如果只是要Demo 怎麼會直接commit進mast

baobomb10/27 12:40er 這CTO跟技術主管是雷吧..

MoonCode10/27 12:45樓上 思路很簡單啊 合併到master手下就一定要去修

MoonCode10/27 12:46當然正常人不會這樣搞XD

baobomb10/27 12:47好吧... 我要是遇到這種的應該先跑 太可怕了..

longlongint10/27 12:47比喻成漫畫家與助手就會很合理

longlongint10/27 12:48寫程式會誤以為要塊陶 但老闆能溝通最重要

longlongint10/27 12:48最怕寫垃圾還不准重構的

longlongint10/27 12:49這篇的比較像原型機還沒打磨

longlongint10/27 12:50肯讓你花時間補測試的老闆就很棒了

longlongint10/27 12:50滿多??只會把責任丟給QA,然後浪費RD後面的時間

jobintan10/27 13:12清理那些屎山屎海的代碼真的有些吃力不討好…

Ekmund10/27 14:48不做多餘的假設是對的 但也沒必要因此讓步或客氣

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

leolarrel10/27 14:49這都不是很困難的事情.

leolarrel10/27 14:53code 會動就好這在demo 階段可以理解,但連開demo分支都

leolarrel10/27 14:55懶,那我只能說軟工工法都假的,老闆爽才是真的

Hsins10/27 15:19對公司來說賺錢才是真的,這說法無可厚非啦……

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

viper970910/27 18:11推一樓~直接進master有點抖...

wulouise10/27 18:23敢進master表示用的人不多吧

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

f496328mm10/27 18:35特別是新創,快速的呈現結果給 stakeholder ,比什麼都

f496328mm10/27 18:35重要

Belieeve10/27 19:03也有可能本來那個就是demo用的repo

s06yji310/27 20:13即使有context我還是覺得很糟。工作環境也很糟。

gundamdx10/28 06:39新創工作方式本來就很亂,想要安穩就別跟風去新創

cplusplus42610/28 07:54push

jobintan10/28 08:05別說startup,一些agency也是求快,結果code base很亂。

s06yji310/28 18:38拿新創來當擋箭牌,其實有點想噓

lovdkkkk10/28 18:56一個可能合理的情形是,要展示 "已經有" 那個功能,所以

lovdkkkk10/28 18:57要 commit 到 master 佈到正式機上

lovdkkkk10/28 18:57放到今天看會有其它做法,例如 github action 可以用分

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

zanyking10/29 01:30對的,時間是2014那時候,現在有更好的做法不需要這樣

giantwinter10/29 13:53奇怪的工作模式

Killercat10/29 17:44請他們不要進master,開一條demo branch大家都開心

Killercat10/29 17:45真的覺得那些code很重要的話 在merge master修conflict

Killercat10/29 17:45修掉以後再回master 或者dev branch

superpandal10/30 19:39適合不適合寫程式在很多公司是很主觀的看法 別人拿一

superpandal10/30 19:41些你很不佔優的點來講怎麼講都是對的 我都覺得自己很

superpandal10/30 19:42平實寫東西儘量考量平衡點都是一種很適合寫程式的表

superpandal10/30 19:43現 又不會主動刁別人 要講一些不好聽也不會大庭廣眾

superpandal10/30 19:43

jones201110/31 20:11直接進master根本是惡搞團隊啊,除非是Boss開口要做

loadingN11/01 21:01branch name 叫 master 可以啦

loadingN11/01 21:04我覺得這篇跟前面幾篇都說得很好,公司請你來重點就是解

loadingN11/01 21:04決問題,方法是為了讓人更順利的解決問題,如果本末倒置

loadingN11/01 21:05這樣才叫做自以為是

tw1150911/02 08:53至少可以重構

Awenwen11/09 00:13不懂為什麼只是趕demo卻不分支去減少風險跟不必要

Awenwen11/09 00:13的後續人力成本

Awenwen11/09 00:13,硬進master與趕demo code分明是兩件事

overhead11/10 01:55這篇的主管做法很可議,但非常欣賞原po找到自己的定位

overhead11/10 01:55,主動去幫團隊cover的精神!