remote工作容易被觉得passive aggressive

因为工作和生活缺乏边界吧。

我是把到点下班看做比完成工作更重要的人，在认为完成工作比到点下班更重要的人眼里，我就是工作态度很差。

简而言之，我的东西出了ticket，我把一个dependency的版本升级，merge后就下线了。结果今早起来看了眼，发现昨天下班后的时间另外的code owner和oncall在群里发了很多信息，信息慢慢变得情绪化，指责我没盯着跑得对不对就下线了。

其实我的东西也不是不对，他们就是觉得我做事不负责，code没跑他们直接给revert了。

我以前也经常碰到这种情况，一般的发展都是，卷人对我的印象是我不卷，我也确实是不卷，以后做事，每次卷人都会急，我就按照正常情况给design，eta和risk，无论每天做到哪儿都到点下线。

熟悉我风格的人也知道，我这个人ego极强，就是完全不屑于别人看法，无论对方说什么我都不改变我做事的方法和速度。然后卷人觉得我不接招，是我passive aggressive，对我越来越看不顺眼。

remote工作的工时这种事情吧，让我和卷人的冲突又自然多了一个。

补充内容 (2026-08-22 20:55 +08:00):
. Χ还有一个可能，就是我之前发现那个code owner原来的code有个bug让他去修，也跟老板同步过我的eta，说我只能在他修好后在那之上再做我的部分，他觉得我跟老板给他告状了怀恨在心。

补充内容 (2026-08-23 00:55 +08:00):
我觉得楼下的回复特别对

你不想上这个班就换地方

是的，这就是区别，对于卷人来说，工作是要做好的，东西是不能坏的，坏了是要赶紧修的。而对我这种垃圾来说，oncall让我修就修呗，oncall告诉我可以merge就merge呗，反正你同意了我就觉得你负责，下班时间发生什么，东西坏不坏，亏的是公司的钱，跟我有什么关系，下个工作日再说。

对的，这就是exactly的区别。我“不想上这个班”。

补充内容 (2026-08-23 01:08 +08:00):
当然我也没说楼下不好，只是我真的懒得管那么多。

很简单，我不是oncall，oncall发现了一个东西，要我赶紧修。不修吧，被人家明确让现在就干；修吧，再跑完都要几小时。最好的办法，当然是修好了然后在那等几小时看看有没有问题，但是，我才不干。

另外，我这个bug甚至是人家own的dependency有问题，新升级的给修了，我把这边的代码link到他们的新version。但是我觉得这不是主要矛盾，就算是我做出bug，或者任何一个人做出bug，我都觉得是系统不够好让人有了出bug的机会，这是个优化系统的机会，而不是出bug的人或者审代码没发现bug的人的问题。是的，我没有ownership，我“不想上这个班“，就是这么回事。

补充内容 (2026-08-23 01:11 +08:00):
至于下班前如果不盯代码就不该merge代码这回事，如果是我自己做，当然如此，上了几年班也不至于没这点common sense。
如果是oncall跟我说紧急，让我做的，approve了我的PR让我merge的，那随他去了，我才无所谓。至于我这么做是不是意味着我下班就要盯，就是回到原来的问题，我是把到点下班看做比完成工作更重要的人，他是完成工作比到点下班更重要的人，我不管了。

补充内容 (2026-08-23 01:13 +08:00):
然后，不要去找我现实中是谁，说不定我很快就要默默去祸祸下个公司了呢哈哈，帮我保密。
. ----
补充内容 (2026-08-23 01:43 +08:00):
还有个问题，是愿不愿意和我这种人做同事，这也是区别，我还挺愿意和我这种人做同事。我如果发现这个问题，根本就不会催着人家下班之前赶紧修，你知道就好，哪怕影响了产品，我也让人家自己决定什么时候修好，我通知到了就行，哪怕影响了我的进度我也觉得通知到了老板就行，我才不想催人家修东西，我也觉得人家需要下班，公司东西坏了就坏了——除非impact巨大或者彻底崩了。

remote工作，最重要的是建立trust，一开始的任务得表现的非常负责，非常上心。
如果一开始的trust没有建立起来，后面碰到这种事情就说不清。
扪心自问，如果你是老板，请一个remote 工作的人，最怕的是不是需要他的时候他 找不到他？
既然remote work，就得先刷availability的存在感。
建立起这种trust以后就算再碰到这种扯不清的事情，老板同事心里也会默认先认为，你是一个心里优先级别清楚，做事有章法的人，就算偶尔不在，肯定也是因为重要的事情都盯完了，而你miss掉的肯定都是些无关紧要的事情。
如果remote做不到这一点，还不如去公司打卡坐班。
. 1point 3 acres从这点来说，我觉得back to office没啥不好，特别如果还有食堂的话

以防地里真的有年轻刚毕业的小朋友不懂的：
周五不要deploy一些重大feature；
下班之前一两小时也不要跑复杂或者可能影响到sibling team的pipeline，任何需要长久monitor的workflow
如果真的很紧急，在team channel里面各种ping一下。。这些真的都是非常基本的常识了🙏

不准备下班时间看班上的信息的话 就别在下班之前做这种有可能耽误别人做事的事 或有impact 比较critical的事。你不想上这个班就换地方

看力竭了，下班前把线上搞崩美其名曰到点下班，还别人觉得你passive aggresive。我是你同事擦一次屁股算我倒霉，如果屡教不改，绝对得escalate了。不要把无知当个性，ego不是啥好事。

补充内容 (2026-08-23 03:25 +08:00):
看了更多楼主的补充触目惊心，bq轮实在是太重要了

有些事得拖到别人上班时间做吧。

支持！继续做自己最重要

人菜到连测试都不会就别给自己美化了

根本跟是不是remote，到点下不下线无关。也跟passive aggressive半毛钱关系都没有。你给的例子就是非常没有工作经验的人才会干出来的事。但凡有半年以上的工作经验还merge了code不monitor我都会黑人问号。你要下班那就下个工作日早上再merge啊，谁会说什么？你的这些说来说去最多算没有ownership吧

好多回复都没搞清楚状况。op的代码出了线上bug，op做了bug fix merge完代码就下线了。op不是下班前merge了一个feature，而是生产事故fix。
我觉得oncall和另一个code owner revert代码说明他们要么看不懂这个fix，要么发现这个fix有问题。这期间想和op讨论发现人不在，热锅上蚂蚁的他们生气太正常了。
总之如果我是涉事同事是一定会在1:1上和manager反应情况的，不能等下次出大事再后悔。
看到op补充说怀疑那同事可能是打击报复，我只能说幸好不是我的同事。

匿名用户 发表于 2026-08-22 08:28:05
好多回复都没搞清楚状况。op的代码出了线上bug，op做了bug fix merge完代码就下线了。op不是下班前merge了一个feature，而是生产事故f

不管是merge新feature还是fix bug都一样啊，merge bug fix不管直接下线也不看是不是修好了反而是更大的雷吧