It has come to my attention that this is essential lore. I've only just seen it. Always Already Programming

Everyone who interacts with computers has in important ways always already been programming them.

This is quite provocative, I found it stimulating. Rambly musings follow. I'm thinking of programming as a spectrum, with "consumer" on one end and "creator" on the other - the spectrum being how much choice you get to make? Fundamentally yeah, writing JS is "similar to" clicking a button in that you are asking the computer to enact certain built-in behaviour. And so on down until you're designing your own silicon. But JS and the web platform give you a lot more buttons to push, a lot more latitude of options for what you want to create. And so then goes going native and writing assembly etc. A given person doesn't sit at exactly one point on the spectrum. It depends on what they're interacting with at that moment, and even in one session they might swing back and forth across the spectrum. Maybe neither end of the spectrum is necessarily superior, though personally I'm biased to enable more people to be creators more of the time. But e.g. lots of business software is written specifically to enforce that e.g. salespeople remain firmly in a specific (consumer) region of the spectrum. So there will always be demand at that one end of the spectrum; businesses don't want to give salespeople the equivalent of unrestricted CPU time to do what they please. 🤔🤔🤔🤔

yeah. this notion clearly points at "business" as the evil here. if business wants people to have fewer, worse buttons, then business isn't worth our time and energy.

Agreed!

It’s a really precious manifesto to have on hand. Lucy Keer has an interesting response to it, which I drew on for my blurry paper. (I’m presenting that at PLATEAU on Tuesday!)

i like that this bit from the beginning of lucy's post…

Nevertheless I think I want to say that the distinction between 'programming' and 'using' _is_roughly in the right place, that clicking a button actually is different enough to pasting someone else's premade code in your click event handler for that same button that it makes sense to call the second one 'programming' and not the first. (I could change my mind on this.)

…is somewhat invalidated (or, better, superseded) at the end of the post. It feels like she's thinking as she writes. I like this style — it feels like I'm thinking through it with her as I read.

I'm sympathetic to this perspective, especially from the standpoint of designing systems that make it more true. However: If you're going to talk about pushing buttons and renaming files as "programming", you need to start thinking about the language in which you're programming, and the expressiveness of that language. If pushing a button is programming, it's programming in a language with only one, maybe two possible programs, "yes push the button" and maybe also "don't push the button". Renaming files or setting calendar reminders have more entropy in their inputs, but still not much flexibility in how they interact with themselves or the world, not much complexity in the possible outcomes they can create. Spend much time here and you find yourself re-inventing automata theory. Different kinds of automata have different kinds of programming with wildly varying demands and outcomes. There is at least a trivial sense in which pushing a button is programming, but its properties are so vastly different from anything Turing-complete or Pacman-complete that there's not a lot of practical mileage in comparing them. (Pasting code into a click handler is not actually that interesting of a case IMO. The interface clearly supports programming, but the copy-paster didn't perform much if any; rather the party(s) who created the snippet did the programming. We could quibble about whether choosing which button handler among many to paste in constitutes programming.)

is this about missing view models again? 😆 Like facet here is having programming text vs GUI action. Another, that's maybe a little interesting is about the assumptions of the UI that make customizing difficult, usually things like there can only be one whatever on the screen.