I've been thinking recently that "end-user programming" as term is overly focused on individuals as opposed to communities, for two reasons: 1) To make/customize anything worth using, it will be complex enough that you'll want/need to use pre-existing widgets/libraries that others have made in order to do it without it taking all your time. I think end-user programming biases towards languages and tools that a single person can make entirely themselves, and thus rules out the more interesting and complex software artifacts people could create. When focused on the individual user, we don't place enough emphasize on the collaboration (through using the code of others) that will be necessary to allow people to make amazing things without programming full time. 2) The vast majority of computer usage is collaborative to some extent, be it friends and family, work colleagues, clients, vendors, strangers online, etc. Only a small minority of computer use is me writing in a journal that no-one will see. Everything else is co-created and meant to be shared, or browsing what others have shared. Thus I propose deprecating the term "end-user programming" in favor of "end-community programming." My thinking on this was likely mostly provoked by @Bosmon and @Philip Tchernavskij

You've certainly gotten me thinking about this for a few hours now. I think both your arguments have holes: a) Using stuff other people made doesn't require collaborating with them. Not even in the world we live in today, let alone the more idealized one where more becomes possible. I discovered http://minimal.linux-bg.org a month ago and within 2 weeks had distilled what I needed from it to create bootable disk images of Mu. b) There's no argument that collaboration is important to any creation. It's key to what I do. But is it prime? (Me, I think preserving a sense of motivation is prime. And expecting 'collaboration' can often be motivation-sapping: https://www.teamten.com/lawrence/writings/plan05.html. I build to enable collaboration, but I treat collaboration as something you sow seeds for and wait a long time to see bear fruit. Collaboration shouldn't be on the critical path. But that's just me, and this is just an example to show that there are other paths forking off where you think there's a straight road.)

Glad to have sparked something! a) I would consider this a form of collaboration that I'd like to support. Doesn't matter what it's called, I think it's key to supporting this passive kind of collaboration Here's an unspoken thought in my head that's influenced this line of thought: I normally see a strong correlation between people who are good with computers and those who like to work alone. I am one such person. I hate teamwork. I think this is partly because I am so augmented via a computer (which Engelbart designed to augment the single human) and much of that augmention disappears in a team setting, such as a spoken meeting, where I can't Google and precisely unpack assumptions and arguments and other pro tools. Thus teams are where I am weakest, so I avoid them. But that's also a huge weakness because teams are really powerful. What if computers were designed from the group up with the team usecase prioritized? I don't want to throw out the personal computers we have but maybe a new kind of interpersonal computer (maybe like Dynamicland) would be a great addition, and so I'm beginning to put my focus there

@stevekrouse I was a bit surprised by your first point because in my experience, starting with a blank slate is a rare event in any category of programming I am familiar with, with the possible exception of exams. Even when I write a small Python script for a one-off management task from scratch, it's based on existing executables, an existing file system layout, etc. Which means that discovering and understanding what's there is usually the first step in any programming project, and that is why I am such a big fan of @Tudor Girba's Glamorous Toolkit.

I'm confused with your interpretation of my first point. It seems like we agree: coding is always remixing others' work

Once we enter into the era of interchangeable parts - and we aren't there yet - then individual creations, even large ones, will be more common instead of the "mash-up" messes that are so common to GitHub. With better languages and tools, it will be possible for regular people to create large complex systems that would have taken teams beforehand. I built some very large programs all by myself, but it took a huge amount of effort, and i had to write really tough missing pieces; once we have the lego pieces set up right, it will be way easier.