I do agree with the common refrain, actually, and disagree with the idea that work can be so big and complex that it has to be in one pull request.
> A big queue of PR's for reviewers to review
Yes, yes please. When each one is small and understandable, reviewers better understand the changes, so quality goes up. Also, when priorities change and the team has to work on something else, they can stop in the middle, and at least some of the benefits from the changes have been merged.
The PR train doesn't need to be dumped out in one go. It can come one at a time, each one with context around why it's there and where it fits into the grander plan.
> The [totality] of the feature is split across multiple change sets, increasing cognitive load (coherence is lost)
A primary goal of code review is to build up the mental map of the feature in the reviewers' brains. I argue it's better for that to be constructed over time, piece by piece. The immediate cognitive load for each pull request is lower, and over time, the brain makes the connections to understand the bigger picture.
They'll rarely achieve the same understanding of the feature that you have, you who created and built it. This is whether they get the whole shebang at once or piecemeal. That's OK, though. Review is about reducing risk, not eliminating it.
> You end up doing work on branches of branches, and end up either having to become a rebase ninja or having tons of conflicts as each PR gets merged underneath you
I've learned not to charge too far ahead with feature work, because it does get harder to manage the farther you venture from the trunk. You will get conflicts. Saving up all the changes into one big hunk doesn't fix that.
A big benefit of trunk-based development, though, is that you're frequently merging back into the mainline, so all these problems shrink down. The way to do that is with lots of small changes.
One last thing: It is definitely more work, for you as the author, to split up a large set of changes into reviewable pieces. It is absolutely worth it, though. You get better quality reviews; you buy the ability to deprioritize at any time and come back later; most importantly for me, you grasp more about what you made during the effort. If you struggle to break up a big set of changes into pieces that others can understand, there's a good chance it has deeper problems, and you'll want to work those out before presenting them to your coworkers.
Reminds me of a job posting sent by a recruiter that expected candidates to seek "professional and personal hypergrowth", "keep up with an unrelenting pace", and "thrive on change". Dealing with these facets of work in moderation is all well and good. However, these and other points led me to guess that they had set up a high-pressure, possibly chaotic environment, perhaps on purpose.
> However, these and other points led me to guess that they had set up a high-pressure, possibly chaotic environment, perhaps on purpose.
It's always wise to ask questions about this during the interview
In my experience, though, hyperbole in job listings is usually the product of someone in HR who doesn't know how to write job listings, so they write a bunch of vacuous words that sound good but mean nothing.
By my reading, the outrage is likely coming from the cushioned stereotyping from the podcast participant. They're stating that "neckbeard types" and autists aren't customer-ready and are uncomfortable talking with customers. That second part is worse because it may lead to assuming that those folks would never want to talk to customers, or even learn how, and so the PMs might "protect" them by never offering them the chance, while assuring themselves "that's okay, that's great, I mean it takes all kinds".
> demand all kinds of ridiculous accommodations that you could never have reasonably asked for on your own
The union oughtn't seek "ridiculous" accommodations then. It should seek at least reasonable ones, and possible aspirational ones, and negotiate it out from there. The problem we're seeing now is that even demands that most would find reasonable are cast as ridiculous by management. And if a union has trouble getting employers to listen, there's no hope that someone on their own can.
I've personally lost faith that a typical employer is capable of recognizing the value of an individual employee. So many of the recent layoffs have not accounted for individual performance or criticality to the business (Twitter's being a good example). So my own value isn't as strong of a bargaining chip.
It doesn't matter, if my employer would treat me as interchangeable anyway.
And even interchangeable employees deserve reasonable accommodations. I do think a union can highlight those needs more effectively than individuals (especially for interchangeable ones, to your point).
Possibly, at least for my own experience. It's much less often that I rerun a search with !g. Brave Search's results are becoming more relevant to my own queries, and Google's becoming less so. Not to mention how ads like to masquerade as ordinary Google results; using Google is starting to feel less comfortable.
That seems to be the general case, other search engines. Especially Bing and those based on Bing are yield increasingly good results, while Google is just ads and spam.
GitHub should monitor their status page traffic for spikes, which probably mean something is wrong somewhere, even if they themselves haven't noticed yet.
> A big queue of PR's for reviewers to review
Yes, yes please. When each one is small and understandable, reviewers better understand the changes, so quality goes up. Also, when priorities change and the team has to work on something else, they can stop in the middle, and at least some of the benefits from the changes have been merged.
The PR train doesn't need to be dumped out in one go. It can come one at a time, each one with context around why it's there and where it fits into the grander plan.
> The [totality] of the feature is split across multiple change sets, increasing cognitive load (coherence is lost)
A primary goal of code review is to build up the mental map of the feature in the reviewers' brains. I argue it's better for that to be constructed over time, piece by piece. The immediate cognitive load for each pull request is lower, and over time, the brain makes the connections to understand the bigger picture.
They'll rarely achieve the same understanding of the feature that you have, you who created and built it. This is whether they get the whole shebang at once or piecemeal. That's OK, though. Review is about reducing risk, not eliminating it.
> You end up doing work on branches of branches, and end up either having to become a rebase ninja or having tons of conflicts as each PR gets merged underneath you
I've learned not to charge too far ahead with feature work, because it does get harder to manage the farther you venture from the trunk. You will get conflicts. Saving up all the changes into one big hunk doesn't fix that.
A big benefit of trunk-based development, though, is that you're frequently merging back into the mainline, so all these problems shrink down. The way to do that is with lots of small changes.
One last thing: It is definitely more work, for you as the author, to split up a large set of changes into reviewable pieces. It is absolutely worth it, though. You get better quality reviews; you buy the ability to deprioritize at any time and come back later; most importantly for me, you grasp more about what you made during the effort. If you struggle to break up a big set of changes into pieces that others can understand, there's a good chance it has deeper problems, and you'll want to work those out before presenting them to your coworkers.