> Visual content creation tools such as Scratch, DWNLD and Telerik will continue to improve until all functionality required to build apps is available to consumers — without having to write a line of code.
> Who needs to code when you can use visual building blocks or even plain English to describe intent? Advances in natural-language processing and conceptual modeling will remove the need for traditional coding from app development.
Seriously? This dream died long, long ago. The hard part of software development is not the syntax; it's deciding exactly what you want to happen for every possible input or event.
until all functionality required to build apps is available to consumers — without having to write a line of code.
All functionality required to build old apps, that is.
This is nothing new: most people can build a website these days without understanding anything about HTML. I suppose Graham's Viaweb was similar in its user experience. You can probably write simple games without writing code by weaving together parts, objects and modules graphically and wiring up some logical connections between them from a pool of supported interactions.
But the thing is that all those are just using the machine. Programming is, by definition, creating and writing something that is new. If it wasn't new, it would've been written already and could be reused with minimal effort. Programming is about building that machine.
Thus, programming is at the edge of new, and you can never automate that. However, the edge of new might certainly change, and also change bias.
In the future, there might be less of the "new" that we do now (figuring out how to load and store data to physical devices) and more of the "new" that only a few people do now (for example, programming a deep neural network to do new things).
Yet as long as humans and computers are inherently physical, someone has to care about the lowest level of new (where the bits go) and about all the intermediate levels up to the highest level of new (someone dumping his brain into a cloud computer). You can not free a human from having to deal with bits――or qubits, or whatever we will have――as much as you can not free a human from his physical existence.
This is very true. The idea of visual programming has been around forever and there is nothing wrong with it inherently. It certainly hasn't quite delivered as expected. But even established visual programming environments (e.g. LabView) are a skill itself now.
Even in high level graphical "magical" interface like Tableau software visual BI tools, the real power come with the small scripting part you can put on some specific places.
When I show my work people go crazy like "wohooo I need this magical too so I can do it too!". Then they ask to modify a pretty straigforward measurement, so I open the calculation script in front of them... they got scared as hell and suddenly think I'm some sort of wizard.
Being allergic to code is a pathology for someone who work in IT, don't get it wrong kids!
While I agree with you on visual programming, I think another issue raises itself: we are used to linear text editors - write one line after another - because they fit the way the computer works. Even breaking code down hierarchically as we do (functions, modules) still breaks a linear process into many linear processes. Yet increasingly as problems become more asynchronous / parallel, I sometimes wish for a more sophisticated code-creation paradigm, one where, for example, there would be some kind of two dimensional or even multidimensional visual representation of the logic of the program (even if those were each composed of linear text blocks). It's always possible to represent multiple dimensions in a lower-dimensional medium, but it becomes harder to conceptualize. So we have code folding tools, we have NERDTree etc to help us manage all the blocks, but sometimes I wonder if I could have some kind of multidimensional VIM that would allow the visual structure of my code more directly to map to the logic flow.
I have taken to coding on a 4k 40 inch monitor (highly recommended - the BDM4065UC from Philips is so good I bought two) because it allows to me see so much more of my code and the way the flow will jump around, to have it all in front of my eyes kinda thing, and I wonder if it would be even better to add some visual tools in there to do conditional flow control.
Not sure about this. If we're writing a scientific study with nothing to do with computers, we still use the standard "write one line after another" to describe the processes and methods we use. Sequential lists and trees may be a natural property of our reality in the same way gravity is?
As you say, when problems become more complex it becomes more difficult to reason about when dealing with a linear flow. But as with writing a report, the key is in the layout. The solution to a problem like that may be simply defining your abstractions better in your code so that each logical block is contained and understandable -- the same as with a section in a report.
Basically it's the age-old programming logic: instead of having large chunks of code where you have to reason through complex logic, create abstractions so that the complex flow is defined in an obvious way. There will still be complex pieces, but they can be pushed to leaf nodes in other classes/files and can be backed by formal algorithms with logical proofs.
So, well, standard best practices from the 1960s and still standard best practices today. Why? Because it seems to fit with the laws of reality.
have to say - am not sure about it either! I'm simply intrigued by the question, namely, why do we still use linear tools for multidimensional problems? I think you have posited an excellent answer in that it's basically intrinsic to how we think and manage complexity, not only in CS.
Couldn't agree more. Code is highly dimensional while our text editors are two dimensional at best. In case you don't know these talks I think you will enjoy The Future of Programming and Inventing on Principle both by Bret Victor.
The closest I've come to visual programming is various UI designers and a couple of DB designers. They work OK up to a point, but as soon as you're doing something complicated you have a mass of arrows crisscrossing the surface.
I think the problem is a visual designer is only a reasonable organising principle for 2D problems. You can get a nice global view.
As soon as you need more dimensions, you might as well use something where the connections are only locally visible. By that I mean eg in a complex codebase, you can only see a few incoming/outgoing connections depending on where you're looking. A codebase can be arbitrarily complex, so chances are on any problem that isn't quite small, you aren't going to be able to represent it nicely in 2D.
It's true that the 'dream' has been here for ages, but I do think that automation might force us to rethink our job in the digital industry.
I recently published an extensive article about the current state of these 'code machines', if developers might lose their job to them and what our options are. If you're interested, you can read it here: https://medium.com/design-and-develop/code-machines-29b066b6...
Bottom line is that I don't think that developers should feel intimidated by machines right now, but not be surprised by their rise either.
Not your coding skills, but your business will define if you’re still needed. If you’re coding basic low-cost websites at a high pace, you might run out of business faster than you might expect. If you can do it by repetition, a machine certainly can do that too. If you’re building crucial online services with a lot of custom functionality, the machines will have a harder time to keep up. Don’t worry about the need for your skills, worry about the need for your current business.
Right. It's not that software engineers are going to go away, just that more and more cookie-cutter software will be buildable by less-technical people (eg. like what Wordpress has done for basic websites and what Unity has done for game development). Advances in NLP and A.I. will probably make code more English-like (eg. like SQL), or at the very least abstract away all the syntax quirks and other tedious low-level bullshit.
Most software engineers are constantly reinventing the wheel (even if they don't realize it because that wheel hasn't been open-sourced yet), and that is the work that will be automated away. But of course the cutting edge will always require programmers (like someone above me commented). But don't be surprised if programming looks a lot different in the future than it looks today.
I think software engineers tend to glorify the act of typing lines of code into a text editor. Code is simply a means to an end.
The thing is, is making a website with those services faster than with code? Even if it is slighly faster, they only work well for the 80%. The last 20% of features are impossible and you're back to code.
I'd rather worry about higher and higher level programming tools that make programmers more productive. Hobo comes to mind (http://www.hobocentral.net/) and Meteor, both making roughly orthogonal aspects of web programming easier and faster.
The way I like to phrase it is that humans are in a perpetual loop of creating things that make life easier in one way yet inherently more complicated in others. Then the cycle repeats to compensate for the new situation. The more granular your understanding of this in a particular discipline ( it doesn't have to be programming but it can be ) the more valuable you will be. :)
Coding is translation as much as translation is translation. That is to say, it isn't.
People who translate are trying to convey meaning. They are not just converting instructions from one language to another. There is intent, emotion, connotation. And you have to do this elegantly. (Everyone who grew up bilingual has spotted clumsy translations.)
I think this article takes a very narrow view of coding. Yet also a fairly common one. If you're one of the people who just wants a machine to do as you tell it, you'll be about as good as coding as someone who cooks in order to not die of starvation.
In order to really master it, just like in any other walk of life, you need passion. You need to have an aesthetic experience, an appreciation for both function and elegance.
You need to find yourself interested in topics that are not directly to hand. You may never need a Bloom Filter or Erlang, but you'll have heard of them and at least placed them on your map of the field.
Getting back to the article and the cooking analogy, better tools will not replace chefs. We have better cooking utensils and machines than 100 years ago. And yes, you need less effort than before to microwave a meal. But chefs still serve a purpose, and you would never mistake a meal made by a guy at home with what a professional chef makes.
+1 on the idea that you may never use something but you will at least have heard about it, know it exists and know where to look, in the future if/when you suspect you might need it.
Wasn't a huge fan of applied maths during my CS degree more than a decade ago, but am very thankful these days that I had an inkling of an idea about FFTs, PCA, and stochastic calculus, all of which I have had to brush up on and use in recent years.
While I agree with some of the premise of the article (you can't become a great developer in a few weeks), it tries almost too hard to scare people away from programming.
>Would I like to type text files for hours a day?
The bulk of my time is spent thinking, not typing.
>Am I comfortable being a digital construction worker?
Programming is a creative job that the author is trying to sound so mundane and boring. Yes, it might not be for everyone, but showing people screenshots of GameSalad Creator, which looks quite scary is not really representative of the vast number of easy-to-use game creators we have today [0].
The fact is that programming is a highly rewarding job (both financially and mentally). As long as there is a demand-supply gap in the industry, people will try to bridge that gap, by whatever methods. Coding academies are just one such method.
If we ever reach parity on the demand/supply situation (or if Universities start training students better), these will be left redundant and new methods would evolve.
I like to think programming is about being creative...but reality has stared at me too long. The large majority of it IS mundane and boring.
I just looked at the commit log for my current project, https://github.com/bjwbell/gensimd/commits/master (SIMD in Go), and ~90% of the commits are boring. I still feel very excited about it, perhaps I'm unbalanced.
The majority of any creative endeavour is mundane and boring, we do it for those small moments of inspiration and insight that break up the periods of drudgery.
Yes, there are very few careers and/or hobbies that are _not_ mundane.
I like to make paper figurines in my spare time. I like seeing how the designs work together. However, about 90% of the time is spent either cutting the figure out, or folding/creasing the figure out. I really hate those parts, but I know that it's necessary for me to make the figure I want.
It's 90% mundane, but the 10% I spend actually putting it together, as well as the finished product, makes it worth the monotony, in my opinion.
And I think that's where passion lies--in a person's ability to trudge through the monotony because of the end goal.
I don't think there is any creative endeavour in life that does not contain very large proportions of mundane work. What gets you through the mundanity is the creative spirit - the idea that the final product will be amazing / different / inspiring, that makes all the work worthwhile.
"Unbalanced" is often a description of someone who is inordinately passionate about a project, and inevitably is applied to creative types without whom such projects would never come to fruition.
For me, even if the smaller portions might be mundane, its the whole itself that is a creation by me. Look at that website: I made that. That tiny wiggle animation that brings a smile to your face: I made that happen.
Sure, it took me 10 minutes of googling and hunting stack-overflow to workaround some weird browser issue, but the end result is definitely creative. Its not about programming as an activity, but the end-result of the activity, which is a creation.
We are digital construction workers because only a few of us are in a position of designers. Most of us are told by product teams what to do and if we have leads and architects in the hiearchy we are limited even more.
If you find that creative then you can find anything in your life creative, even shopping.
And I must agree 90% time tasks are mundane but for the 10%, it is worth doing.
Programming by and large is NOT creative. As a software engineer, I don't understand where this idea comes from.
Sure if you're coming up with cutting edge machine algorithms or coming up with the product features or designs that you're then going to implement, there might be a great deal of creativity involved. But most programmers are simply solving technical problems assigned to them by a product manager. There is nothing "creative" about fixing a bug, adding a new feature to a website (that you didn't design yourself), streamlining your deployment process, or reducing the latency on your server.
As a software engineer, the one thing I dislike about my job is the lack of creativity, which is why I find myself pursuing arts in my free time (eg. video game design, music).
> But most programmers are simply solving technical problems assigned to them by a product manager.
Solving technical problems is a creative process. No technical problem that I have ever come across requires the exact same solution for it. You have to think about how you want to express the solution to a given problem. How complex or verbose do you want it to be? Sure there are patterns, but what design patterns can you use to solve this? How do you modify a design pattern to really suit the given problem.
Programming IS a creative process. It's a process where you cannot ever document how something must be done in a step by step manner which is applicable in every given situation that the document refers to.
If one's job feels like a job dependent on rote, then that's an issue with the job. The software industry does not encourage creative process in many ways, and that holds true even for the design industry. It's why so many people break away to become independent designers or developers. It's why there are so many sites and comics dedicated to highlighting the absurdities of clients. The discipline of programming or design both require creativity. We are however surrounded by corporations and people that believes that developers and designers should be moved to a factory line type process whereby any creativity you can express is effectively reduced to nil.
I totally get this. My day to day programming at work doesn't get me feeling like I'm truly exercising my brains. It's mostly handling instructions handed down to me. But when I get home and fire up my editor. Ah. It feels like I've just donned a superhero's cape and I'm embarking on an adventure. A superhero who can look at a problem, and with some lines in a text file can hopefully connect with another person in making their life better.
If that isn't art, I don't know what it is.
PS - If someone wants to make a comic around superhero devs, do make a husband and wife one. "Dev Dave and Dev Dana: Adventures in 4D"
You could add one more line of crappy code to work around another line of crappy code, when explicitly asked to by your product manager, but that's a pretty bad way to do it. Even if a lot of people out there are doing it to make a living.
It does take creativity to come up with a better way to arrange the code, to balance robustness, performance, and simplicity. Elegance (and even simplicity) is subjective. There are different styles that can work, but you kind of have to have good taste to end up with a good result. It's an art.
Well, being creative by and large is NOT creative either. Take the musician who spends days practicing their scales or playing sheet music, for every minute of original composition they do.
While I agree with some of the premise of the article (you can't become a great developer in a few weeks),
I don't think coding academies or the people in them would argue that you could become a great developer in a few weeks or even a year.
The other day I was talking to a friend who is doing one of the better reputation coding academies in NYC. She's learned a lot but also realizes how much more there is to learn, and she's also gone from knowing very little to understanding that coding academies operate primarily in one, high-level part of the tech stack. Over time she'll keep learning but she does have a job as a junior developer—which means someone, somewhere thinks she knows enough to be productive. AFAICT, that's what coding academies offer.
Which is, I suppose, what you say here:
The fact is that programming is a highly rewarding job (both financially and mentally). As long as there is a demand-supply gap in the industry, people will try to bridge that gap, by whatever methods. Coding academies are just one such method.
Agreed. Also, if a code academy is that stepping stone that provides enough impetus or motivation for someone to take their development efforts further, then I can't see how that as a bad thing.
Back in the day I worked with a project manager who would edit a spec in Word and save it, not tell anyone she'd done it, then be angry the next day when she launched the software and it hadn't changed. Because that's how plain English programming works: magic elves.
I had another colleague at a different job, a chemistry PhD so (on paper at least) a smart guy, but he genuinely could not get his head around the idea that software was something that was written. Software was something that was found and the skill was like the skill of being a gold prospector in the hills panning for that program that would do what you wanted.
Like good enough voice recognition? The fact that we dreamed about computers and robots since first mechanical automatons, perhaps earlier and for many years we couldn't crack it doesn't mean that we haven't and we won't.
I think the author is wrong but not because we won't have visual building blocks and flexible language interfaces. Rather because event if you try to describe what you induction cooking plate does for you using visual building blocks and English language you still end up with pretty tangled mess that only real programmer could have patience for.
> even if you try to describe what you induction cooking plate does for you using visual building blocks and English language you still end up with pretty tangled mess that only real programmer could have patience for.
Sorry, I should have been less succinct - I totally agree with you, visual languages already exist and are improving all the time. I don't believe that they will lead to a world without programmers for the reasons you state. They are just another way to express syntax, they don't reduce the complexity of the actual problem being solved.
Voice recognition is not "good enough" yet. It is better at simple commands than it used to be, and more ubiquitous, but it is still incredibly limited. Frankly, it's right up there with visual programming as a technology that's been touted as 5-10 years away from a breakthrough for decades.
More like the last 50 or 60 years: "the programming occupation will become extinct (through the further development of self-programming techniques)" (Herbert A. Simon, 1961, and the notion seems to be even older, cf. Janet Abbate's "Re-Coding Gender", page 74-75)
From the same book (p. 84): "Stephanie Shirley, who started a contract programming company in the early 1960s, later recalled: 'When COBOL was introduced, we thought that would be the end of the company, that nobody would be buying software anymore – programming – because it was just so easy.'"
The author neglects to mention the wonderful feeling of having your code successfully compile and come to life. For some it is a special kind of high that makes all the 'construction work' worth while.
There's also no mention of the thrill of the hunt for the right abstractions - which can be both intellectually and emotionally stimulating.
The less these two factors come into play, the less motivated one would be to sit in front of a computer and click those keys all day long.
If you're set on finding out, and if you require the structure that an academy provides, and you understand the financial implicatios, then don't let this article dissuade you from trying.
I worked in a programming bootcamp and I can tell you that is a complete scam. Yes, everybody knows the wonderful feeling of having your code.... but this is related with a marketing scam where students pay thousands of dollars for nothing.
Yes, as in any field I'm sure there are scammers out there, or even just poorly conceived programs. So maybe what we need is a review site for these academies.
A review site would be great to have. But wouldn't someone who runs a scammy coding school be likely to pay someone to post a great review? To ensure accuracy, you would need a way of confirming that (1) the person writing the review actually learned to program at that coding school and (2) they now have the job and salary they claim to have. It seems like a hard thing to do, and the high monetary incentives for posting fraudulent reviews would encourage scammers to put a lot of work into gaming the system.
I'd love to see something like this. I mentor a lot of people and I'm always asked about particular programs, but I can rarely recommend anything in particular because I am not aware of anyone else who might have graduated from there.
Also: spreadsheets. The world's most popular (zero-th order) functional programming language.
Legions of `normal' people wrestle spreadsheets every day. It's a brilliant model to get people started. Even better than PHP. (Only partially joking.)
I agree that there are a limited number of people that are excited about the types of thinking and problem solving that comprise typical coding. But not all of those people are already coders. 9 weeks of intensive training can get someone with the right mindset in shape to make useful contributions as part of a team.
You can self teach (I did), but having structured guidance and someone to answer your questions can get you there faster. I watched my cousin move from novice to gainfully employed via boot camp in a tenth of the time that it took me drilling with a friend nights and weekends.
Even if we take the author's dubious claim that the skills have a shelf life, it's going to be years at minimum before the demand slacks. Plenty of time to earn back the cost of admission with a significantly higher salary.
:-) I know that's a rhetorical question, but I can say that I tried Scratch briefly on a Raspberry Pi and not the slightest worry about keeping my job ever crossed my mind, and that from using NLTK the following blog post is spot on:
http://spacy.io/blog/dead-code-should-be-buried/
I've tried teaching programming to friends with STEM university degrees that were doing it as part of their jobs, and the results are in almost all cases dismal. Maybe I'm a bad teacher, but otherwise it seems that indeed a tiny percentage of the population has talent for (or maybe interest in?) programming.
More and more substandard code is and will be written; the more people writes code the more work there will be for me to clean the mess at consultancy rates. I'm not afraid at all of losing my job, and welcome any and all interested learners into programming.
I don't believe that there's a tiny percentage that have the talent for it; coding is a skill like most skills that can be learned and improved via practice. I'm not trying to be mean, but you're probably not a great teacher. That's not a knock on you, it's just that teaching is hard (and it's a skill that can be learned and improved via practice).
"Do I enjoy decomposing problems into detailed lists of instructions?
Am I good at abstract conceptual thinking?
Am I comfortable being a digital construction worker?"
It is funny that these three questions appear one after the other in the article yet the author doesn't seem to understand the connection or the fallacy of the analogy.
Construction workers don't have to define what a 2x4 is, it simply exists. Translators don't create a new words. The developer has to work simultaneously in the world of the abstract and the concrete; the 2x4 doesn't actually exist in his world, he needs an abstraction to stand in for reality.
Very few people are able to simultaneously juggle both the abstract and the concrete. Which is why the majority of people quit; they do not have a mechanism for these mappings; how to take a requirement, represent it as a series of instructions, through the abstraction of a language.
So yes, academies are nonsense, but by using poor analogies, we simply reinforce the notion that predicated them in the first place.
>In 15 years, those hard-won skills will be obsolete — if they ever stuck in the first place.
Whoa, holy shit, if you don't learn new things, you'll stagnate? Who could have guessed? Good point, bro, no one has made that observation ever before and it totally only applies to people who graduate from bootcamps, not to, oh, I dunno, literally any coder in the world.
Know why I like coding bootcamps? Because I left teaching, went to a bootcamp, and doubled my salary. And my job's fun and rewarding and I get to learn stuff constantly and then go home and put that stuff to use on projects that I do for myself.
I agree with the premise you won't be a great programmer in week or even months. This is a truth for any skill, job, passion.
I think there is a common wrong way of considering programming among non-programmers: customers and people thinks programming is easy, extremely easy but the truth is the opposite.
Just try to think how much time does it require to build a simple mobile app or a webapp and how many different knowledges you have to master to do that (front vs server programming languages and frameworks, persistence technologies, deploy tools and so on). And i'm not talking about the complexity of an "enterprise application".
I think this common and misleading sense of easiness is due to the fact that people thinks that you have a lot of work already done thanks to all those opensource libraries, thanks to the ready-to-go tools like wordpress, thanks to all those beautiful and simple programming languages that every child can learn...come on, there is always an easy "build a twitter like app tutorial" so it obviously can't be that complicated thing :D
The truth is that like any other job, you must love programming to do it very well, because programming requires a lot of thinking, designing, studying, patience and perseverance and all these skills are not for everybody.
I call this 'inventor syndrome' because innately people want to better the world in some way, instead of just leech from technology.
MY only issue with that approach is people re-inventing the wheel. There is more code on Github than one could imagine, and not enough people evangelizing for Less-lines-of-code.
Of course it may take a programmer two decades to realize this, but what's the phrase:
"In the beginner's mind there are many possibilities, in the expert's mind there are few"
this is an extremely self serving article given that the author sells a tool (for $29/ month no less) that writes the code for you. Wonder why he doesn't like code academy's. There is some truth to the fact that a lot of people don't make it through code academy, but I would take this article with a grain of salt.
i really didn't like the arrogant tone and the misleading content of this article.
the author discourages curious people and potential talents with uncertain future self replicating apps that will replace programmers (anyway, aren't this apps made of code as well?) and shows his huge-complicated-6M-lines-of-code to cut enthusiasm once for all, forgetting to describe a process that take years and involves loads of people to end up with so much code in a complex application.
if you want to programm pick something you would like to build and work hard. the author of this article did exactly the same, the difference is that he did it long before you.
I thought I would completely agree with this post (since I do believe that coding academies are indeed nonsense), but it's so full of stupid comments.
The author seems to not understand what coding is (despite his 15 years of experience as being repeated several time, as if to make it true maybe). Coding is not just building a stupid app, coding is not translating English into some weird language. The language of choice in programming is just a detail, anyone can learn a syntax in a couple days. The real challenge is in the understanding and the modeling of the problems, the design of the solution to have all the pieces fit together.
While I appreciate the intent - to warn people about a scam - I find the content lacking in both insight of software engineering history as well as practice.
1. The message that automated tools will replace text based coding has been repeated every decade since text based programming languages were invented. Visual programming has found it's niches https://en.wikipedia.org/wiki/Visual_programming_language but somehow I'm still producing new code in C++ - and not only due to historical baggage of large organizations (while it does have a considerable part to play as well)
2. The view that visual programming will take the hard parts away from coding is highly misleading. It applies only to the stupid parts were one needs to connect input to output b as nauseam. On the large scale it will still be about systems design, and on the individual operand level about understanding, designing and debugging algorithms.
I understood the last point very strongly when observing my 8 year old progressing with his hobby programming in Scratch. At first he was quite flabbergasted at what to do with all of the blocks - then he followed some examples, but was still baffled. After a while when my wife found a book about Scratch programming for him (we're not native english speakers so it's not as trivial as it sounds) he was extatic that he found all these examples that finally explained to him how he could implement things.
But the thing is - he's not copying the examples verbatim, he parses the examples in his head, then figures out a new interesting variation of the technique with his own art and then implements it.
Clearly he has skills far beyond simply "connecting wires". The blocks take the tedium of parsing and compiler errors away but the algorithms he needs to still implement himself.
And the familiar categories of bugs are present there still. "Why is not my spaceship moving - Oh, I'm initializing this variable inside the loop and not just before it" - a simple mouse drag - and suddenly the space ship he drew is flying across the screen.
This article is plain nonsense amd I'm surprised it was published in Techcrunch. Saying this about programming: "Would I like to type text files for hours a day?" is like saying that writing a techcrunch article is pressing keys thousands of times. I have no idea why this article is so (negatively) opinionated, but as someone who learned programming because I love it, this strikes me as someone talking about something they have no idea about...
> Who needs to code when you can use visual building blocks or even plain English to describe intent? Advances in natural-language processing and conceptual modeling will remove the need for traditional coding from app development.
Seriously? This dream died long, long ago. The hard part of software development is not the syntax; it's deciding exactly what you want to happen for every possible input or event.