Ask HN: How to Work with Seagull Principals?
1 comments
I would suggest including in your PR a clear design statement that summarises (briefly) why you coded the solution the way you did.
I always used to 'demand' that of my juniors otherwise there was no way of knowing if they'd just opted for the simplest and not most performant solution
I always used to 'demand' that of my juniors otherwise there was no way of knowing if they'd just opted for the simplest and not most performant solution
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.
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.
I'd love to hear tips on how to work better with Principal Engineers, especially ones of the overworked seagull variety.