Al Sweigart is a software developer and tech book author in San Francisco. He has written several Python books, which are available under a Creative Commons license at https://inventwithpython.com
Al Sweigart
| Follow @AlSweigart
United States
Authored Comments
Hi, author here. I just found that this article was posted to Slashdot back in September. A lot of those comments seemed similar to the kind I saw on Reddit: universally dismissive of the articles premise. Which would be a learning experience but I saw again and again the commenters were referring to things they assumed the article said rather than what the article does say. (Like, I can copy and paste exact sentences from the article.)
So to clarify these misconceptions, let me just go through a few of the more popular critiques:
* "Everyone won't become software engineers."
I agree, and say exactly this in the article.
* "Popular programming won't replace software engineers."
I agree, and say exactly this in the article.
* "Programming is beyond most people's ability."
I disagree, and the same would have been said hundreds of years ago about literacy. If anything, programming easier today than it was in, say, the 80s. Computer science will always be hard; writing small scripts to automate tasks is easy and becoming easier.
Take a typical office worker thing like email: You don't have to be a computer scientist to set up Outlook email rules. They're a series of "if the sender is this and it contains the word foo, mark it as read and put it in this folder". Extend this (incredibly helpful) feature to other applications and web services. It's not writing a 10,000 line app with complex data structures. It's an incredibly useful way to specifically configure the application.
* "People would rather just buy a $5 app than write their own app."
I agree, and I don't claim that the average person will write their own Facebook app. But individuals will have their own needs and workflows _on top of_ their Facebook app, or their email client, or their spreadsheet program. "The app already does this, I just want it to do that with this other thing." These last-mile features are too insignificant of a market for professionals to make, but significant enough to that one user for them to cobble together a script for.
* "Everyone has cars but aren't mechanics."
Moving from the state of "broken" to "working" is different, and much narrower, than wanting to configure a computer to do some custom action. And this massive range of possible configuration is what makes a computer different from an appliance like a car or refrigerator or skills like wiring a house. If computers didn't have this large, flexible potential of use, then computers would be no different from cars and only a few "mechanics" would be needed.
I'll have to add a post-publication clarification: when I said in the article that people will learn to debug, I mean that they will debug their own code. Not that they'll be debugging code written by others or submitting pull requests for professional software.
* "Amateur programmers will write terrible, buggy code with security vulnerabilities."
Snarky reply: So it'll be the same as professionally written code, then.
Sincere reply: The programs they write will be of much smaller scope. Most often these will be limited scripts that automate simple tasks, not control nuclear reactors.
* "Amateurs will write inelegant code that is impossible to maintain. They start small, but then the company becomes dependent on it and then eventually has to spend tons of money to replace it."
Snarky reply: So it'll be the same as professionally written code, then.
Sincere reply: Good. There was obviously a need for that shoddily-written script and it was an improvement on what was there before. And if it wasn't worth the cost of replacing, then the company simply wouldn't replace it. But that shoddy code is what grew the company and made these growing pains possible in the first place. If that's terrible, you might as well argue that we should have never developed agriculture because it led to modern day problems.
* "In the 70s if you owned a computer you had to write code for it. But computers are becoming more like appliances and won't need to be programmed."
Programming is much easier and computers are much more relevant to culture now than they were in the past. This makes it possible to have programming as a casual skill rather than a job-related specialization or only for hardcore hobbyists. Meanwhile, because of the internet, there's a lot more you can do with a computer now than decades ago. Also, see my "last-mile" bit above.
* "We tried this already with Visual Basic and COM. They didn't take off."
One, this was in the 90s before the internet made computers relevant to mainstream users as a social tool and Google made it easier to learn about these tools. Two, HTTP is far more universal setup for APIs than Microsoft-only COM (or other API schemes) ever was. I don't know what future programming languages and protocols will look like, but I know they'll be more relevant and usable than the ones we have today, not less. Otherwise we wouldn't have switched to them.