The end of coding

During past couple of years there’s been a strong push from the technology industry to teach everyone to code.

“Every student in every school should have the opportunity to learn computer science” —

Everyone should have the opportunity to learn computer science. Understanding computation changes the way you think, and directing it gives you amazing power to realise your ideas. Understanding concepts like abstraction, coupling, generality, complexity and scale change the way you understand and approach problems. Wielding general purpose programming tools changes the way you solve them.

Software is transforming the world more and faster than anything since agriculture. It is at the heart of business growth and innovation today, both in the technology industry and outside it, and is rapidly changing the way individuals live their lives. Software has taken over our ways of accessing knowledge, of storing and processing information, of publishing and receiving news and media, of executing commercial transactions, and of communicating with our friends, colleagues and communities. The world’s largest bookseller and video service are software companies; our dominant music companies are software companies; our fastest growing entertainment companies and telecom companies are software companies. Companies that aren’t software companies are increasingly depending on software to optimise logistics, supply chains, manufacturing processes, and advertising or provide tools for their employees to produce ever more value. Software is on the brink of disrupting the way we teach and learn, borrow and lend, learn about and care for our heath, and find and consume services of all types.

But despite this unprecedented transformation, one day, coding will be rare. The current enthusiasm for and growth of coding is temporary, an artefact of our tools. Coding is, right now, our best technology for directing computation, but coding itself is not the essence of computer science. Computing is manipulating data and directing algorithmic computation in order to solve problems. Code is our current tool of choice, but we must make better tools. One day, it will be commonplace for people to manipulate data and direct computation without writing a line of code. I can’t wait.


Programming is a highly specialised skill. Solving complex problems is naturally difficult, and as a coder, I frequently write programs to solve problems of all sizes. I cringe at the techniques non-programmers bring to bear on easily automated tasks. I happen to be blessed with particular logical and linguistic facilities which mean I can crudely simulate a computer in my head and talk to it in an unnatural language with weird, unforgiving rules (I’m less good at simulating humans). Many people are less well adapted to be good at coding, but not much less likely to benefit from solving complex problems. The tools and methods of programming introduce much of the complexity associated with solving a problem with code, and take those solutions out of reach of the majority of us who aren’t trained in the craft. Programming is not easily learnable, and is an unnecessarily distant abstraction from many problems people may want to solve. People shouldn’t have to learn to code to apply software to these problems.

There are a few tools I can think of that today give non-programmers some programming-like general problem solving power.


Calculators have come a long way since the introduction of pocket calculators in the ’70s. Programmable calculators allowed scientists and engineers to solve problems more complicated than simple arithmetic could handle (though they might have used some code to do so), and graphing calculators helped them understand the answers visually. Since the popularity of personal and mobile computers, software calculator interfaces have evolved towards representing the problem the user is expressing, rather than the anachronistic accumulator-style implementation (e.g. typing a whole expression left-to-right at once rather than one term and operator at a time and inside out). Innovative designs like Soulver and Calca embed the calculation in its context and show working on the surface, providing some ability to vary inputs and watch results change live.


Spreadsheets are some 30 years old but still fundamentally pretty similar to their first ledger book-inspired ancestors. They’re still the best lightweight accounting tool but also turned out to be a great general purpose calculation and modelling tool, and are good at representing tabular data, too. The tabular format is nonthreatening yet general enough to wrangle into so many roles[1], and the live recalculation encourages piecewise problem solving. Lots of people who work with data are great with spreadsheets. They can do craaaazy things. Up the complicated end, spreadsheets are capable at data storage and exploration (especially since the advent of pivot tables), help people develop and evaluate complicated multi-variable expressions, explore simulations and what-if scenarios, and visualise results. Spreadsheets are a somewhat generative tool, making possible things far beyond the tool creator’s imagination. They are as close to programming as many people get.

Spreadsheets have their shortcomings though, especially in light of today’s standards for interface and power. They’re poor at handling multi-dimensional data, and you usually need to decide dimensionality up-front, or start over. They can roughly simulate vector/parallel calculations by using a range of cells and repeating calculations crosswise, but they don’t understand the shape of your data enough to offer much help doing so. Spreadsheets conflate the interface of a flat two-dimensional tabular view of data with the data itself and with the formulae evaluated on it. Alphanumeric cell addresses are opaque and brittle; either moving data or altering layout is liable to break the other and affect computation. The formulae are hidden and it’s very difficult to verify the correctness, or even understand the functioning, of a spreadsheet you didn’t author.

A few mid-80’s spreadsheet programs attempted to address some of these shortcomings, primarily by decoupling the data from the tabular display: Javelin, Trapeze and Lotus Improv; but they’re long gone and sadly we haven’t seen anything similar in consumer software.

Personal databases

Sometimes a spreadsheet just doesn’t cut it when you have complex or multidimensional data. Data manipulation, query and reporting are the essence of a large range of problems people want to solve. But unlike spreadsheets, it’s my impression that personal databases have sharply reduced in popularity over the past couple of decades. Have they gone out of fashion, or do I just move in different circles now? Perhaps the presence of programmers in any sizeable organisation has discouraged people from using them, on “expert” advice. I remember the distaste I had for MS Access back in university: point and click query building over my dead body! But I was naive, just high on the power of SQL. The capabilities embodied by personal databases should be taught to everyone; not instead of coding, but maybe before it.

I now discover that MS Access can pretty much build CRUD applications for you, and Filemaker much the same. I’m also pretty keen to try out Zoho Creator next time I need to prototype a data-heavy app. Still, while they have evolved a bit, these tools are still not flexible enough to build a real application, just easy forms and views.


There are a few more specific fields where non-programmers have tools by which they perform something very much like programming, but without much code. Game development provides a good example: a game is a computer program providing a particular interactive experience. Games are typically really complicated programs, dominated by “user interface”, but a game development team is typically dominated by artists and designers, not programmers (the mix does vary depending on game requirements). These artists and designers use tools built by programmers to realise much of the creative output a game embodies: art, textures, terrain, models, animation, cinematics, level design, puzzles, interaction, narrative. To propose a process whereby, say, a level designer provides drawings and written guidelines to a programmer who then manually translates the design into code, and then repeats that cycle until the designer gets what they want, would be just ridiculous (yet this is how most application interfaces are built today). No, the programmers build a game engine and level design tool and then the designers can work directly in an environment that closely matches the finished game and produce output to be directly loaded into the engine at runtime.

Sadly, today’s user interface design tools are not usable by non-programmers, nor used by many programmers. Point-and-click has been looked down upon by “real” programmers since the invention of the mouse, just as assembly programmers looked down on early Fortran pioneers, C programmers look down on Java, and Vi/Emacs users look down on those who harness an IDE. Those who have mastered one tool or process have great difficulty letting go to adopt something different enough to be significantly more powerful.

For a long time, GUI builders were crap. GUI builders are still crap: they often provide a poor representation of what the rendered interface will look like, are not powerful enough for developers to achieve exactly what they want, and are too complicated and laden with programming concepts for non-programmers to use them[2]. Programmers understandably decide to just fall back to coding, since they’re going to be doing some of that anyway to work around the tool’s deficiencies. This is a mistake, though an understandable one. Code provides a terrible representation of visual concepts with a huge mismatch in thinking modes, especially when that code is procedural rather than declarative or you’re designing the interface as you build it. Recompiling and launching your program to observe each UI tweak is an inexcusably slow development process. I get the motivations (e.g. here, here) but it’s a scandalous waste of effort that designers do all their work in Photoshop and a developer starts from scratch to replicate it. Our tools must improve so that designers can build the real UI, with programmers taking over later for the back-end (Spark Inspector and Reveal hint at the future).

Other tools providing programmer-like power to non-programmers include batch processors (e.g. in Photoshop), node- and layer-based compositing tools (e.g. Shake, Blender), Apple’s Quartz Composer for node-based image processing and rendering, Automator for scripting Mac OS and applications, Mathematica, Matlab, and LabVIEW for scientific and engineering design and analysis, Yahoo! Pipes and IFTTT for web and API mashups, and wikis for content management and presentation. And I must make a special call-out at this point to HyperCard (1987-2000), one of the most influential application design environments to date. I fondly remember building stacks and writing HyperTalk long before grasping any of the concepts I would now consider fundamental to programming. I made things I was proud of and saw people in both my own and my parents’ generation (i.e. educated pre-computers) do the same[3]. If you missed out, do read this reminiscence. HyperCard’s legacy lives on though its influence on hypertext, the web, wikis, and derivatives like LiveCode.

So we have some data analysis and calculation tools for maths, crappy UI builders for interface, and some application-specific tools for games, graphics and hacks. The next generations of these products should radically expand what non-programmers and programmers can achieve without coding. They won’t write code for you, but they will make coding unnecessary. I hope similar tools emerge to cover most of what is now achieved by writing code, enabling the creation of arbitrary useful and high-quality applications by anyone. In particular, we’ll reach a critical point when these tools become recursively self-improving, so that a non-programmer can create a tool which will in turn be used to create more applications, including better tools.

That six-figure-salary engineers don’t consider translating a Photoshop render and some instructions into a functioning user interface to be a tragic waste of their time shows how valuable this problem is to solve. If you’re a programmer and this offends you, consider how much more value you could create if you didn’t spend half your time as a glorified PSD->HTML translator. Yes, yes, I know, front-end is hard, it’s really complex[4]. But so much of its complexity is due to the tools we use, not essential to the problem. All that deep software engineering insight and hard-won domain knowledge is so valuable because building a UI requires thousands of lines of code. When it doesn’t, you can apply your towering intellect to something better.

Most previous attempts at programs that help non-coders make programs have sucked, especially the more general-purpose ones. But we’ve learned a lot about user interface recently thanks to the billions of people now using our interfaces and consequent value of improving them. The challenge of creative tools is presenting an interface that extends expressive power without crushing the user with complexity. While in every domain there will always be experts working at the boundary between impossible and easy, as tools improve things that once required sophisticated knowledge and technique become accessible to amateurs. Witness the explosion in quantity and quality of amateur music and video as the tools of production became good enough and cheap enough to pick up in a weekend. I’m optimistic that as our ability to design interfaces for complex domains improves we’ll create better and simpler non-programmer tools for designing and implementing a wider range of software. For some, these will be the stepping stone to expertise, but for most the tools need only help them get the job done.


Coders have a tendency to make tools for coders. It’s much easier to build a tool that works when you can assume a high level of technical sophistication for your users. But tools usable by non-programmers will help programmers too. Reducing the cognitive load of directing computation will enable coders to solve more complex problems faster. Like the mythical successful employee, we should be aiming to do work so great we put ourselves out of our job. We’ll still need programmers and engineers–experienced and creative practitioners of modelling problems, designing algorithms and data structures, taming complexity, and managing process–but they might become like farmers today: a highly leveraged sliver of the population.

A future where everyone can code would be wonderful, but code is only the means to directing computation for now. When our technology reaches the point where everyone has tools for thinking and creating but few need to code we’ll be far better poised to conquer our society’s challenges. Programmers could start building that technology now.

Teaching more people to code is a great step forward, but a future where few need to is even better.


Thanks Jessica, Natalia, Nik and Glen for your feedback on my first draft.

[1] Joel Spolsky (once PM for Excel) recounts learning how people actually used Excel.
[2] Apparently Microsoft’s tools have led the pack for a while, but I haven’t used them for a long time.
[3] James Davies: I still remember your dad proudly showing us his stacks and soliciting feedback. That and him ejecting a bone that was choking me with the Heimlich manoeuvre.
[4] I underestimated this complexity for a long time when I was more interested in back-end engineering. Front end is really hard, and the tools are weak.

19 Thoughts on “The end of coding

  1. Interesting thoughts Alex! So your vision of the future is a computer coder that is in some form of AI machine learning, semi-conscious Turing engine? I shared similar views with a few of my mates last week and we ended up talking about the Terminator series, Sarah O’Connor and SKYNET! Think it will happen in our lifetimes?

  2. “Recompiling and launching your program to observe each UI tweak is an inexcusably slow development process.”

    PaintCode ( is a great drawing app that tries to solve this problem. It turns your drawings into Objective-C code.

    • That looks pretty damn cool! I will definitely check it out. How long has it been released? Have you seen good results?

  3. andrew wulf on November 5, 2013 at 1:11 am said:

    Nice to see a mention of Trapeze which I wrote back in the 80’s. It’s never easy to do something different which is one reason it will be hard to eliminate coding.

  4. There is usually one of these essays every few weeks and when i say few weeks i mean for the last 50 years at least.

    Machine code was going to kill coding and the man in the street would be doing it. Assembler was going to kill coding and the man in the street would be doing it.
    Autocode was going to kill coding and the man in the street would be doing it.
    COBOL was going to kill coding and the man in the street would be doing it.
    Third GL’s were going to kill coding and the man in the street would be doing it.
    Fourth GL’s was going to kill coding and the man in the street would be doing it.
    Visual Studio was going to kill coding and the man in the street would be doing it.

    You get my drift?
    Programming is not about the language. Coding is about a state of mind and an approach to problems.
    The average man in the street (and the ladies) does not think this way.
    The average man and woman in the street doe not even understand how positional based radix weighted numbering systems work.
    Most of them cannot even work out a 10% tip from a restaurant bill.
    No coding will be around as a specialised task for a long long time

    • The fourth doorman of the apocalypse on November 5, 2013 at 1:52 am said:


      Given that the average IQ in the US is 100 and there are a couple of groups with lower average IQs than that, and that it takes an IQ of around 3 SDs above the mean to understand things like race conditions, Paxos, Choros, and so forth, I am pretty sure we will not see average people doing much coding soon.

      As far as tools taking over coding, well, when we have stuff that can understand natural language maybe we can make a start but by then I will have moved on to more complex stuff.

    • Going to agree with John. It’s not about whether you’re entering code into a text editor. It’s about how you describe a problem to a machine such that the machine can help you solve it. Think about a world where we could use voice to do that task. Would it be any less complex? Would it require less thought to manipulate virtual symbols in 3D space? Until computers can operate on essentially the same semantic level as humans, someone is going to need to translate, and that someone is a programmer.

      • Mark: I think your closing statement isn’t that far off. “Until computers can operate on essentially the same semantic level as humans…” indeed.

        We need to be able to direct computers at a similar semantic level to the expression our problem. Where that’s specifying rules, maybe language is the right approach. For interfaces, perhaps something graphical. For the deeper building blocks like specialised algorithms and data structures there’ll still be some coders. But I don’t think we have to propose the Singularity to imagine tools that work at higher semantic levels.

  5. It all depends what you call “coding”.
    I suppose you refer to coding as “building software from A to Z”, but when confronted to complex analysis or modelling, there inevitably comes a point where you need to use some kind of language that will be sufficiently precise to define exactly what the input is, and what calculations are to be done. Spreadsheets for instance do nothing more than helping a user degrade a problem into pseudo-atomic mathematical operations.
    And as soon as mathematics are involved, some kind of structured language is required because no matter what, natural language too ambiguous for mathematics – and what is code, if not a structured language?

    • > It all depends what you call “coding”.


      The ability to give clear concise instructions in a language is always going to be necessary as a vital part of communication. Its non-negotiable.

      We are just at a point in development where communicating instructions to computers needs to be done a lot to the point where we give it a special name and a lot more respect as a field than it really deserves (its a special case of something fantastically common sense)… it will never disappear entirely. A lot of the same methodologies apply to instructing people, groups, companies, nations etc.

      We will always need to know how to instruct something to do something at some level…

  6. Nicely put Alex. However, you probably should qualify that serious programming is more about organizing logic so that change can be managed. The rate of improvements in computing tools though should push developers to work on a higher level of abstraction.

    Personally, I think a cross between a visual programming IDE and a reactive system can lead to systems which have less code and yet easier to comprehend.

  7. You should read Isaac Asimov’s short story “Profession”. It appears in his book “Nine Tomorrows” and possibly other places. It pretty well sums up, in a slightly fantastical way, where the world is heading. Those that understand the inner workings of technology will become more and more an elite, while those that don’t will simply push virtual paper.

    Your own line “When our technology reaches the point where everyone has tools for thinking and creating but few need to code we’ll be far better poised to conquer our society’s challenges” basically sums up Asimov’s “Profession” world, and I don’t know that it really is a better place to be.

  8. Moschops on November 5, 2013 at 5:29 am said:

    “Software is transforming the world more and faster than anything since agriculture.”

    How about the antibiotic revolution?

  9. You are absolutely right about our desperate need for better software development tools.

    Problem is: Most programmers are tight, and won’t shell out for decent development tools; so life as a tool-maker is really really hard.

    However: there is anpther point that is worth raising (I think).

    However good our tools get, we will always have a need for some general-purpose method for precisely and accurately describing the details of problems – whether as an executable specification, or as a programmatic description of the solution in it’s own right.

    The approach that we use may not be linguistic: it may be diagrammatic, or mediated via some other interaction paradigm that we are yet to invent, but the need will always be there.

    In my experience, the thing that separates the programmers from the non-programmers is very simple: a willingness to get involved with the details. An ability to avoid the sad, siren song of “big picture thinking”, with all the self-deceit that it entails.

  10. I’ve been building an open source platform for ‘painting’ API pipelines with a lot of your points in mind, It’s an interesting time for the industry in that I think most people have realised that if ‘programming’ is to become part of a toolkit even non-coder folks have access to then it needs to be expressive, ‘smart’, visual and speak to their immediate needs. So the tooling is becoming much more abstract, and more powerful as a result and particularly now that web based API’s are part of a general vocabulary for problem solving, anyone can leverage the one thing that SaaS providers do really well as part of their own workflow. And that’s the way it should be (life imitating art) – its the perfect time to deconstruct all the walled gardens and build tools people can actually use.

  11. Some of the weirdest thoughts I have read in a long time. The end of coding? Yes – I agree that everyone is becoming more and more familiar with using technologies, but this is because technologies are much more restrictive and easier to use than before. For example, while all Android devices are very easy to use, they don’t give you a super user access to your own phone to make those “core” modifications if you want to.

    The increasing use of frameworks will never make everyone a coder – in fact, it becomes coding a more prestigious and lucrative job. Programmers nowadays are the most sought after individuals in the world – and I expect this to remain the case in the foreseeable future. Maybe at one point the supply will be more than the demand, but it’ll be only temporary.

    Final thought: I learned programming in the university, and believe you me, there are many people out there who just can’t be programmers (it’s not like driving, you just can’t teach it to everyone).

  12. Nonsense. Everyone fantasises we could give up programming in code and move to pushing buttons and direct manipulation of data structures. It will never happen. Nothing is more flexible than text. Diagrams and visualisations are limited to two or three dimensions that our visual cortexes can handle. Or four using time. They won’t handle five upwards. Nor recursive data. Nor infinite lists and algorithmic types that can be represented in a couple of lines of code.

    Drawing pictures helps the people who aren’t good at abstraction. But the most powerful and most important software, the software that defines the world, is going to be written by people that work with very high level, very powerful abstractions indeed. (Map-reduce anyone?) Today’s “visual programming” tools are not much better than flow-charting, a level of abstraction achieved by Fortran in the 1960s. Are there any visual, direct manipulation tools that get closer to the power of Haskell monads or Lisp macros?

Post Navigation