I'm going to start an opinionated overflow thread for the previous discussion (https://futureofcoding.slack.com/archives/C5T9GPWFL/p1599588394135900) Why programmers shouldn't program for themselves (my editorializing) Focusing on "quantity of programming" feels like the wrong frame. My ideal society of people educated in programming may not involve most people actually doing much programming most days. What matters is the potential. Compounding advantages from programming for one day per year. * Impulse to generalize is self-limiting (some maintenance burden may be irreducible). A good end-user computer needs to be extremely parsimonious in out-of-the-box capabilities, and leave lots of space for users to "pollute" it with what they care about. Give people space to make mistakes, raze things and start over. If it's too built-up, it discourages experimentation and customization. * Baiting big to catch small. (https://xkcd.com/1319) The long tail of manual tasks are not really economic to automate just for oneself. * First-world problems. Until we get good sensors/actuators, programming is kiddie-pool stuff for the most part. "I wrote a script that lets me open projects easily so that I can write more scripts." There's more to life. (Not for me, but for most people 😄) Why programmers don't program for themselves (snapshot summary of the previous thread) * Interoperability limitations. Between any putative new script and other devices, platforms, programs. * GUI limitations. * Operational/maintenance burden (Ivan Illich). Keeping up with security advisories, for example (https://mastodon.social/@akkartik/104790515855023278) * Programming for employers sucking up all the oxygen. Building for oneself is economically invisible in the current paradigm. (Thanks @Konrad Hinsen.) * Long-term trend towards locked-down, consumption-oriented devices. Morlocks turning Eloi. * Lack of DIY culture. Programming for others may be poor preparation for listening to one's own needs (e.g. https://mastodon.social/@akkartik/103994830568601931). Perhaps the original sin was framing programming as driven by exernal "requirements"? But computers always had to start out expensive; hard to imagine how we could dodge that bullet.. * Fragmentation in incumbent programming models. High barrier to entry for exploring new programming models. * Poor discoverability/unmemorability/anti-memorability. (Bullets are not disjoint, just interlocking/overlapping frames I've been finding useful.)

As someone who comes from the antediluvian era when personal computers were personal, that was one of the most depressing threads I've read since joining this community. 😥

Yes! Sadly. The more I learn about that "antediluvian era" the more I think we have this whole thing backwards. Back then, people like Alan Kay were trying to figure out how to make computers work for everybody. "Programmer" was just a synonym for "computer user". But then we somehow accepted the idea that it's better to distinguish between so-called "experts" that can create all the software for "not experts" to use, even though these "experts" knew nothing of what the "not experts" really wanted to achieve. Primarily it seems, so we can sell a sh*tload of products and turn a planetary-scale nuclear attack-proof knowledge-sharing computer network into a shopping mall. The result is that now everything is so complicated that not even the "experts" find it feasible to do most things with a computer themselves, and the "not experts" are now convinced that they can't possibly learn how to do anything useful with computers unless somebody else creates it for them. We should've never stopped trying to make computers work for everyone. And we should've kept talking about the "medium" aspect of computing more.

@Stefan (last paragraph) have you expanded on it elsewhere?

@Ricardo A. Medina I have a lot more thoughts about it than I have written down anywhere (yet?). Every once in a while I keep rambling about it here. What I did write down elsewhere is this: https://stefan-lesser.com/2019/12/13/democratize-programming/

@Jack Rusher Regarding the thread being depressing, I personally am more hopeful after the realization I made here https://futureofcoding.slack.com/archives/C5T9GPWFL/p1599666723187800?thread_ts=1599588394.135900&cid=C5T9GPWFL That I think a better place to look at how programmers use programming for themselves is to create things to share with others. E.g., it seems to me that things are like personal sites and side projects (sharing) are much more common than using programming to improve personal productivity. Correspondingly, it seems to me that the most fruitful area in end-user programming would likely be in making it as easy as possible for non-programmers to share their creations with others. I think the history of the web also reflects this, with the move towards services that remove the technical hurdles to sharing (e.g., Twitter/Medium, for better or worse) and the current no-code movement.

I am from that antediluvian era as well, my first computer (https://en.wikipedia.org/wiki/Colour_Genie) was so personal that it didn't even have any connection to the outside world other than via physical artefacts (cassette tapes). But I never left the universe of end-user programming. All the software I write is for my own use. Often published for sharing with others, but never written exclusively for that purpose. From this perspective, the evolution of the last 30 years looks like computers becoming ever more powerful and at the same time ever more difficult to use. I spend more time today on administrative overhead (software updates, ...) than I did 30 years ago.

Related to Roben's point, I've always thought it should be easy to share workspace customizations and the like as well as code. Config packages should be easy to create, install, and uninstall.

@Andrew F I think the right way to share workspace customization is as "naked code". Copy-pasting fragments. One link from my OP above is relevant: https://mastodon.social/@akkartik/103994830568601931. My argument goes like this: * Settings often grow in an unruly fashion compared to codebases. We're more careful about organizing modules in a repo than we are in adding knobs to a config file. Even though the modules are internal details and the config file is externally visible. * Settings in config files often depend on each other in subtle, hard-to-debug ways. * Creating packages to manage customizations requires dealing with these dependencies. That creates a lot of bloat to sense lots of different combinations of settings and behave appropriately. * The bloat hinders further customization. People start to rely more on packages created by others, and the muscle of doing your own customization atrophies. Bottomline: If you make something look polished, people will assume someone else should make it. If you make it look half-assed, it will encourage, even beg for, helping oneself. This is a case where worse is actually better, not just pragmatically but really.

@Konrad Hinsen I, too, still write tools for myself constantly, including little 10-15 minute programs meant to be thrown away. All I could think looking at that thread is that if one's normal toolchain makes producing nonce personal code that difficult, something has gone terribly wrong. @robenkleene The first time we used Maria.cloud to teach a class of novices we added a feature where any "cell" in a notebook could be shared as a an "app" -- a view onto the whole notebook via an interactive graphical cell -- with a single mouse click. At the end of the first day everyone had made a game or some art, and they loved sending around their creations. It was great. So, yes, this is definitely something "non-programmers" (rather, not yet programmers!) respond to quite readily.

Aye aye aye, what a cool idea, a social networking platform based around sharing little interactive bits of code. Twitter x CodePen

@Kartik Agaram you argument is compelling for text config files as they are today. However, looking to the future, blobs of text config can't be the only way people make customizations. The whole hidden dependency thing especially needs to die (that alone would take you a long way). Basically what I mean by "it should be easy" is that the obstacles in your post should be defeated. :)

Totally agreed. But it's not really about text. In fact, text helps here because it's still easier in 2020 to throw text into a random text box than it is to attach files to it. The real problem is the indisciplined dependencies, and it's a devilishly subtle problem. For the obstacles to be defeated we need somehow for everybody to do "the right thing" -- even after we figure out the rules of engagement. I don't know how to even start attacking that social-organization problem. In the meantime, it seems to me the best way to share customization is to encourage sharing what works for you, with the expectation that others will need to tweak it to get it working for themselves. It's fiddly and annoying, but still on balance better than the current world of pervasive learned helplessness.

I don't think the explanation even needs to be specific to programming. There has been a long-term trend towards people doing less and less for themselves, and instead satisfying more and more of their desires through market interactions. Cooking, cleaning, basic repairs, altering clothing, music, story-telling etc are all often outsourced now. End-user programming is swimming against that tide. Maybe there is inspiration to be found by looking at surviving knots of diy culture, where people are still interested in learning new skills. Eg my old housemate used to hang out at a community carpentry workshop.

@Kartik Agaram I disagree about one point: your argument is all about text. In a universe where people share small pieces of code for inspection and adaptation to their own needs, it is crucial to have a representation that is universally supported by communication media, and that means text. I actually guess we all agree that it means text for now, but my claim is that this is not going to change. Text is the dominant mode of time-delayed communication between humans, with pictures taking the second place and everything else (voice recording etc.) lagging far behind. Therefore text is going to be the preferred medium for the kind of interaction you describe for a long time. Perhaps we will develop picture-based communiction with machines to the point that it can complement text, but that's no more than a dream for now. What made me realize the importance of text-based representations is my recent involvement with Pharo (i.e. Smalltalk). When interacting with a Smalltalk system, text is used only at the most fine-grained level, inside a method. But that means that discussing Smalltalk code by e-mail or in discussion forums is very cumbersome. People end up using constructs that are legal Smalltalk code but which nobody ever uses for code development, such as creating classes by sending a message to another class. This creates a serious disconnect between human-computer interaction and interhuman communication.

I've been trying to keep an open mind and work against my pro-text bias, but I'll be very happy if that's not needed 🙂

Re: DIY's passing, I sometimes wonder whether having an entire industry competing to building seductive simulations of personal development might be interfering with the actual personal development of human beings. Or, to put it another way, how many music lovers have spent more hours playing Garage Band than it would have taken to learn how to play and form an actual garage band?

The killer features of plain text are collaboration and sharing. One pet theory is that one reason for the incredible popularity of visual programming languages practically everywhere except for software development (e.g., https://twitter.com/robenkleene/status/1280182521796399106) is that most those are areas much less dependent on collaboration.

@Jack Rusher I saw some back of the envelope math recently - if it takes about 1000 hours to become competent (not expert) at a skill, and the average american watches 4 hours of tv per day, then the opportunity cost of tv is 1.5 skills per year.

@jamii 1000 hours must be about deliberate practice, which is highly demanding and you can't put too much of it in a day. You can't easily replace 4 hours of watching tv with 4 hours of high-intense practice. But replacing 4 hours of tv with 30 minutes or an hour of practice should be fine. But on the other hand, I don't believe you need a thousand hours to be competent either. My guess is 100–500 hours depending on the skill. That should give you 1–3 skills per year. So yeah, tv is huge waste either way.

what a cool idea, a social networking platform based around sharing little interactive bits of code. Twitter x CodePen

You mean like http://www.bashoneliners.com?

@jamii It's funny I was actually talking about this with a few friends and we sort of all had the opposite experience. Not sure if we're part of the same generation. We found that the generation of our parents (born in the 50s early 60s) didn't have a DIY culture at all. From real experience: • If you're bike is broken : Parents => bring it to the bike shop Us => Watch a youtube tutorial • You want to organize a trip: Parent => Contact a local travel agent Us => Do some research, go on Sky Scanner, try to find local guides, booking.com... I was also talking to my step dad about it, who was also leaning to the same conclusion, He was amazed that kids of our generation all seem to cook. He is a city guy from Italy, he never cooked for himself. Being a bit counter-cultural he associated cooking yourself with the older more repressive generation (he was a bit of a hippy). And maybe we are doing the same things he did, we cook because our parents didn't. I think there might be some vertical and also horizontal cultural differences. Most of my friends come from cities/big towns and we are Europeans. There might be different shift depending on your generation/location.