Conversation

Notices

1. Embed this notice
   Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 05-Jun-2026 12:38:36 JST Paul Cantrell

   RE: https://social.treehouse.systems/@wwahammy/116695372319811855

   This!! I am yelling this too!!

   And it’s yet another one of the things where now when I yell it, I have to add that it’s something I’ve been telling students and companies alike since long before the release of GPT:

   “Generating code is by •far• the easiest part of programming.”

   “No matter the source, don’t let code into your project unless you understand what it does.”

   “Programming languages exist for humans to communicate with other humans. Code does not just make machines go; it encodes and reifies human mental models. Good code communicates •intent•; very bad code has no coherent intent at all.”

   and so on

   • Embed this notice
     vashbear (vashbear@hachyderm.io)'s status on Friday, 05-Jun-2026 12:58:10 JST vashbear

     in reply to

     @inthehands

     In principle I like this.

     But in practice. -even before AI - how often did you use a library (paid or open source) that you just trusted worked?

     Did you understand every single line of all its dependencies?

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 05-Jun-2026 13:02:35 JST Paul Cantrell

     in reply to

     • vashbear

     @vashbear
     It’s a good question. The maxim does not apply to the transitive closure of all dependencies! It applies to code you are bringing into your •own• project (and thus taking on the responsibility of maintaining). To introduce a dependency is to delegate responsibility for understanding and maintaining that particular code to other people, which is a form of trust. Of course trust is no guarantee of anything, and trust can be broken and can be misplaced, but trust is still necessary — both to have computing to have a society.

   • Embed this notice
     Boyd Stephen Smith Jr. (boydstephensmithjr@hachyderm.io)'s status on Saturday, 06-Jun-2026 06:02:20 JST Boyd Stephen Smith Jr.

     in reply to

     @inthehands "Programs must be written for people to read, and only incidentally for machines to execute."  - Harold Abelson

   • Embed this notice
     David Smith (catfish_man@mastodon.social)'s status on Saturday, 06-Jun-2026 06:40:40 JST David Smith

     in reply to

     • Boyd Stephen Smith Jr.

     @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.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Saturday, 06-Jun-2026 06:40:40 JST Paul Cantrell

     in reply to

     • David Smith
     • Boyd Stephen Smith Jr.

     @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.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Saturday, 06-Jun-2026 06:41:47 JST Paul Cantrell

     in reply to

     • John Colagioia

     @jcolag
     Yup. I believe I have even used the phrase “code is sort of a necessary evil” with students.

   • Embed this notice
     John Colagioia (jcolag@mastodon.social)'s status on Saturday, 06-Jun-2026 06:41:48 JST John Colagioia

     in reply to

     @inthehands My current line for this in discussions is that code is the necessary evil in the system. The work is to understand people and help them, but you can't ship caring...

   • Embed this notice
     Boyd Stephen Smith Jr. (boydstephensmithjr@hachyderm.io)'s status on Friday, 19-Jun-2026 07:30:55 JST Boyd Stephen Smith Jr.

     in reply to

     • David Smith

     @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].)

   • Embed this notice
     David Smith (catfish_man@mastodon.social)'s status on Friday, 19-Jun-2026 07:43:50 JST David Smith

     in reply to

     • Boyd Stephen Smith Jr.

     @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.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 19-Jun-2026 07:43:50 JST Paul Cantrell

     in reply to

     • David Smith
     • Boyd Stephen Smith Jr.

     @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.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 19-Jun-2026 07:44:37 JST Paul Cantrell

     in reply to

     • David Smith
     • Boyd Stephen Smith Jr.

     @Catfish_Man @BoydStephenSmithJr

     I do agree with Boyd that much depends on the life and context of the code. Data analysis that needs to work once under author supervision has different code readability + quality needs than, say, an OS kernel.