求问 如果senior要求很高 block住你的进度怎么办

大家好，我想请教一下大家关于SDE工作上的一些问题。我工作也快两年了，经历了两个组，在每个组都遇见了对代码要求非常非常高的人，他们似乎对写代码这件事有偏执症，也完全不在乎你的项目有很紧的ddl要求，只在乎你是否达到了他的coding要求。有时候我想绕过他们找别人review，他们甚至会在我的code被approve之后 继续留很多comments，包括且不限于要你improve以前别人写的testcase名字，说可读性太差，可是这都是存在几年的代码了 真的有必要在赶项目这么紧的时候非要去改这个吗。但是你要去challenge他，他就有无数理由来反驳你，我也知道这些是好事，但是要做的快就必然做的糙呀，方方面面都考虑到就需要更多的时间。而且老板并不在意我code写的多fancy，只希望我能赶上ddl。老板也没什么能力去改变senior，毕竟senior在这个org很多年了。。最后就是所有的压力都在我身上，既要求我code简洁好看，各种testing/metrics全部到位，还要fix前人留下来的一些bug，又要求我在很短的时间内完成。。最后我只能加班改才catch上ddl。

我想问大家组里都是这样吗。。如果遇到这种情况你们都是怎么处理的呢。

曾去过十分类似的组，最后以转组了事。现复盘如下：
1. 回复将会在专门开一个code cleaning的ticket里一并解决，这个ticket ddl就在眼前，不希望延误工期
1.1 可以在weekly meeting上提出开code cleaning session的事，比如两个月来一次，专门处理legacy code。这样不仅可以满足senior的嗜好，还可以增加你的visibility
2. 1 on 1和老板反映此事，批评该senior做事情不professional，分不清top priority/low priority issue
3. 如果老板的态度是支持此人，或者表示无力改变现状，说点冠冕堂皇的话来打发你，那尽早换组。这样的组呆久了只会伤害你自己的career path


特别解释一下1.1。不要忘记，legacy code是前人写的，senior没资格点名要求你在你的PR里解决该问题。应该在专门的session改进此类问题，而不是越改越乱、PR越写越大。这样对谁都不好。

以及大家也不要单纯觉得Senior给你抓bug是无私、对你好的表现。在商言商，作为Senior，除了lead的project以外，自己对组里的impact都是每次performance review的时候需要着重考量的点，以及我记得亚麻的Senior是要担任一定management的任务的，所以对于junior engineer是有lead的义务的。这种review都是要量化自己的成果的，所以怎么体现呢？PR comment的数量其实就是一个很好的point。所以有时候如果发现PR comment有些故意找茬的意味在里面，不要怀疑自己，你没有什么问题，是给你comment的兄弟想升职了或者保住饭碗而已。所以勇敢地怼回去是正确的做法。



补充内容 (2022-07-30 16:21 +8:00):
把我楼下某个补充的观点放在这里，大家自行判断。对于Jr来讲，ddl也好，quality也好，都不如个人成长（promotion）重要。在Promote到Senior之前，你的一切行为就应该为了promotion服务，如果赶ddl对你更有帮助那就多赶ddl，反之如果在一个ddl让位于quality的组，那就好好管quality

“This is outside the scope of this CR. Happy to discuss if you’d like it addressed separately.”

问问自己几个问题吧

作为新手：

别人的烂代码有没有给自己添过麻烦？

自己的烂代码有没有给别人造成过影响？

这个项目的生命周期有多长？自己今天省5分钟造成的技术债会不会在将来要5个小时来解决？

Does the business goal require me to get it work, get it right, make it faster in the short term?

我是因为写不出高质量代码，还是因为这次选择牺牲质量换时间？

我的career goal是什么？作为junior我有没有涉及过大型库/框架？现在refactoring是不是一种锻炼的机会？



作为tech lead：

我的团队现在或将来能不能驾驭项目的代码？会不会烂代码导致项目失败？

团队来了新人，tech debt会不会导致培训困难？

组里的同事向我抱怨烂代码导致工作困难我该怎么回应这个同事？

我的团队是不是在修复tech debt上投入的时间大于当初设计并实现好代码的时间？

leading by example效果怎么样？我有没有遇到过某些同事就是不愿学习，而导致唯一的途径就是在Code Review提出问题并block？

重构和单元测试应不应该有专门的工单？这些工单会不会因为短期收益小而导致从来没人实现？

我有没有能力向上面多要些人给组里分担压力？我能不能说服项目经理给项目多争取点时间？


上面这些问题都是我亲身遇到过的。

私下问问senior，能不能先ship，然后设定期限，比如一个月之内改进。

han6 发表于 2021-2-20 12:46
私下问问senior，能不能先ship，然后设定期限，比如一个月之内改进。

遇到好说话的是可以协商的，但是真的也有那种不太管你的ddl，只管自己的要求有没有达到的senior。。不知道大家都怎么解决这种情况。

一定要push back回去啊！cr里面如果comment太多iteration太多会被认为能力不行然后被成为pip的证据的。不是自己的问题一定不能承认自己错然后改，要全部怼回去

1. 和这个CR无关的通通不要放到一起。回复就是这是以前代码现在改可能会convolute things. 下一步会专门针对这个发一个cr。开一个sim task放到回复里以示诚意。

2. 简单名字啊 format啊就从了，改起来还好，不费劲。

3. CR越小越好。


4. 赶不上ddl的话要及早跟老板说。下次定ddl的时候要给自己留够buffer。

hawktomania 发表于 2021-02-19 21:23:42
一定要push back回去啊！cr里面如果comment太多iteration太多会被认为能力不行然后被成为pip的证据的。不是自己的问题一定不能承认自己错然后改，要全部怼回去

手动反对…这种无理取闹的push back比多iteration 糟多了…

—-

具体的话，ls说得好，下次多留buffer，快的就从了，慢的留todo

cbvr 发表于 2021-2-20 14:06
“This is outside the scope of this CR. Happy to discuss if you’d like it addressed separately.”

但是他是待了很久的senior 他可以不approve你的cr 一直拖着你直到你改
至少我观察到的 组里的人被senior留了很多comments的 都是加班加点的在改 没看到几个真的push back成功的。。

借个名字 发表于 2021-2-20 13:55
1. 和这个CR无关的通通不要放到一起。回复就是这是以前代码现在改可能会convolute things. 下一步会专门针 ...

谢谢这么detailed的回复！
因为senior指出很多别人留下的小问题，我本来也觉得都是小问题可以顺手改一下，后来发现小问题积累在一起非常费时间，而且可能会改变test behavior就又要花时间改。
除了小问题还会有那种需要花时间调查的问题 比如写的过程中发现以前的某个已有的metrics没有work 某个已有的unit test他觉得logic不对 即使这段代码已经存在并且运行几年了 他也会要求你去调查 理由是可能会有undelying issue 我觉得我真的很难说服senior 他的理由我也没办法反驳
这个项目的ddl不是我定的 是一个和合作组的项目 合作组的TPM定好了ddl并且每个task都有ddl 我也尽力跟TPM多要时间了 但是每天老板都在催我 同时senior在任何你看得到的看不到的细节处都在尽力做到完美。。真的很心累。

开个task记下跟你diff不相关的comment 然后把task贴上到comment 说之后会处理 diff只想focus在project相关的问题上

换位思考下 你做到senior看到同事diff里面有些东西可以改一下 可能跟本意不一致 但是从整个team来说这样的effort也是必要的