| The 'large PR' issue - I've been on the 'violating' end of that, but... there are actually times when a PR touching a lot of files and making changes is called for. I got push back at the last team I was on where this was an issue, and the stated thing was "it's hard to review". Yet... no one ever - literally - pulled down code in a PR/branch and reviewed it locally, never reviewed any tests (in 2 years I never got one question about a test as in 'you missed use case X in your tests', etc). They literally just meant "reviewing this on the screen in the github UI is hard when there's more than a handful of files - it's hard to tell where the changes are or what they effect". This is why I would also have tests and (sometimes extensive) documentation in the PR, to help a review. Never happened. I had "large" PRs (by someone else's labelling) about 10-15% of the time. I would get pushback - "this is too much - it's too confusing". Me: "OK... let's schedule some time to review - maybe you can help me cut it back some, or you can assist me in some way in this work?". Others: "don't have any time for that - this is just too much work". OK, so... complain about the work, but when I ask for help to conform to your standards... I get a refusal. I point blank asked multiple times when this was lodged as feedback - "what steps could I take to have made this smaller?" The only substantive thing that would have made it somewhat easier to roll out some of these "larger" changes in smaller chunks would be to have had a more comprehensive feature-flag system in place. I put a basic flag system in over a weekend - some server side, and some hacky method to respect the flags in client side code as well. It was done over about 3 hours, and was never improved. Again - very hacky. I had an "improvement" ticket in for... about a year, begging for more than a few hours to devote to tightening up "feature flag" system to be a bit more comprehensive, documented, etc. Every "sprint planning meeting" it was the same "there's no time for that, it's not that important, quarterly deadlines, blah blah blah". But if/when I'd do things that were 'unticketed', that was met with accusations of being passive/aggressive, or being subversive, or 'not a team player'. "If you've got time to do that, you could have been helping out people who were behind". The same people who didn't write tests or documentation, and refused to meet with me when I asked for assistance in trying to accommodate their calls for "smaller PRs". First year on the project was good, but as it grew, policy/procedure/scrum/agile got in the way, with more process and less ability to get useful stuff done. Second year was far less productive (at least, compared to what it could have been - I'm sure some people just saw forward progress as 'good', but we were greatly slowed by more process and ceremony over time). |