Is Coding Over? No. It Will Evolve.
I recently stumbled across a Hacker News' thread discussing an article published on Medium with the click-bait-like title of »Coding Is Over«. When I read the article, I just rolled my eyes, shrugged and just moved on. But then a discussion on this article popped up in my Facebook timeline. And for some reason (Passion? Probably. Hurt ego? Possibly, too.), I wrote long-ish answers. So I thought I'd expand on those answers and post my thoughts there.
The »Coding Is Over« article's gist is basically, that coding shouldn't be done by people anymore, but rather by... I'm not sure, actually. It just shouldn't be done, apparently. But this paragraph does give you a feel for the article:
Product Managers should be able to just make the app do what it’s supposed to do, without knowing how to code at all. The only thing a company should be creating are the things that make their product unique. Everything else has already been built in other apps and should be reused.
And I find this a very simplified (simplistic, even) view of coding / engineering.
Here are some of my comments on parts of the article:
We should be throwing data into a pile and databases should organize and optimize themselves using machine learning and other buzzwords.
My question then is: Who writes these machine learning tools and »buzzword« devices? They just appear out of nowhere? This sentence alone is very revealing of the author's view of what coding / engineering is.
Engineers around the world are re-writing things like authentication, shopping carts, messaging, and countless other ubiquitous features. And a lot of them are probably feeling pretty cool about it. These are just a few examples of how engineers waste time duplicating the same basic features over and over.
If you work with modern frameworks and use tried and tested modules, it's in a way already combining things and building on top of stuff. I don't write my own authentication, I wouldn't write my own messaging modules. In my head, it's already like using building blocks. Building blocks that update »themselves« because of the so many contributors (and coders!) of open source software.
And if you don't like coding, use Shopify or Squarespace, you just do a few clicks and you have a whole shop or website. But having a tool that can create everything, from Android Game Apps to financial institutions APIs to factory manufacturing software - we're quite a bit away from that scenario. Maybe in a decade or two we'll get a bit closer, but with the introduction of new software, machines and concepts, I think there's always more engineering, developing and coding to do. And I don't even think click-and-point is the most efficient way for full-stack development.
I could go on and on about the article, but I want to focus my energy more on context and taking a broader view.
Shoulder of giants: Where we are now
The role of programmers / developers / engineers will evolve, definitely.
70 years ago, there were only a few people who knew how to program. You needed to punch holes in cards and »debugging« actually meant getting a bug out of the machine.
35 years ago, it was actually possible that a serious hobbyist or someone with enough money to get their own computer in their home. And perhaps they can play a game with it or write text.
Today, it's possible for a developer located in Australia to buy a domain, get a virtual server in the US for 5$ a month, upload some files there and have people with a mobile phone access those files from anywhere in the world. All within an hour, if you want.
Most coders or engineers today will not know how compilers work, how data »flies« from computers to routers or even how a click of a keyboard button translates to showing a letter on the screen. This has been automated. By other engineers and developers and coders.
In this context - and looking at what is being done by computers and networks - what developers and engineers are doing today is already easy. »Easy« might be a misleading word, perhaps »relatively super-productive« is a more suitable expression.
Learning about the history of computing you get a deeper appreciation of technology, computing and what people before you have built. Grace Hopper (born 1906), Donald Knuth (born 1938) and Tim Berners-Lee (born 1955) all had a huge impact on computing and networking - but you can see that the tools at their disposal and the challenges each of them faced were vastly different - even though they were only born decades apart.
I recommend watching this video for inspiration :-)
(computing stuff starts at 3:06, but the whole video is worth watching)
I myself have been coding and developing for a few years now. I developed my first websites when I was 15-ish - that was somewhere mid to late 90s - and tried to solve some of my math homework with C programming. But I didn't really go full-time until a few years ago.
And every now and then I will feel more and more confident about my programming and developing. But then all I need to do is read about the scalability challenges at a top 10 website to make me feel I know very, very little ;-). Fortunately, this makes me want to learn and understand more.
Question 1: Can engineering ever be just simple and automated?
I've been thinking about if at least the basic idea in the article (only-click-and-point-software-engineering) is possible. And at the moment I can think of only 2 scenarios where it would be possible. But perhaps I'm not enough of a futurist consultant (you know, those overpaid keynote speakers that talk about any new technology and get paid for each buzzword used... no, I'm not rolling my eyes every time I read someone describe themself as »futurist and keynote speaker«... ok, yes, I do) to think of more.
Scenario 1 would be if a system was created and it handled all the stuff that is needed for the engineers and no new concepts or ideas are ever introduced. A non-changing, universal, final system. I find this scenario unlikely.
Scenario 2 would be where engineers and coders (!) build a (artificially intelligent) thing that learns and improves on its own, so this thing can always include new aspects in order to assist engineers avoid routine (coding) tasks - now and for all future tasks. I find this is a more likely scenario for a »non-coding world« than scenario 1 (but as of now, still relatively unlikely, though). But by then, AI might just take over some of the engineering as well. I won't go deeper into detail, but if you're interested in this, I recommend reading The AI Revolution: The Road to Superintelligence from »Wait But Why«.
Question 2: Is Coding »super dumb« or inefficient?
»Super dumb« was the phrase used in the article. Because you can introduce »typos« and »code smells«. Sure, but working with a modern development tool, you can reduce that significantly and much of the things needed can be automated.
There are some examples where at least part of the process is click-and-point-engineering, such as developing desktop applications. But soon enough, you will need to code as well because of the custom functionality. And then I feel like click-and-point will quickly become (very) inefficient. You choose a box, you tell the box where to be, then you have to tell the box to do something when it is clicked on, then you have to tell the box to save a variable and then send that variable somewhere else. You have to tell the program not to show that variable to anyone except the owner, etc, etc.
I think coding (by text) is more efficient and more precise in this sense (possibly there will be a better way in the future, e.g. better input device? Virtual reality? AI assistance? Maybe websites will be obsolete anyway).
And yes, there's no nice GUI, but for frontend stuff it's possible to just include Bootstrap or some other CSS framework and within minutes create a layout, buttons, form and a basic functionality. And for backend, to use a concrete example, Laravel (PHP Framework) is geared towards rapid application development (RAD). If you're experienced enough, you can create a decent app in a day or two. You can connect it to a mail service, have social login, billing, etc. With Laravel Spark you can even have Software-as-a-Service functionalities, subscriptions, teams. With Forge and Envoyer or Amazon's Elastic Beanstalk you can set up a server + simple deployment.
My clients usually get a URL where they can test a development / staging / MVP version of their website / web app within a day or two of me starting the project. And this staging version (iteratively updated) will also be the basis for some of the ongoing discussions.
My gut feeling tells me I'd be faster with coding that click-and-point when creating a full-stack web app. Even simple code or calculations or processing of data will be too specific to be represented with a graphic or box that you will need to revert back to coding, anyway.
Sure, there's a learning curve, but no one's forcing anyone to code.
I think in the short and medium term the demand for coding and developing will be strong. And it will likely increase with new technologies popping up. New categories of hardware in homes and businesses are being introduced e.g. intelligent home devices, smarter phones, smarter cars, drones, wearables, blah blah blah and so on. Mostly-click-and-point-development-systems for those seem very unlikely (and possibly inefficient). New programming languages and new frameworks will be developed.
It's easy to start coding, run into a problem, throw your hands up and then say »can't this just be done easier?!?«. Yes, there's a learning curve, but I believe that with time, effort and experience, you can become very efficient, more efficient than a click-and-point system. And looking closely at the history of computing (and coding), you will feel a deep appreciation of what kind of possibilities lie in the hands of coders today and what it took to arrive at this point.