[haswell]

> If many of your discussions fall in this zone, it's possible you, yourself, may be taking guidelines as too black and white.

I have very mixed feelings about this. On the one hand, I’m no fan of following process for the sake of it.

On the other, the way to address policies that need an update is to sit down with the lead/manager and propose changes with evidence as to why.

Deciding to just do things your way and then arguing about it is not the way.

[withinboredom]

If you can automate the rules, do it. If you can’t automate the rules, don’t try to enforce them, just ask why.

I worked at a place where 10k LoC PRs were the norm. At my next place, I’d open a 1k PR and people would lose their shit. They’d ask for it to be broken up into smaller PRs and my response was “it’s already ridiculously small”

Personally, I’d rather see the big PR and spend time reviewing that than trying to figure out what they’re trying to set up and do. As long as the big PR is coherent and well-written. If it’s spaghetti monster, I’ll pass.

[out-of-ideas]

I mostly agree due to the nature of not all code is straight up assembly/c/cpp, LOL. Knowing your target audience is key. In this case the team size, company size, ect.

I would be okay with larger PRs especially for configuration as code like ansible and terraform hcl. Hoping that people actually use comments and keep code chunks in relevant sections (I've begun paraphrasing ansible to use more whitespace between different "sections". This of course becomes more acceptable when one playbook or hcl folder is copied to another area for promotion purposes, but of course using tooling to check for diffs is crucial here.

[zeroonetwothree]

IME it’s pretty much impossible to change rules adopted by a bureaucracy if you are just a cog.