@BoydStephenSmithJr @inthehands It's interesting and instructive to try to derive this.

My code is read in earnest by maybe, let's say 10k people, and run by about 2 billion. So a shallow analysis would suggest that for this to be true, we need to derive about 200,000x more value from reading than from running.

However!

Many of those people who read it then go on to change parts of it, which creates a feedback effect where the 10k influence the 2B.

Difficult to figure out where crossover is.

@Catfish_Man @BoydStephenSmithJr
Yeah, trying to model this quantitatively goes into a bunch of deep holes very fast, full of counterfactuals and hard-to-measure cognitive effects. How do the benefits of writing for readability (or costs of non-readability) accumulate over time? Forget the constants; what kind of •curve• is that? What is the effect on the •author• of these things — not just their efficiency, but their thought process, their ability to solve the problem? What are the social effects on team cohesion, code attracting contributors? How does this change “black swan” events in the form of rare but catastrophic failures of code? etc.

I like the quote as a subjective statement, a statement of values — and I’ll leave it there.

@inthehands @Catfish_Man I think it's not about the reader:runner ratio. That's a red herring.

It's about the writer:reader ratio and minimizing effort. It's the same reason that one-to-one email conversation is fine in TOFU format, but mass email discussion (whether you use mailing list software or not) is best done with the context above the new information, either has a single group or, if there's multiple trains of discussion going on, the "interleaved" style.

If your software is ever going to have more people reading it than writing it, reading it should be easier than writing it. (And, if you are ever going to get more writers, you will have more readers than writers [potentially MANY more].)

@BoydStephenSmithJr @inthehands

Gotta say I don't buy this argument. The red herring is the idea that the developers of the code are the only ones with an interest in it. Different code produces different results for end users, and we have a tremendous responsibility to them.

Focusing on readability is often (usually? always?) still the right thing to do, but it's *for* them.

@Catfish_Man @BoydStephenSmithJr

This is the thing. And there’s lots of stuff that is for all humans affected by the software in the long term that is only immediately visible to the developer. So we ask questions like:

- Does this code help us understand what it actually does?
- …what its makers •intended• for it to do?
- Does help its makers •think• about both those things? About mismatches, hidden assumptions, unforeseen consequences?
- Does it lend itself to future change, flexibility?
- etc

“Readability” is both a shorthand and a reasonable starting place for all of the above. It’s a way to refocus on the humans.