Don't Learn to Code, Learn to Program – But Come Back in 10 Years (opens in new tab)

This is an entirely pointless false dichotomy. "Coding" and "Programming" are just synonyms of the same damn thing: make a turing machine do stuff. I have no idea why people are suddenly trying to make a false distinction when there was none for decades and decades, but frankly it's stupid. My only thought is there's a bunch of butt sore guys who are upset that learning to make a computer do stuff is nothing special and are now trying to find a new way to differentiate themselves with the moniker "Programmer" and looking to shit on anyone who's "Just A Coder".

So I propose a new term. Turingulate: verb. Making a turing machine do stuff. Typing Python into a file and running it with python? Turingulated! Running a PD graph to create a fuzz pedal? Turingulating! Using Max/SP? Turingulating! Programming because you're so special? Turingulate. Coding to .. uh code some ... uh code... which isn't programming? Turingulator!

So stupid.

Hold on a second. OOP, markup, APIs, and HTML/CSS/JS are snake oil, while visual programming isn't? Say what you will about the former technologies, but they're being used for productive purposes. Visual programming is vaporware that someone tries to build every 5 years or so to no effect. Functional programming has much the same challenge, but it's getting integrated into mainstream languages. Otherwise, it would likely still be a research toy as well.

Just because something is hard doesn't mean it's broken. Nobody would say that say, advanced mathematics is broken because the layman doesn't get it.

My bullshit detector notes that he talks very generally about "knowledge workers leveraging machines". The problem with the phrase "knowledge worker" is it often means "person who sends lots of emails". You don't need to be a programmer to send lots of emails.

Real "knowledge workers", like, the kind of people that actually are working to extend human knowledge and need computers to do it, largely do know how to program to some degree (IE, scientists and mathematicians and so on). A lot of it isn't "professional" grade, but it works well enough for them and it keeps getting better.

Also a tangent: but I'm sick of the whole "coding is literacy" nonsense. Not everyone needs to code. Literacy unlocks centuries worth of knowledge in any domain you want, from contemporary thinkers to people who are long dead. Coding lets you tell a computer how to do specialized things. It's not even remotely comparable.

My paraphrase of this article:

"All of the blood sweat and tears poured into making programming more productive over the years just isn't good enough. No, I haven't done anything, personally, to improve the situation. My plan is to continue bitching about how things aren't good enough until...well, indefinitely, because bitching about other people's efforts is much easier than doing the hard work of solving a challenging problem myself."

Is that too harsh? I don't see a single concrete, actionable proposal in there, let alone anything the author has personally done to fix the sorry state of programming.

I also think it's a huge disservice for him to dissuade his friends from programming until some state of nirvana is reached in programming tools. There are some hurdles to overcome, but a little bit of programming skill can greatly amplify the reach, scope and influence of non-programming talents.

> "Programming is a notion to extend human capability, by offloading humanly-infeasible work onto a machine. It is the promise of an amplified knowledge worker. This would be worthy to learn."

With this (correct) notion the author continues until he decides that

> "Meanwhile there are few souls looking to evolve text code into something more humanly intuitive. For example something you can touch, you don’t have to read, or that tells you what the computer is thinking, so you don’t have to think like a computer yourself."

I can't help but feel that what the author really wants is some futuristic kind of AI assistant. Decades of programming progress has resulted in numerous abstractions piled on top of one another in order to minimize the amount of "thinking like a computer" that you have to do. But all abstractions are leaky and when you encounter those leaks you will inevitably have to be able to think like the machine you are trying to communicate with.

Why is it acceptable to say that effective communication with people depends on being able to think like the person you're talking to, but demand that communication with a far more different and limited machine should never require you to compromise on your preferred thought patterns? This is the fundamental fallacy of the natural language programming advocates. They want to use another entity to do things for them but demand all communication with that entity be in their preferred language, on their own terms.

I don't think we have to worry about "everyone" or even a small percentage thereof learning how to code. They won't. It's not that they can't, but it takes more than a couple of hours writing "Hello World" to do anything substantial and most people are not willing to put in the time, day after day, to learn anything substantial.

That being said, I can't imagine anything more human and more powerful than text. If I want to give instructions to a _human_, the best way I know of is to write them down as clearly as possible. If this works with a complex person, why would it not work with an incredibly simple (from an abstract point of view, not implementation) microprocessor. After all, all processors have an extremely limited set of instructions (even CISC ones).

This desire for something that is not text seems misplaced. After all, text is (IMO) certainly better than pairs of numbers indicating operation and data. Writing is one of the greatest human achievements. To dismiss it in favor of touch or something graphically visual is to disregard its power and superiority to both touch and visual systems of communication.

When designing a system, if I am able to give it commands in English (or any other language), this would be vastly superior to anything visual or touch based that I can think of or that the article specifies (or rather doesn't). To take the whole system of a language like English with its complex idea-expression engine and its vast array of words (1 million++) and discard it is ridiculous. Now, we are not currently programming in English, or anything even remotely close (though many languages' grammar follows from natural language somewhat), but I do believe this is, and has been for decades, a goal that may one day be achievable. This is desirable as humans are naturally inclined towards language and those who practice it can be incredibly good communicators (programmers of reality).

I think the author should read Fred Brooks's "No Silver Bullet". Many of his arguments are still valid after 28 years. "There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity."

Visual-based programming is definitely something that can help more people solve problems, but it gets complex to manage too (or so we've been told by blogs and others).

Perhaps something like visual-based programming would suit a different mindset altogether.

Truth be told though, programmers have managed to solve the website problem with all the new site-builders out there. They all seem to be "drag and drop", which should have been addressed long ago as a standard for at least the frontend.

Don't learn how to paint, learn how to create art. How is one without the other?

Is it satire?

Why 10 years? Given that we've known what a mess the software development world is for 50 years and nothing has improved, what makes you think anything will be better 10 years from now?

The author is frustrated by a real and frustrating problem, but he's missing why things are this way.

The "triumvirate of HTML/CSS/Javascript" isn't just a technology. It's a social consensus. It's not actually "designed" in a meaningful sense -- it's evolved.

And things pretty much need to be this way, unless you want to be an island. Even if you have the ambition and the resources to throw it all away and "do it right" from scratch, by the time you finish the world will have moved on and your perfect gem will be obsolete. Real technology is always iterative.

The same constraints apply to programming languages in general, because they truly are languages that human beings use for thinking. Languages and their associated cultures can only evolve so fast. It's not really a technical issue, it's a social issue.

The author's assertion that our "arcane" interfaces persist out of a kind of perverse pride just doesn't ring true to my experience. Programmers cry tears of joy when they get to throw away something old and arcane because they don't need it anymore. And his assumption that visual programming will necessarily be better than textual programming is completely unproven.

Anyone who could actually make programming easy would reap vast wealth. The incentive is there. If it's really a no-brainer to build visual programming tools, well, where are they? There must be something harder about it than you think if we're still waiting.

I don't the author understands programming if he sees object-oriented programming as being in the same bucket as HTML/CSS/JS. OOP is a way to deconstruct problems, just like functional programming, and their beginnings are based on very similar principles.

Any language that fully accepts the object-oriented paradigm lends itself very naturally to functional programming, and vice-versa.

I think the reason visual programming hasn't taken off is there is a very real difference between what you can express with language and what you can express visually. Images don't really contain determinate, precise statements or propositions the same way that written or spoken word does. In contrast language can express any thought, no matter how recursive or abstract, effortlessly. For the narrow domain of programming - not typesetting, not rendering and manipulating images - the text editor happens to be an extremely very powerful tool that allows us to tell the computer exactly what we want it to do. It hasn't been replaced because it hasn't needed to be - it is simply the most powerful tool in which to write language.

The other reason visual programming hasn't taken off is because programmers aren't visually oriented, right-brained, intuitive people. Exceptions to this rule abound, but I am certainly not one of them, and neither are many programmers I've known. They've tended to be left brained, linear, linguistic, rational-over-intuitive sort of people - which is why we pick up computer languages so quickly, and it's also why we like typing code into a text editor instead of drawing our program on screen. I know that functionality isn't lateralized to easily and this is an oversimplification - but there does seem to be a dispositional difference between those who are attracted to programming and those who aren't.

But this'll probably change, as everything does. As the author notes FP and lambda calculus have been around since the beginning of computer science as a field and they are just now starting to get mainstream traction. So, maybe, in about 20 years visual programming tools will start to be mature enough to applied to any arbitrary problem., and a powerful visual language will develop that attracts enough visually-oriented people to change or revolutionize the field. But we can't put the chicken before the egg - the tooling needs to mature enough to cause this network effect to occur.

I left this comment at the blog:

Perhaps coding will look like minecraft, where you dig physical paths for the water, for the chickens, and hunt down bugs with bows and arrows. Modern tablets with no keyboards do minecraft just fine (my 8 year old and all his friends are completely addicted to minecraft). Also, they can join lan games, and work in the same virtual world. This may allow multiuser programming, no? Weird thoughts. They won't call it programming either, they'll call it something like flowcraft or some such.

You only can learn how to program, if you have learned how to code. So learn how to code :)

"A relief from the unintuitive, unscalable, unfounded snake oils like OOP, markup, APIs, or the triumvirate of HTML/CSS/JS. As if these technologies are the best we can do."

At first I was mad. Then I read the above quote and everything clicked into place. This article is hilarious and I love every shrill, indignant, purposefully absurd word of it.

Probably the biggest bit:

"Can’t I just make a website?"

That type of question is where a lot of things go wrong. Newbies ask that because they don't have the experience to break it into smaller parts, experienced people get tripped up because they can't see past the "well, what type of website doing what?"--all the while the question is "what would you use it for?".

It's a bad question, because the asker doesn't know enough to ask a useful one. Our job, then, is to help them learn how to ask the right question.

There is no point in teaching something to people they don't like doing. Its a bit like forcing painting or sketching on people who just don't like doing it. A lot of schools do it, and kids who don't like painting or sketching do it real bad and become the object of ridicule.

Programming et al has a meta science its called 'making', 'tinkering' or 'hacking' or whatever you call it. If there are people who don't have a taste for it, teaching them sorting algorithms is as boring as learning math. Now common people are one thing, most people who join our industry as programmers discover they just want to do something else and go down the managerial stream.

Programming isn't for every one, just like building houses, cars, dams, or an electric grid isn't for every one. In all those disciplines common patterns of problem solution and general science are at play. Chances are if you like chasing a difficult bug and fixing it, you will also like repairing a car engine, or fixing your TV.

I have an elder cousin who runs a shoe shop for a living, he tried very hard to learn programming during the dot com boom era. He gave up in like six months. He just realized that procedurally learning something only because, every one is just doesn't work out, the problem isn't just programming. If you don't like solving problems and are not good at problem identification and opportunity identification, it gets really really boring at one point. He likes to sell things and is exceptionally good at that. Building things is just not for him. And there is nothing wrong about it.

The biggest problem with 'teach every one to code' is you have to first ask 'Do they want to learn coding?'.

The issue with every Visual programming language I have used is that while it is easier to learn for beginners, it is almost always faster to type once you start to understand programming.

I don't think programming should be mainstream, I think software should simple and intuitive enough to let anyone get work done without having to know how to write code.

I agree with the author in regards to coding web sites. It's not enough to know a just a few languages, there's a whole frickin' vocabulary of crap piled on layers of services and frameworks frosted by the JS flavor of the week.

Or just configuration. Everybody wants to reinvent Make and they all do it wrong...

There is a reason we speak and write words to communicate complex ideas rather than hold up pictures. Words are powerful and flexible. They are not going away.

When I saw the title, I thought it was, "Come back after you practiced for 10 years" which doesn't help much.

I used to think the solution was better interfaces, or making programming more accessible to the lay person. I get less sure of this over time. It seems like what we've gained in language ease of use (Python versus C) we've given back in environmental complexity. The net is better productivity for programmers, and more people crossing the divide (CS programs growing by leaps and bounds) but we're far from being there for the Everyperson. I don't see this changing in 10 years without increasing the rigor and logic requirements of our entire educational system.

The author of the article wrote it using words. He didn't make a video or draw a picture, because words were the best way for him to communicate with other humans. For some reason, he wants a different way to communicate with machines, one that is inherently not the way humans communicate with each other.

I also agree with what others have said, that this is nothing but a bitch fest with nothing actionable other than we ought to be creating visual programming tools no one wants or needs instead of doing actual work. Sure, buddy. I'll get right on that.

Man, people are so overly sensitive... it's almost like someone is trying to promote job security.

We currently have a decentralized mess of competing products. Many of them overlap and do similar things, but they all feed off of each other to improve. It is this competitive environment that improves the products and libraries we use. Anybody can identify a flaw in an existing system and build something to address it.

What this article proposes is a monolithic culture, where everything is centralized and controlled by a few entities. We tried this in the IBM/Microsoft days and it doesn't work. We end up with a single poorly documented tool that offers limited functionality.

The world of programming is more accessible today than ever before. If you are a novice, there are tools for you. If you are an expert, there are tools for you. If you are transitioning from novice to expert, there are tools for you!

This blog post would have been way better without the ranting style of writing.

It doesn't even get to the point (that programming does not have to be text-based) until halfway into the article.

The title and the objection to other people learning to code are at most tangentially related to that point. Just because there could be better ways to give instructions to machine doesn't mean other people should wait to learn how to instruct machines until those methods are developed.

For anyone interested in the prospect of visual programming for web development, please join our newsletter at crudzilla.com ... we are coming out with an update that will attempt to fit a wordpress-like plugin system into an IDE. We think that'll be a good start for a more visually oriented development environment.

Focusing on solving a problem instead of the tool is what motivates me to try new frameworks and actually code.

I agree that the focus has shifted way too much on spec. technologies unfortunately.

Again with this visual programming bullshit

Eye opening at certain points, dragged on at others. Either way I'm more excited to code. I mean, program. :)

I'm neither a coder or a programmer, I'm a code-monkey and proud of it.

is it just me or is this guy completely wrong. In my opinion languages aren't that confusing or unwieldy, the hard part about programming is the logic, not the languages.

It seems that folks here are reacting to the angst of the author as well as the literal meaning of the language used to make his point instead of contemplating what the author is trying to actually say.

Otherwise, why get hung up on definitions of "coding" vs "programming" or concepts such as "text" vs "visual"?

I think this post is an expression of the frustration that we have all reached at some point (if not many points) along the way while using any language or solution or architecture: this sucks and there's got to be a better way to get shit done!

How many times have you been working on project "foo", ran into a problem and employed solution "bar" (or better yet, created solution "baz" on your own) in order to solve your problem...only to find yourself derailed into a swamp of limitations with "bar" (that everyone forgot to mention in that awesome blog post you found)? Or, how many times have you lied to yourself and said "I'll improve upon the limitations of 'baz' in the v2 release" of your home grown masterpiece only to never return because you're actual goal is to finish the "foo" project?

The problem might be the tools or the user or the application or even the philosophy...or it might be a combination of that list plus some I haven't mentioned. Perhaps these problems have already been solved and the lessons have been lost? Or, perhaps more analysis is needed to come up with a new way around this issue entirely? I certainly don't have the answer right now but this article made me take a step backward to survey the landscape (or the wake?) of the most recent 10 years of "disruptive" (read, self-serving) technology and I feel an undeniable sense of dissatisfaction with it all.

Maybe that desire for something better just means I'm a programmer and not a coder? I don't know but I won't avert my eyes from the problem no matter how obvious it is to everyone simply criticizing the article. Awareness is the first step to understanding the problem you are trying to solve and I see people recoiling from that. Denial is a sign that a belief (or end of thought) is overruling the critical thinking process and to me that's acceptance of the status quo (not just dangerous but stupid too).

I did get a good chuckle at the metaphor provided by xerophtye's comment "you think of a pretty picture and tada! It appears on canvas!" The truth is always funny so perhaps this comment encompasses the entire article but I think it oversimplifies what the article attempts to drive toward. Sure, comprehension of the building blocks (or, the colors) allows you to build bigger and better buildings (or paintings), but, if that were truly the case, why aren't things improving? Wouldn't all of the so called experts chiming in have already built bigger and better buildings? And if so, what are they? NoSQL? Twitter Bootstrap? Ember or AngularJS? Bitcoins? Animated CSS? All I see are copies of the original idea done "my way" which is "better".

Amateurs borrow, professionals steal. And that is the process improvement methodology I see employed today.

If everyone thinks they know their craft so well, inside and out (and, for safety, let's say I don't), how might you take that knowledge (and a step back) and change/improve upon how things are accomplished today?

I think that's the core of this article.

To put it another way, if the acquired knowledge to accomplish tasks via "programming" is only useful and self-serving within the realm of the library/language being used, how is that moving the entire ball forward?

I think the solution implied here is that a re-examination of history and more experimentation with different architectures or applications of the existing building blocks might get us over this hump we're facing.

Anytime anyone tries to spin any of the following - coding, programming, software engineering, software development - as distinct things, and expects me to acknowledge their special definitions that they probably made up, I kind of lose interest.