Coding academies are nonsense
techcrunch.com
techcrunch.com
> 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.
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.
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!
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.
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.
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.
1) Code diffs are pathetic with visual programming.
2) Sharing code examples is very limited with visual programming.
3) Full-text search capabilities are pathetic with visual programming.
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.
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.
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.
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.
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.
>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.
[0]: http://www.pixelsham.com/wp-content/uploads/2014/04/indie-ga...
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.
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.
"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.
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.
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.
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).
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"
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.
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.
Stopped reading there, despite predictions this has not happened in the last 20 years and I see no evidence that it will happen in the next 20.
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.
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.
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.
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.'"
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.
Discslaimer: I'm co-founder of http://kitchentablecoders.com and http://sfpc.io
* Would I like to type text files for hours a day? Check.
* Do I enjoy decomposing problems into detailed lists of instructions? Lines of reasoning, but check.
* Am I good at abstract conceptual thinking? Check.
The pool of potential programmers is a lot larger than we might think.
Legions of `normal' people wrestle spreadsheets every day. It's a brilliant model to get people started. Even better than PHP. (Only partially joking.)
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'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.
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.
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 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.
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"
I work with code school grads. A perfectly fine set of junior engineers.
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.
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.
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.
(And where do we draw the line. Is FizzBuzz enough?)