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

o彩蝶寻梦o 发表于 2021-2-21 14:08
那我觉得你这个时候就应该站在你们team的角度去分析，到底quality重要还是ddl重要啦，如果你都没分析过， ...

我相信对于任何像样的team来说，ddl都应该重要于quality。如果一个组把quality放在ddl前（in general），那这个组里的人和business基本都走不远。

其实你猜的没错，我当年呆的那个组是个内部的tooling组，做的tool差不多是彻底不赚钱、单纯为了公司牌面存在的，如你所说，是个单纯的把quality放在ddl前的组（因为根本没人想用我们的产品，我们开发得慢一点，我估计别人还想谢谢我们）。因此我转去了impact大的组，结果就是做得很开心，该升职升职该加薪加薪，同事的技术水平很高但不苛责，提出的建议都是中肯且有理有据的、有益于整个软件健康运行的，而不是软件工程理论里拎过来的一些关于design pattern的杂碎。


两个组孰好孰坏，虽然在我看来一目了然，但我不想给出我的答案。只能说不同的人适合的东西不一样吧

补充内容 (2022-07-30 16:11 +8:00):
顺便说一句，我认为对于还没到Senior的junior来说，不论是quality还是ddl都没有promotion重要。你自己考量应该怎么做才能尽快promotion

o彩蝶寻梦o 发表于 2021-2-21 14:08
那我觉得你这个时候就应该站在你们team的角度去分析，到底quality重要还是ddl重要啦，如果你都没分析过， ...

senior这种程度感觉并不是提建议了。。建议还要看我接不接受。。这种只能叫要求。以及你肯定是没有跟那种吹毛求疵的人工作过 真的合作过并且没有一个人可以制止他的时候你就知道那种感觉了。。

donnice 发表于 2021-2-21 14:23
我相信对于任何像样的team来说，ddl都应该重要于quality。如果一个组把quality放在ddl前（in general）， ...

谢谢你！我觉得这种处境真的只有经历过的人才懂 以前我没有经历过的时候 看到这种情况 也会觉得senior是为你好 你可以学习可以提高 真的经历过才明白个中滋味吧。。恭喜你去到氛围更好的组啦。

回复里面是不是对Sr有什么主观臆断的恶意啊？还是因为这只是楼主的一家之言所以都站楼主边？一个组的代码质量如果Sr也不站出来把关，你觉得就靠大家自己各行其是自己给自己ship？首先，Code review本来就是义务性质的，多你这个不多少你这个不少的，给你提comments本来就是会消耗自己时间的，包括comments之间的back and forth，有那时间干嘛不花在自己的项目上？Code debt这个东西从长期来看是会bite你们自己组的，虽然你按时deliver了，但是留下一堆不合格的代码其实是要付出更大的代价的。如果非要escalate，manager还非要站ddl一边，我会觉得很不爽的，以后出事的话coe老板也得挂上名。有时候你觉得没必要的comment其实是别人觉得很不合理的东西，比如说实现一个功能你只知道A方法但是不知道B方法，你当然在实现的时候会直接用A方法实现了，等别人给你提出应该用B方法的时候，即便别人说出了B方法的pros，你也会觉得我的A方法能work可以先上了再说。这种情况出现一两次情有可原，如果老是出现你是不是应该反思一下，换个做事情的方法，在写代码之前先share一下你的思路，先去align一些大方向？这个时候你们组的Sr反而会成为你这边的人了。

chilam 发表于 2021-2-21 15:15
回复里面是不是对Sr有什么主观臆断的恶意啊？还是因为这只是楼主的一家之言所以都站楼主边？一个组的代码质 ...

不是这个问题，首先题主提到了整个teams里所有人都被Sr cue到了要改代码质量，大家还加班加点改。如果说题主一个人的代码有问题情有可原，全组都有问题，那你觉得是谁的问题概率大？

其次，我不知道你现在是不是Sr。对于Sr来说，自己的项目做得快慢好坏已经不是考察的重点，想往更高处走（Manager），更多的是要强调对组员的lead和educate。何况这位Sr对项目代码了若指掌，多做个ticket少做个ticket根本也不是事儿。这时候类似PR comment这样的带有lead性质的互动反而比项目更能make him shine。PR comment是算credit的！

最后，我不是说代码质量不重要，但我认为一个合格的Sr应该要分清主次。做一个工程，最关键的就是要模块化，就是一个PR只能focus on一件事。把refactoring和new feature混在一起，最后只会导致这个PR越来越乱，时间越拖越长。工程最忌讳的就是目标不清、胡子眉毛一把抓。在这点上，这位Sr显然是不合格的。

这些只是不带恶意揣测的客观因素。一个PR长时间不得解决、comment巨多无比，对于一个急需成长升职的junior来说，ta的perf review只会降低，短期内有害而无益。作为Sr应该是不可能不知道这些事情的，所以我觉得真的很难说这位Sr是否有恶意。

当然我知道，确实存在一些傻白甜Sr，不管所谓的perf review，也没想那么多，给你comment是真心想让你学到东西、帮助你改进代码质量。我谢谢您嘞，但我来这上班又不是为了在学校进修，大家一起挣点钱而已啊！

chilam 发表于 2021-2-21 15:15
回复里面是不是对Sr有什么主观臆断的恶意啊？还是因为这只是楼主的一家之言所以都站楼主边？一个组的代码质 ...

楼里已经回复过了 如果给足够的时间 我也完全同意无限改进 写出一手牛逼的代码我也很开心 没有批评senior的comments都很无理的意思 问题是这个项目不是极度追求性能的项目 老板也非常着急ddl  而且为什么就assume senior不满意的代码就是不合格的代码呢？如果照着senior的标准 amazon和fb前期的产品绝对都不是合格的代码 甚至现在的aws很多产品都不是。但是如果要等到他们都完美再launch，他们都不可能会是现在的规模。

chilam 发表于 2021-2-21 15:15
回复里面是不是对Sr有什么主观臆断的恶意啊？还是因为这只是楼主的一家之言所以都站楼主边？一个组的代码质 ...

而且还有一点，一般来说在实现一个feature前，大方向都是定好的，也就是具体实现的方法里会存在A方法和B方法。

在这个假设下，我只知道A方法，然后Sr告诉我B方法。B方法固然可能更好，但往往仅仅是一些good to have 而不是must have的东西（因为must have的东西在讨论大方向的时候应该已经确定了）。这种时候为了一些good to have的东西去阻拦真正重要的ddl，我个人认为是很愚蠢的。再者，很多时候所谓的B方法都算不上good to have，只不过是另一个option，这位Sr本人更喜欢而已。我凭什么一定要符合别人的胃口，用别人喜欢的方法？

donnice 发表于 2021-02-20 23:33:15
不是这个问题，首先题主提到了整个teams里所有人都被Sr cue到了要改代码质量，大家还加班加点改。如果说题主一个人的代码有问题情有可原，全组都有问题，那你觉得是谁的问题概率大？
.google  и
其次，我不知

忍不住要回复你，但是不想耽误太多时间在这上面了，所以这是最后一条，你还有话说请另开楼不要点回复了。只希望你不要乱误导人。你要是个Jr我很庆幸没有跟你一个组，这样的Jr真心带不动，心累。你要是Sr或者Principle，我也很庆幸没有跟你一个组，你们组的坑还是留给你们自己填好了。你要是SDM我还是很庆幸没有跟你一个组，一个只顾眼前的ddl不看长远的代价的老板无法earn我的trust。

chilam 发表于 2021-2-21 16:31
忍不住要回复你，但是不想耽误太多时间在这上面了，所以这是最后一条，你还有话说请另开楼不要点回复了。 ...

滑坡谬误。我说的是ddl最重要，但这不等于完全不顾代码质量。我提出的方案是专门开code cleaning session，我呆过的大部分组的PR规则也仅仅是抓大放小，提高test coverage而已。大幅度牺牲ddl而almost all in quality的组，恕我直言，都不挣钱。如果你们时常出现代码无法维护、需要大量refactor的情况，请先考虑一下在开发feature前做好design planning。


同样的话还给你，看起来你是一位Senior，我十分庆幸没有和你呆在一个组。一个为了所谓一些不合理的quality标准连ddl都能牺牲的Senior绝对不可能遵守deliver result和customer obession

补充内容 (2022-07-30 16:13 +8:00):
另外，那个叫Principal

chilam 发表于 2021-2-21 16:31
忍不住要回复你，但是不想耽误太多时间在这上面了，所以这是最后一条，你还有话说请另开楼不要点回复了。 ...

只是想说一句 别人又没有非要和你做同事 为什么来这么一堆莫名其妙宣布我不要和你同事的话。。另外你有没有看过alexa某些service的code 如果照你的说法 bezos就是一个只顾ddl而牺牲长远利益的老板啊 因为赶着alexa上线抢占市场 alexa很多service code质量都不咋地 也不妨碍alexa还是市场份额第一啊。。