作者zanyking (最後的六年级生)
看板Soft_Job
标题Re: [讨论] 怎麽跟自以为是的同事相处
时间Thu Oct 27 01:02:31 2022
※ 引述《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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1666803762.A.545.html
※ 编辑: zanyking (123.194.158.240 台湾), 10/27/2022 01:03:33
1F：推 baobomb: 听起来很奇怪... 如果只是要Demo 怎麽会直接commit进mast 10/27 12:40
2F：→ baobomb: er 这CTO跟技术主管是雷吧.. 10/27 12:40
3F：推 MoonCode: 楼上 思路很简单啊 合并到master手下就一定要去修 10/27 12:45
4F：→ MoonCode: 当然正常人不会这样搞XD 10/27 12:46
5F：推 baobomb: 好吧... 我要是遇到这种的应该先跑 太可怕了.. 10/27 12:47
6F：→ longlongint: 比喻成漫画家与助手就会很合理 10/27 12:47
7F：→ longlongint: 写程式会误以为要块陶 但老板能沟通最重要 10/27 12:48
8F：→ longlongint: 最怕写垃圾还不准重构的 10/27 12:48
9F：→ longlongint: 这篇的比较像原型机还没打磨 10/27 12:49
10F：→ longlongint: 肯让你花时间补测试的老板就很棒了 10/27 12:50
11F：→ longlongint: 满多??只会把责任丢给QA，然後浪费RD後面的时间 10/27 12:50
12F：推 jobintan: 清理那些屎山屎海的代码真的有些吃力不讨好… 10/27 13:12
13F：→ Ekmund: 不做多余的假设是对的 但也没必要因此让步或客气 10/27 14:48
14F：→ leolarrel: 工作十几个小时硬上功能这不是理由.开分支,demo build, 10/27 14:48
15F：→ leolarrel: 这都不是很困难的事情. 10/27 14:49
16F：→ leolarrel: code 会动就好这在demo 阶段可以理解,但连开demo分支都 10/27 14:53
17F：→ leolarrel: 懒,那我只能说软工工法都假的,老板爽才是真的 10/27 14:55
18F：推 Hsins: 对公司来说赚钱才是真的，这说法无可厚非啦…… 10/27 15:19
19F：→ moom50302: 唯一建议，想通老板的思路会让你在工作上更顺心一点 10/27 18:07
20F：→ viper9709: 推一楼~直接进master有点抖... 10/27 18:11
21F：推 wulouise: 敢进master表示用的人不多吧 10/27 18:23
22F：推 f496328mm: 推这篇，以前我也很重视软工，但当你在更高的角度看， 10/27 18:35
23F：→ f496328mm: 特别是新创，快速的呈现结果给 stakeholder ，比什麽都 10/27 18:35
24F：→ f496328mm: 重要 10/27 18:35
25F：推 Belieeve: 也有可能本来那个就是demo用的repo 10/27 19:03
26F：推 s06yji3: 即使有context我还是觉得很糟。工作环境也很糟。 10/27 20:13
27F：推 gundamdx: 新创工作方式本来就很乱，想要安稳就别跟风去新创 10/28 06:39
28F：推 cplusplus426: push 10/28 07:54
29F：推 jobintan: 别说startup，一些agency也是求快，结果code base很乱。 10/28 08:05
30F：→ s06yji3: 拿新创来当挡箭牌，其实有点想嘘 10/28 18:38
31F：推 lovdkkkk: 一个可能合理的情形是，要展示 "已经有" 那个功能，所以 10/28 18:56
32F：→ lovdkkkk: 要 commit 到 master 布到正式机上 10/28 18:57
33F：→ lovdkkkk: 放到今天看会有其它做法，例如 github action 可以用分 10/28 18:57
34F：→ lovdkkkk: 支名称当条件决定布署到哪里，但若是 2015 之前就可理解 10/28 18:58
35F：→ zanyking: 对的，时间是2014那时候，现在有更好的做法不需要这样 10/29 01:30
36F：推 giantwinter: 奇怪的工作模式 10/29 13:53
37F：→ Killercat: 请他们不要进master，开一条demo branch大家都开心 10/29 17:44
38F：→ Killercat: 真的觉得那些code很重要的话 在merge master修conflict 10/29 17:45
39F：→ Killercat: 修掉以後再回master 或者dev branch 10/29 17:45
40F：→ superpandal: 适合不适合写程式在很多公司是很主观的看法 别人拿一 10/30 19:39
41F：→ superpandal: 些你很不占优的点来讲怎麽讲都是对的 我都觉得自己很 10/30 19:41
42F：→ superpandal: 平实写东西尽量考量平衡点都是一种很适合写程式的表 10/30 19:42
43F：→ superpandal: 现 又不会主动刁别人 要讲一些不好听也不会大庭广众 10/30 19:43
44F：→ superpandal: 下 10/30 19:43
45F：→ jones2011: 直接进master根本是恶搞团队啊，除非是Boss开口要做 10/31 20:11
46F：→ loadingN: branch name 叫 master 可以啦 11/01 21:01
47F：推 loadingN: 我觉得这篇跟前面几篇都说得很好，公司请你来重点就是解 11/01 21:04
48F：→ loadingN: 决问题，方法是为了让人更顺利的解决问题，如果本末倒置 11/01 21:04
49F：→ loadingN: 这样才叫做自以为是 11/01 21:05
50F：推 tw11509: 至少可以重构 11/02 08:53
51F：→ Awenwen: 不懂为什麽只是赶demo却不分支去减少风险跟不必要 11/09 00:13
52F：→ Awenwen: 的後续人力成本 11/09 00:13
53F：→ Awenwen: ，硬进master与赶demo code分明是两件事 11/09 00:13
54F：推 overhead: 这篇的主管做法很可议，但非常欣赏原po找到自己的定位 11/10 01:55
55F：→ overhead: ，主动去帮团队cover的精神! 11/10 01:55