Unified versus Split Diff

I don't necessarily disagree with you, but I don't agree either.

A typical workflow should be:

1. Engineer writes code 2. Engineer does manual and automated testing to verify things work correctly 3. Engineer commits, pushes, and creates a PR/MR 4. CI runs test suite 5. Another Engineer reviews PR/MR 6. Approval causes merge which causes deployment to staging 7. QA 8. UAT 9. Repeat steps 1-8 until everybody is happy

In this, we need to place checks on #1 and #2.

In my eyes, QA and UAT are superficial reviews/sanity checks on #2.

#3 is a check in #1. However, it relies on A) previous engineers implementing good tests and B) the current engineer doing the same. This means trusting people are doing the right things, but a Review implies you don't completely trust that.

#5 is a check on #3 and #1. They're essential. Having a full understanding of what the code looks like is more important in my mind than what was actually changed. The changes don't show how other code is interacting with those changes (which should be, but isn't always, captured by unit tests).

That's why I think the article author's preferred view is ideal. In fact, that's roughly what I work with when reviewing without realizing it (diff in GitLab/GitHub/Sublime Merge, code in JetBrains where most of the review happens).

* everybody is good at breaking down code into changes small enough review quickly but not small enough to become tedious and trivial

* people work on CRs whenever they have time. They do generally not post them after people have started going offline, and wait til next morning as a courtesy, since there is no difference between publishing for review at 5pm vs 9am the next day

One side effect of this workflow is that because the pieces are more manageable, less uninterrupted “flow” time is required to complete a bunch of small things than to make one really big change. And others digest the smaller changes easier and knowledge spreads more effectively. And with the time its easy to say “don’t make people review outside working hours.”

Split diffs align well with modern "papier mache" development, where the goal of a task is to paste the smallest possible change onto whatever existing structure. Participants don't need to understand the whole structure and are expected not to alter it. Module refactoring is strongly discouraged and postponed until there's no other way to proceed on a critical feature. Designing (or refactoring) with an eye for future tasks is considered pointless because nobody understands which JIRA tickets are likely to survive and which will get purged or indefinitely backlogged.

When all you're supposed to be doing is overseeing Copilot as it drafts a new call to your upstream service and adds a perfunctory test that never fails, a split diff does a perfectly fine job of reviewing that work.

Whether this workflow represents durable, quality engineering or is just a way to LARP Katamari Damacy and get paid for it is another matter. As the enshittening continues year after year, it sure tends to look like the latter.

This essay is good food for thought, but it's just a peak into the dark forest that "move fast and break things" has been leading us into.