This is a really impressive amount of effort. Every entry has a fairly even quality to it...screen grabs and contextual descriptions of even one-off episodes of television shows, yet alone decades worth of movies.
In some cases, reviewing PR diffs commit-by-commit (and with the logs as the narration of the diff-by-diff story) is a substantial improvement over reviewing the entire PR diff. Concrete examples...
* A method or function that has code you realize needs to be shared...the code may need to be moved and also modified to accommodate its shared purpose. Separating the migration from any substantive modifications allows you to review the migration commit with the assistance of git's diff.colorMoved feature. It becomes easier to understand what changes are due to the migration, and what changes were added for more effective sharing.
* PRs sometimes contain mechanical work that is easy to review in isolation. Added or removed arguments, function renames, etc. No big deal if it's two or three instances, but if it's dozens or hundreds of instances, it's easier for the humans to review all of those consistent changes together, rather than having them mixed in with other things one has to reason about.
* Sometimes a flow of commits can help follow a difficult chain of reasoning. PR developer claims that condition X can never occur, but the code is complex enough that it's difficult to verify. However, by transforming the code in targeted ways that are possible to reason about, the complexity might be reducible to the point where the claim becomes obvious. One frequent example I see of this is of function/method arguments that are actually unnecessary, but it wasn't obvious until after some code transformations.
I'm not willing to cede the point on hardware design for as long as their primary mouse product cannot be charged during use. It's such a simple and obvious mistake, like a throwback to the days of hockey-puck mice.
The comic pokes fun at the ridiculously cruel babelfish puzzle. Which, I'm proud to say, I solved back in the day without assistance, after a full day's worth of effort, and requiring at one point to completely restart the game because of an apparently useless item I didn't pick up at the very beginning of the game (if you've solved it, you'll know the item I'm referring to).
But...while that was a nice achievement, I still got stuck later in the game, trying to fix the Nutrimatic.
I left Slashdot for HN...but I didn't leave Slashdot because of HN. I was frustrated with Slashdot and was actively seeking alternatives. About 2 days after I discovered HN existed, I was done forever with Slashdot.
Among other frustrations (including some really vile comments), I felt like the world was bursting with interesting tech news, and Slashdot was just not keeping up. The publish rate was too slow (maybe 10-13 stories a day), and the %age of stories I found interesting had dropped considerably from a few years previous.
I wasn't a fan of the redesign, but it was content that drove me to seek alternatives.
Growing up in the 70s, among the things I sought out in our house to play with was an old manual typewriter. It was endlessly fascinating to me. I liked playing with all of the mechanical bits. Trying to jam keys, working the carriage return, scrolling paper through it, pressing the Shift key and looking to see how it moved the entire basket of typebars, overtyping to make new characters, watching how the ribbon advanced with each keystroke and rewinding it by hand, etc. One thing I had forgotten, which was mentioned in this article, was figuring out how to set tab stops, which allowed me to either stutter the carriage across, or make it fly free from one end to the other.