I deliberately make tiny investments in learning opportunities for me and my colleagues.
Yesterday I was reviewing a PR which had a large number of edits to data using a few patterns applied in many places. Unfortunately, the edits were embedded in non-trivial contexts which made the diffs less easy to eyeball than I might have hoped.
Here's an invented example that gives a flavour of the problem. The first line is an original, the second an edit:
+ (ab)038458345023421-5-7345234
Actually I haven't quite set that up right: the diffs were easy to eyeball, especially given coloured highlighting, but I know from experience they're also easy to wave through after a cursory skim which misses something. And this data is important to get right for regulatory reasons.
Fortunately, I know a thing or two about quick checks, so ... I pulled the branch and, at the terminal, applied the expected change patterns to the original data and compared that to the PR's content. Something like this gives the idea:
$ git diff | grep "^- " | sed 's/(ab)3/(ab)03/' | sed 's/D$//' | sed 's/-/+/' > mychanges.txt
That series of calls finds out what the PR did (git diff), filters to just the removed content (grep), then applies changes (sed, sed, sed), and stores the result in a file (>). I could then use a couple more calls to compare that to the whole changeset:
$ git diff | grep "^+ " > prchanges.txt
$ diff mychanges.txt prchanges.txt
$
The empty line at the end shows that there are no differences, which means that the changes I applied are also the only changes that were made in the PR.
Naturally you're now wondering whether the PR missed some changes it should have made. Good thought. I checked for that too by searching the branch for the same patterns that I replaced using ack:
$ ack "(ab)3"
$ ack "D$"
$
There were no remaining instances of those patterns which means that, unless the author and me have both got the task wrong, we're done.
It would be easy to drop an "LGTM" in the PR and approve but I didn't do that. Instead, I copy-pasted the commands I'd run into a comment with a smidgen of context and then approved. I'd done the work by that point so this was essentially no effort and no cost.
That's the tiny investment.
And the learning opportunity? Well, perhaps the author of the PR will notice that I made a poor assumption, misunderstood the task, or overlooked an important case, and then I'll learn something. Or perhaps they'll realise that they made the mistake and we'll both learn something. Or maybe they don't know these tools, or never thought to do what is essentially a cheap throwaway reference implementation to check their work and they'll take that forward with them.
Or perhaps they never look past the approval, don't see what I did, and just merge this boring housekeeping task that's really someone else's job and move on with real work. That's OK. My evidence stays there and, if we later find a mistake, future archaeologists seeking the cause, and me, get the same opportunities again.
I generally believe in open notebook working and this kind of behaviour is a microcosm of that, with the chance to be educated a welcome side-effect of the public documentation. Other things that I regularly do include cross-referencing work after I've found the connections, say in Slack threads, or summarising a conversation concisely and sharing it back, or caring to log the current status of a piece of work in its ticket.
Each of these is a tiny investment with an uncertain payoff, but future me has
seen its value often enough that today's me wants to be the past me that made
it.
Image: Mizanur Rahman on Unsplash
Highlighting: pinetools