职场潜规则:问问题

想问一下在别人的文档/PR底下leave comments 是不礼貌的行为吗？

背景: 楼主新加入了一个大厂。之前在Startup工作过几年。
之前养成的习惯是经常是问问题，不是那种在Google能轻易搜到的问题。由于经常wear multi hats, 做的东西涉及到multi domain. 我的体会是问问题是最快进步的方式。

不过最近有个同级同事好像不允许我在TA的design doc 跟PR下comments。举例就是我问一个问题，TA直接就close或者resolve了。主要不是一次两次，所以我就有点疑惑。

为了避免被喷，楼主没有预设立场，只是表达困惑而已。

1.  大厂之间的peer是有competition关系吗？所以不欢迎其他人。我一直以来的价值观是同个team 的人应该有共同的mission。是我太天真了吗？

2. 怎么Resolved conflict. 我打算以后走Manager track 对于这一类conflict怎么有艺术地处理。

是你这个同事有病

匿名用户 发表于 2022-06-27 23:48:38
这个有点道理。
谢谢，没有想到这一点。

吹毛求疵一下，我不知道是不是你说话的习惯问题，你可以把'有点道理'改成'有道理'，把点去掉，你也不会掉一斤肉但是可以避免惹到一些敏感的人。我不知道你在回复别人doc里面是不是不经意间也会用到类似修辞，在美国，fine is not good, good is not good enough...

你是被被assign的reviewer吗？还是说同事本来没打算让你review？

如果你同事在doc里正式让你review，那么你的comment他理论上不能直接关掉，如果他这么做你可以re-open甚至回一句“not done？“以防他点错了键。如果他不回应那么是他passive aggressive，这跟舔着脸直接跟人要approval也没区别了。

但如果你同事压根没想让你review的话，那这个度的确需要拿捏一下。

理论上说，如果你不是正式的reviewer，除非当你发现有重大问题的时候你应该直接指出来。一来的确是为了所有人好，不然越往后越难改，甚至可以避免postmortem，二来也是为了更高的visibility，毕竟你发现的问题连正式reviewer们都没有看出来。即便你指出来，你也应该立刻私下里去跟他友好地聊一聊，把你的问题当面再问一遍，因为如此大的问题应该也不是一两句话能讲清的。你们俩当面沟通完事之后，他可以在doc里回复你spoken offline的总结，也是for visibility。

不然的话，如果是你觉得你的方法比他的好，然后你语气在直接点，比如上来就why not，那的是有点问题的。

大厂里的design doc虽然叫design，但其实并不是你一个人的“设计”，相反很多时候是经过无数轮讨论和妥协之后的结果，整个过程非常的nagging。比如如果你只是一个L3/L4，然后一群L5/L6已经提出了一堆相互不同意见，经过了数周甚至数月的讨论，最后终于得到了你现在看到的这个方案。由于这个design是大佬们神仙打架的结果，可能真的不一定有多好，但是它至少应该没有foundamental的问题。

你如果没有从头参与讨论，只是看到了这个design doc，你大概率会觉得为什么这么简单的问题不直接用xxx？这doc写的都是些什么玩意？

同事如果要回复你的话，相当于需要把整个讨论的历史都给你讲一遍，跟你说我们其实讨论过了solution a，b，c，其中a的优劣是xxx，b的优劣是yyy，最终我们选择了c。很可能为了回复你的问题，他相当于要重新写一篇design doc。

重要的是，他又不能因为你说了啥就改方案，就算你的建议可能的确在某一方面更好，但是他又不可能推翻大佬们好不容易妥协完的结果，他甚至都不能在doc上公开跟你说现在你看到的这个垃圾东西是大佬们都同意的，那你觉得他应该回复什么呢？认同你的建议然后再解释一堆为什么不采用吗？而你评论的诉求又是什么呢？你是真的只想学习吗？还是你觉得他应该听你的？

换句话说，你要看这个design doc已经到了一个什么阶段。如果只是早期team内部公开讨论收集意见的阶段，那你的确可以提。如果已经到了中后期，很多东西已经被反复讨论过了，那这个时候你就不要再去comment了。如果你对别人的项目不那么熟悉并且想学习，不然更好的方式其实是约个1:1然后当面问问题。一来当面说能问答的更彻底，甚至可以跟你说一些不能在doc上明说的东西，二来半个小时或者午饭的时间可能真的比他正儿八经回复你要短。

另外，最后补充一句。我个人对于别人的comment的回复详细程度取决于我对这个人的喜爱程度。所以哪怕你真的就喜欢通过在别人doc上留comment的方式学习，你至少先跟同事处好关系，至少让别人知道了你真的只是好学。关系处理好了，同事可能都更愿意主动跟你多聊一聊，而不是等你去发一些comment然后还得想要不要花这个时间在你身上。

这个应该是分人吧………
跟公司应该关系不大

匿名用户 发表于 2022-06-27 15:01:30
这个应该是分人吧………
跟公司应该关系不大

层主有什么建议解决这个问题吗？

匿名用户 发表于 2022-06-27 16:35:38
是你这个同事有病

层主有啥建议。
毕竟要一直合作的同事。

打探一下别的和ta有过合作的人的口风？

匿名者 发表于 2022-6-27 17:24
层主有啥建议。
毕竟要一直合作的同事。

先跟对方同事clarify为啥这么做，他想你怎么做。如果他提的你觉得不合适，建议汇报给你经理。

你留comment是啥语气呢，是单纯不懂的问题还是非要找出来的问题呢？，还有一个是你和一起合作的doc或者项目吗？
如果是我，我们组假设有个和我同期的新人，不熟悉我的domain 和我不合作 做的东西没什么关系，却要展现自己的leadership要来provides comments，而且不是在那种design review的会上，我也会觉得很烦。 会觉得他为什么觉得自己有水平也有资格对我的东西来做很多judge。

zjh412202188 发表于 2022-06-27 19:35:42
你留comment是啥语气呢，是单纯不懂的问题还是非要找出来的问题呢？，还有一个是你和一起合作的doc或者项目吗？
如果是我，我们组假设有个和我同期的新人，不熟悉我的domain 和我不合作 做的东西

没什么语气？
就正常的技术讨论吧。类似schema要怎么设计，是否可以加一个新的field. ModelName有歧义之类的。

在同个项目工作。组里就没几个人，一直手能数过来。

强行展现leadership技能是什么意思，能解释一下吗？

zjh412202188 发表于 2022-06-27 19:35:42
你留comment是啥语气呢，是单纯不懂的问题还是非要找出来的问题呢？，还有一个是你和一起合作的doc或者项目吗？
如果是我，我们组假设有个和我同期的新人，不熟悉我的domain 和我不合作 做的东西

另外 资格 是什么？

这算职场潜规则吗？  默认级别不高不能提问题？