| ▲ | nixon_why69 6 hours ago | ||||||||||||||||
Context is everything for massive PRs. If you don't ever have a massive PR from a dynamite session, then you cannot ever be better than "average and plodding". So the question is, what's the context of the massive PR and how should it be handled? * Mature product making money, intermediate engineer just refactored everything so it's "better"? Shut the fuck up, kindly please, you will have to demonstrate that you understand why things are this way and why it's better before we even have this conversation. * Greenfield dev, trusted engineer getting from 0 -> 1 on something big? Maybe it shouldn't be held up in committee for 2 weeks. Maybe most objections will be superficial stylistic concerns. Obviously there are many other contexts and these are 2 extremes in a multi-dimensional space. But if the process is "we litigate every line", then that's just not an innovative place to be. Yes, most PRs should be small, targeted, easy to review and tied to a ticket but if you're innovating? By definition it's a little different. | |||||||||||||||||
| ▲ | pdimitar 5 hours ago | parent | next [-] | ||||||||||||||||
> you will have to demonstrate that you understand why things are this way and why it's better before we even have this conversation I can fling that back to you: very often the team hates the conclusion I arrive at, which is "It worked during your initial crunch and then everyone is just afraid to change it, which means your test coverage is far from good -- why is it not enriched?" I am not trying to be an arse on purpose but the inertia and cargo-culting and tribe-defending practices I've seen during my contracting years (10-11) made me almost physically sick. Programmers are a fiercely territorial bunch and it's often to the detriment of the organization. Of course the reverse cases exist: where the domain is difficult and ugly hacks had to be done so the project works and makes money. Absolutely. I love receiving this knowledge and integrating it; makes for interesting engineering discussions. > Greenfield dev, trusted engineer getting from 0 -> 1 on something big? Maybe it shouldn't be held up in committee for 2 weeks. Maybe most objections will be superficial stylistic concerns. Yep, full agree. And often times these stylistic concerns are not even that; they are often "I suffered here at the beginning, this green-horn should suffer as well!" which is honestly pathetic and it also happens quite a lot. | |||||||||||||||||
| ▲ | dogleash 5 hours ago | parent | prev [-] | ||||||||||||||||
> If you don't ever have a massive PR from a dynamite session, then you cannot ever be better than "average and plodding". That's just cope to avoid learning how to turn a big change into a well organized patch series. | |||||||||||||||||
| |||||||||||||||||