Comment by setr
21 hours ago
I consider PRs to be primarily a defense of the architecture, and to a lesser degree a general sanity check. It’s also a useful opportunity to enforce automations are being run
21 hours ago
I consider PRs to be primarily a defense of the architecture, and to a lesser degree a general sanity check. It’s also a useful opportunity to enforce automations are being run
I consider 99% of my "defense of the architecture" strategy to be teaching my team why the architecture is important, how to think about it, and invite they commentary on it as we own and evolve it together. And of course if they are doing something and want input or are uncertain, then my door is open.
If PRs are a notable part of my architecture defense, I'm going to work on investing in the team instead of reviewing PRs.
> I consider 99% of my "defense of the architecture" strategy to be teaching my team why the architecture is important, how to think about it, and invite they commentary on it as we own and evolve it together.
Nice way to avoid the responsibility for any team fuckup: it's not me, I only teach them, they decide themselves.
>Nice way to avoid the responsibility
Welcome to the tech industry. Its all about shifting responsibility in case something goes wrong. Thats the only reason companies use third party software in the first place, to have a scapegoat...
1 reply →
"Teaching" doesn't work well for plenty of people. I couldn't count the number of presentations, design review meetings, tech talks, etc. I've attended that I remember nothing from. On the other hand, putting something into code, getting feedback and understanding how something affects the system I care about - that's something that sticks.
Ok, so you ignore PRs and don’t catch people who made architectural mistakes until what, they go to production?
I mean, do that too, but end of the day PRs are your final chance to catch the mistakes before they start cementing, and is your best opportunity to identify misunderstandings (you can smell the confusion in their changes and address it directly).
But also, I must defend against the hordes of unwashed masses and maintain the sanctity of my domain. End of the day, a codebase I own is a codebase I own, and others cannot be allowed to poison the well, intentionally or not. That’s how you get cholera
Very well put. A PR is the final (and ultimate) chance to say "no" to a change - after that it's part of the software, it needs to be maintained, it can have impact on stability/quality etc.
I don't quite understand how someone in charge of a software (techlead or similar title) can't take this serious; I know a few such people and I generally prefer to avoid working with them...