> 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.

Comments URL: https://news.ycombinator.com/item?id=43462526

Points: 22

# Comments: 12

I opted not to pursue the opportunity.

Comments URL: https://news.ycombinator.com/item?id=42627341

Points: 1

# Comments: 0

Peter: ... Nothing.

Lawrence: Nothing, huh?

Peter: I would relax, I would sit on my ass all day ... I would do nothing.

Lawrence: Well you don’t need a million dollars to do nothing, man.

https://www.youtube.com/watch?v=4lmW2tZP2kU

Comments URL: https://news.ycombinator.com/item?id=41837700

Points: 3

# Comments: 0

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).

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.

https://wipeout.fandom.com/wiki/Teams

https://www.goodreads.com/book/show/3165591-the-virtual-real...

The demo program was a robotic arm simulator that my partner already had on hand, since it could easily render wireframes. The updated simulator rendered two wireframes of Optimus Prime, so with the driver in place, he floated in front of the screen.

And, of course, you could rotate him in space, and then hit the space bar to transform him in 3D.

* "public images will only be removed from Docker Hub if their maintainer decides to delete them"

* "Public images will only disappear if the maintainer of the image decides to proactively delete it from Docker Hub. If the maintainer takes no action, we will continue to distribute their public images."

This sounds good, but it would be better to explicitly say "if you opt to let your free organization be suspended, Docker Hub will continue distributing your public images indefinitely anyway". It feels like there's a loophole here where if a public image comes to have no maintainer - because they abandoned its organization - then it no longer benefits from this assurance. That seems unlikely, but given how this change has been going so far, it's tough to give Docker the benefit of the doubt.

The problem is with the scale of punishing an entire company, though. There's a lot of fallout from that, it's true. So the punishment would need to be fair, limiting the offending entity as a whole without unduly harming innocent employees. This could be where the analogy breaks down (which argues towards how unfair the personhood of corporations is, if there's no good recourse for wrongdoing).

As for a chilling effect ... yeah, that's the idea. Employees in a company would be very much more interested in staying on the right side of the law because of the heightened risk to, well, everybody.

I'm reminded of businesses that need to stay accredited, or licensed, or otherwise in legal compliance with something in order to function at all. If one errs enough (criminally, say), it loses that blessing, and could end up folding, and all the innocent employees are out of a job.

I can't tell if the idea makes much sense, but there's a symmetry there, specifically around the personhood of corporations.