请问HN：如何与海鸥原则合作？
与“海鸥管理”（https://en.wikipedia.org/wiki/Seagull_management）概念相似，我在与首席工程师合作时遇到了类似的情况。
在我工作过的多家公司中，我遇到过这种现象，通常在PR/MR评审时会出现，但并不局限于此。我观察到的一般行为是，首席工程师飞过来，对PR/MR、提案、文档或项目进行一番批评，制造一阵噪音后又消失不见。这种批评通常并不明显，但会给任何“较低”级别的人员在审查或提供反馈时带来巨大的压力，往往会严重拖延进度。
在最近的一个案例中，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.