Ask HN：如何与海鸥原则协作？
1 分•作者: mystickphoenix•9 个月前
类似于“海鸥管理”（https://en.wikipedia.org/wiki/Seagull_management）的概念，我在与首席工程师打交道时也遇到了类似的情况。
我在几家公司都遇到过这种现象，通常发生在代码审查（PR/MR）期间，但也不限于此。我看到的一般行为是，首席工程师突然出现，对代码审查、提案、文档或项目大肆批评，制造一堆噪音，然后就消失了。这种批评通常不会很明显或直接，但它会给任何“下级”人员在审查或提供反馈时泼一盆冷水，并往往会严重阻碍进展。
在最近的一个案例中，对代码审查的反馈基本上是“你为什么不直接……做这件表面上看起来很简单的事情呢”。我已经探索过提议的解决方案，但觉得需要证据来支持我使用的替代方案。这导致我陷入了几个小时的“兔子洞”，因为我试图让首席工程师的解决方案起作用。有趣的是，它并没有起作用，而且还把代码搞得一团糟。然后他们消失了一两天，而我的团队其他人也没有给我任何反馈，因为他们都在等待首席工程师的回应。
我很想听听关于如何更好地与首席工程师合作的建议，特别是那些像海鸥一样忙碌的。
查看原文
Similar in concept to "Seagull Management" (https://en.wikipedia.org/wiki/Seagull_management), I've run into a similar thing when it comes to Principal Engineers.<p>I've encountered this phenomenon at a number of companies that I've worked for and it normally comes up during PR/MR reviews, but not exclusively. The general behavior I see is a Principal flies in, shits all over the PR/MR, proposal, document, or project, makes a bunch of noise and then disappears. The shitting all over it usually isn't blatant or obvious but it throws a huge wet blanket on any "lower" personnel reviewing or providing feedback and tends to stall progress massively.<p>In the most recent case the feedback on the PR/MR was essentially "why don't you just... do this thing that seems simple on the surface". I had already explored the proposed solution but felt like I needed evidence to back up the approach I used instead. Which necessitated a several hour rabbit hole as I tried to make the Principal's solution work. Fun fact, it didn't, and had that added benefit of turning the code into a spaghetti mess. They then disappeared for a day or so and I got zero feedback from the rest of my team as they were waiting for the Principal's response.<p>I'd love to hear tips on how to work better with Principal Engineers, especially ones of the overworked seagull variety.