Re: [讨论] 怎么跟自以为是的同事相处

楼主: zanyking (最后的六年级生)   2022-10-27 01:02:31
※ 引述《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,但我们版上的没有看到实际案例是很难评断的
作者: baobomb (baobomb)   2022-10-27 12:40:00
听起来很奇怪... 如果只是要Demo 怎么会直接commit进master 这CTO跟技术主管是雷吧..
作者: MoonCode (MoonCode)   2022-10-27 12:45:00
楼上 思路很简单啊 合并到master手下就一定要去修当然正常人不会这样搞XD
作者: baobomb (baobomb)   2022-10-27 12:47:00
好吧... 我要是遇到这种的应该先跑 太可怕了..
作者: longlongint (华哥尔)   2022-10-27 12:47:00
比喻成漫画家与助手就会很合理写程式会误以为要块陶 但老板能沟通最重要最怕写垃圾还不准重构的这篇的比较像原型机还没打磨肯让你花时间补测试的老板就很棒了满多??只会把责任丢给QA,然后浪费RD后面的时间
作者: jobintan (Robin Artemstein)   2022-10-27 13:12:00
清理那些屎山屎海的代码真的有些吃力不讨好…
作者: Ekmund (是一只小叔)   2022-10-27 14:48:00
不做多余的假设是对的 但也没必要因此让步或客气
作者: leolarrel (真.粽子无双)   2022-10-27 14:48:00
工作十几个小时硬上功能这不是理由.开分支,demo build,这都不是很困难的事情.code 会动就好这在demo 阶段可以理解,但连开demo分支都懒,那我只能说软工工法都假的,老板爽才是真的
作者: Hsins (翔)   2022-10-27 15:19:00
对公司来说赚钱才是真的,这说法无可厚非啦……
作者: moom50302 (武林三羚鳄)   2022-10-27 18:07:00
唯一建议,想通老板的思路会让你在工作上更顺心一点
作者: viper9709 (阿达)   2022-10-27 18:11:00
推一楼~直接进master有点抖...
作者: wulouise (在线上!=在电脑前)   2022-10-27 18:23:00
敢进master表示用的人不多吧
作者: f496328mm (为什么会流泪)   2022-10-27 18:35:00
推这篇,以前我也很重视软工,但当你在更高的角度看,特别是新创,快速的呈现结果给 stakeholder ,比什么都重要
作者: Belieeve (芥末拿铁)   2022-10-27 19:03:00
也有可能本来那个就是demo用的repo
作者: s06yji3 (阿南)   2022-10-27 20:13:00
即使有context我还是觉得很糟。工作环境也很糟。
作者: gundamdx (真飞鸟)   2022-10-28 06:39:00
新创工作方式本来就很乱,想要安稳就别跟风去新创
作者: cplusplus426 (c++)   2022-10-28 07:54:00
push
作者: jobintan (Robin Artemstein)   2022-10-28 08:05:00
别说startup,一些agency也是求快,结果code base很乱。
作者: s06yji3 (阿南)   2022-10-28 18:38:00
拿新创来当挡箭牌,其实有点想嘘
作者: lovdkkkk (dk)   2022-10-28 18:56:00
一个可能合理的情形是,要展示 "已经有" 那个功能,所以要 commit 到 master 布到正式机上放到今天看会有其它做法,例如 github action 可以用分支名称当条件决定布署到哪里,但若是 2015 之前就可理解
楼主: zanyking (最后的六年级生)   2022-10-29 01:30:00
对的,时间是2014那时候,现在有更好的做法不需要这样
作者: giantwinter   2022-10-29 13:53:00
奇怪的工作模式
作者: Killercat (杀人猫™)   2022-10-29 17:44:00
请他们不要进master,开一条demo branch大家都开心真的觉得那些code很重要的话 在merge master修conflict修掉以后再回master 或者dev branch
作者: superpandal   2022-10-30 19:39:00
适合不适合写程式在很多公司是很主观的看法 别人拿一些你很不占优的点来讲怎么讲都是对的 我都觉得自己很平实写东西尽量考量平衡点都是一种很适合写程式的表现 又不会主动刁别人 要讲一些不好听也不会大庭广众下
作者: jones2011 (σ゚▽゚)σ)   2022-10-31 20:11:00
直接进master根本是恶搞团队啊,除非是Boss开口要做
作者: loadingN (sarsaparilla)   2022-11-01 21:01:00
branch name 叫 master 可以啦我觉得这篇跟前面几篇都说得很好,公司请你来重点就是解决问题,方法是为了让人更顺利的解决问题,如果本末倒置这样才叫做自以为是
作者: tw11509 (John-117)   2022-11-02 08:53:00
至少可以重构
作者: Awenwen (初心者)   2022-11-09 00:13:00
不懂为什么只是赶demo却不分支去减少风险跟不必要的后续人力成本,硬进master与赶demo code分明是两件事
作者: overhead (overhead)   2022-11-10 01:55:00
这篇的主管做法很可议,但非常欣赏原po找到自己的定位,主动去帮团队cover的精神!

Links booklink

Contact Us: admin [ a t ] ucptt.com