October 24, 2023

I wish people would do historical arguments better

Just because the historical context for a practice was different doesn't mean it's useless in the current context

There's a common argument I hear that goes like this:

• Pull requests were originally intended for low-trust environments, so we shouldn't use them on tight-knit teams.
• Open source was originally coined to be palatable to corporations, so we should write Free software instead.
• The web was originally for sharing text documents, so we shouldn't use it to run apps.
• The wheel was originally developed for shaping clay, so we shouldn't use it to move things.

Okay I haven't seen the last one yet but it's the same kind of argument. All of these look at the historical context where a tool or practice arose, note that it's different from the current context, and conclude that it's unfit for its current purpose. I'm a firm believer in understanding the historical context of our practices, and I think that it does have weight in evaluating our current practices. But arguments based on history can be a bit misleading if you don't look deeper into the actual history. There's more work you have to do.

First of all, you have to establish what changed between then and now. Take the argument that "the web was originally for sharing documents". The World Wide Web entered public domain in 1993. Macromedia Shockwave came out just two years later. For 93% of the web's total life, at least, the public used it as a universal platform. So saying "the historical context is different" just tells us that the "original intention" badly mispredicted how people wanted to use the internet.

You also need to understand how the current context and how people use it differ. The common historical argument against pull requests and code review:

I see pull requests as being a way of gate-keeping in low trust environments like an open source project. Why would we (developers) adopt pull requests on our teams yet we don't consider our team/workplace being a low trust environment?

I could totally believe that pull requests were originally a means of (mission-critical) "gatekeeping in low-trust environments", which are different from how companies develop software. But then I'd ask are companies using pull requests as a form of gatekeeping? Or are they adapting the form to their own needs? Like at all the places I worked, PRs were used to bundle fixes for an issue-tracker bug into one changeset to get a trail of what was fixed, when, by who. That's a really useful thing to have! Also, I can trust my team but still use PRs as a way of getting a fresh pair of eyes on my changes, to make sure I didn't do something boneheaded or introduce a subtle problem only the deployment/security/performance expert would notice. My current context is different from the historical one, but I've also adapted the tool to fit the current context.

(You could respond with "you can do that with PRs but pairing/mobbing is better for those things." And that's fine, but we should discuss that with respect to how PRs are used, not how they were originally used. Plus, if things have been adapted before, perhaps there's further adaptions we should be looking for, too?)

Reading this, I feel like there's a third thing you-gotta-do that I'm missing, but I'm not seeing it.

How to do it better

I think I did a better job with my post Why Do Interviewers Ask Linked List Questions, which argues that companies originally asked linked list questions to gauge C experience, and then we sorta just kept asking them. I never actually say "so we should stop asking them" but I really strongly implied it so it's the same kind of argument. Here's how I addressed my two objections:

1. How did the context change? No hard evidence (history is cruel like that), but I wrote six paragraphs arguing that it was due to Joel Spolsky + Cracking the Coding Interview.
2. Do people use it differently now? I claim the only difference between then and now is that people say it's about "CS fundamentals"/"reasoning through problems", and that these questions are bad tests of reasoning.

(Still not seeing that third thing.)

My point is that you can do a historical argument well, and you can do it poorly. So you might as well do it well.

---

Misc Project Updates

• The Graph Project is going well! I've interviewed three people so far and am starting to build some theories on why we don't have graph libraries. It's also got me deeply curious as to why all modern languages do have mapping types. Like from a historical perspective, not a use-case perspective.

• Logic for Programmers is far behind where I want it to be, and I don't think it'll actually be worth money anytime soon. My current plan is to release a free online website end of this year / early next year and then offer a PDF/print version to anyone who wants to pay.

• I got like eight blog posts that are near- or at- first draft level, and I just need to stop being a perfectionist and finish them.

• I've started posting "sketchpad" ideas over on the Patreon. Some of them might become blogposts or newsletters later.

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.