Web Programming: A Prophecy

Over the course of the 20th and 21st Centuries, a lot of jobs that used to require human labor have been turned over to robots. Factory jobs are going to robots. Mining jobs are going to robots. Fighter jet and spy plane pilot jobs are going to robots. Retail jobs are going to robots, with self checkouts and restaurants like Eatsa.

I used to believe, smugly, that programming was too complex and difficult to ever be taken over by robots. When I read an article by some business commentator that claimed programming jobs were going to be this generation’s equivalent of the high-wage factory jobs of the 1950s and 1960s, I scoffed. Until I actually did some of what passes for programming in industry.

It’s pretty much all been lamented before: modern programming in a corporate environment is mostly writing little bits of glue code to combine a bunch of libraries written by some distant genius. Mike Taylor’s version was the first version of this lament that I saw, back when I was still in school and under the impression that industry programming was at least a little bit like personal or school programming. But I’m not here to lament. I’m here to make a prophecy.

In my current job, I am a full-stack web developer. I write the server-side code. I write the client-side code. I write the HTML and CSS. I create the database schema and write the SQL scripts to update the database. Is it complex and difficult? Kind of. But it’s complex and difficult because I have to have passing familiarity with Java, Javascript, HTML, CSS, and SQL, and work through all the amazing ways they don’t fit together well. My part in the whole mess is to drop in fairly simple, monotonous bits of boilerplate code to grab things from the database and insert them into an HTML document. Then I manipulate another mess of frameworks and libraries to show it all nice and pretty and make dynamic behavior on the page. Between the server-side framework, the Javascript framework, Bootstrap, and various other libraries, about 90% of the work is done by magical frameworks that just use little spludges of repetitive code I write to get that last 10% of the way towards becoming a web app.

I find it extremely hard to believe that there’s no way to automate that last 10%. There has to be a tool that makes it possible for someone to drop in those repetitive little globs of boilerplate just the way they like, and get a web application out of it.

As a full-stack web developer, I also offer some advice on design, UX, and business needs. But I’m not a designer, a UX pundit, or an expert on the business needs. My degree is in computer science. My expertise is programming. But there’s damn little programming in the code I write, and nothing I’d call computer science. The main hurdle is the delicate little interconnections between these rickety, rigid frameworks, the brittle wooden bridges I have to cross by writing repetitive boilerplate. But, per hypothesis, there has to be a way to create a tool that automates that repetitive boilerplate. Without that, there’s no programming left in creating the sort of custom line of business app that I work on. You could get together a designer, a UX pundit, and an expert on the needs of the business, and have them use this tool to create whatever web app they want. There are actually already tools that are close to this. Squarespace. Drupal and Joomla. WordPress is a little closer to full-stack web development, but I see job ads for “Wordpress programmers” rather than “PHP programmers” or “Front end programmers”, which suggests to me that WordPress is a specialized tool. As I was writing this I discovered WebML, which already sounds pretty close to what I was envisioning.

Once I realized that, I saw how right Mr. or Ms. Business Commentator whose name I’ve forgotten was in his or her comparison of software developer jobs to factory jobs. Right now, tools like Squarespace and Joomla still have certain limits, and there’s cachet in having a custom web app, so everyone and their dog needs a full-stack web developer to make one for them. Trucking companies need web apps; banks need web apps; government agencies need web apps; churches need web apps; even the Amish probably have a full-stack web developer on their payroll to make an Amish web app for them. (Job perks include hot apple Brown Betty in the kitchen, bonuses paid in handmade furniture, and a company carriage for the commute.) But once this magical tool whose future existence I’ve postulated comes to pass, none of these people will need full-stack web developers. Except the Amish; they need someone who’s okay being in a building with electricity every day. But everyone else will just have business experts make the web app. This might be the product manager, or the head of the department that’s going to use the web app, or the lady down the hall who knows Excel and VBA really well and consequently always gets stuck doing everyone’s spreadsheets. But there’s no reason to bring a programmer into the company and pay them a bunch of money and have them learn the business requirements when you can just have someone who already knows the business requirements use the tool to build the web app.

This doesn’t mean that all programming jobs will suddenly disappear. There will still be programmers. You can’t have a business person build something with a prepackaged tool when you don’t have any business requirements and no one’s ever built anything like it before. Google-scale stuff isn’t going anywhere. Google-level programmers aren’t going anywhere. But people like this guy are going to lose their jobs, or they’ll be slotted in at a lower pay grade to build web apps with the new tools. Even people who aren’t like that guy, people who don’t obstinately hold it as a personal tenet that no one should know more advanced technical subjects like Big O and data structures and we should all just concentrate on understanding business requirements and spelling Dijkstra’s name right, will lose their jobs in droves. They’ll lose their jobs because they’ll have spent careers working on simple little full-stack web apps built on existing frameworks instead of on Google-scale stuff, and suddenly businesses won’t need that anymore, or at least they’ll be paying a lot less for it.

So how long do we, the generic full-stack web developers working on dinky little web apps, have before the apocalypse? My guess is no more than ten years. The tools are already getting there, and they keep advancing. With single-page apps and faster connections, users are already being trained to expect more lag in web apps, so the kind of performance tuning that an experienced developer does will become less relevant. And businesses would love to be able to fire a bunch of expensive programmers and squeeze a little more work out of the business people. They’d love to be able to stop stocking soda and Terra chips for us arrogant, overpriced keyboard jockeys.

A few questions

At this point, you might be thinking my prophecy is wrong and the era of anyone who knows Javascript and one server-side framework being able to find jobs anywhere at relatively high salaries will last forever. And you might be right. The odds are against it, but you might be right.

However, I’m going to try and preemptively address a few questions I can see people having about this prophecy.

Won’t programmers just switch to programming the tools?

No. Well, yes, some of them will. But there aren’t nearly enough jobs working on the tools for everyone who now works as a generic full-stack web dev to get one. The world only needs two or three competing tools in each space, but even if a dozen more manage to scrape by, the scale won’t match the number of people currently working on dinky custom web apps alone for non-tech companies. Think about it: have you ever written a framework? And if you have, did anyone use it? Even though it sometimes feels like there are new frameworks for Javascript coming out on a daily basis, only about three or four actually get widely used, and most framework creators don’t get paid to work on them. The ones that do get used, the ones whose creators do get paid to work on them, are the ones like Angular and React that are backed by large tech companies.

Writing the tools will be the kind of Google-scale programming that will hang on after the Twilight of the Generic Full-Stack Web Devs. But for every former generic full-stack web dev who switches to working on tools, there will be at least ten who get shut out because of significantly lower demand for programmers, and probably another five who switch to using the new tools to do their own jobs at a significant pay cut just to stay employed. Companies in all industries needing to have their own custom web app and hiring a generic full-stack web dev to glue together some frameworks for them has created a supply of generic full-stack web devs that won’t be nearly as much in demand once business people can make the dinky custom business app.

Isn’t programming too complex and difficult to automate like you describe?

I hope if you’ve done the kind of generic full-stack web development I’m talking about here, you know that’s not true. The frameworks already do most of the work. Disorganization and the dismal state of web standards is the only thing holding us back from a single isomorphic client/server framework that lets us build monolithic web apps in a single language the way we used to build desktop apps. And with Node.js, client-side MVC frameworks, and Bootstrap, we keep getting closer to that one framework to find them all and in the DOM bind them.

There are other kinds of programming that I don’t foresee being automated so easily: hardware programming, big data, machine learning, cryptography, and of course the tools such as compilers, IDEs, frameworks, servers, and databases. Programming those things is complex and difficult, and programmers working on those things will continue to have lucrative careers. This prophecy will largely affect people not working in the tech industry, but working on web apps (and possibly mobile apps) in other industries.

Didn’t this already fail?

There have been various attempts to create tools that business people could use to make custom applications, e.g. CASE tools. Many failed. But one, COBOL, turned out to be one of the most successful programming languages of all time.

It’s possible that efforts to create the super tool I’m prophesying here will also fail. But I think modern day has one big thing that makes such a tool more likely to thrive: Google. Older tools were expensive proprietary things, and you had to read a gigantic manual to figure out how to use them. But nowadays, if you need help, you can Google for answers, or you can ask a question on a Stack Exchange site. And there will probably be blogs and tutorials and help guides for the tools, and maybe even public online documentation by the manufacturers, the way Oracle does with Java.

If you’re a busy business expert trying to make a web app, this makes a huge difference: instead of having to spend hours reading through a giant manual and days figuring out the best way to use what your tool gives you, you can just Google for an answer and copy it verbatim, like programmers do.

I’m a generic full-stack web developer and I believe in your prophecy. What should I do?

As a prophet of doom, I sadly don’t have any constructive suggestions for you, other than to consider where your career might go after this doom comes to pass.

If you enjoy the technical side of things, you can try to become an expert in one of those other areas of programming that won’t be wiped out in this apocalypse. If you find cryptography or machine learning too imposing, go for stuff like dev ops and database adminstration. Or if you’re more of a front end person and you like design or UX, you could head in that direction.

Alternately, if you like business requirements and management, like this guy, go full speed in that direction. I don’t, so I won’t be joining you.

What are you planning to do once the prophecy comes to pass?

Once my career in generic full-stack web development dries up, I’m going to take a few months to backpack around Europe and find myself. In a small Italian village on the Amalfi coast, I will rescue a stunningly beautiful woman from three drunken Sigma Chi boys on Spring Break from Penn State. The only daughter of the owner of a struggling trattoria, she will have the heart of poet and the sensitive wit of a Regina Spektor lyric. Our love will blossom like the last flowers of June, and after months of sexual tension and exquisite trattoria food, we will finally consummate our relationship. But the next morning, I’ll receive word that my beloved Albanian bulldog, Bullard, has died. Stricken with grief, I will weep tears of manly remorse, and rue that I was not at Bullard’s side in his final hours. I will return to the United States to further weep, and to visit his grave under the shade of a poplar tree in my parents’ backyard. But in the ashes of this tragedy a fire will kindle within me, and I’ll start a popular YouTube channel in which I talk about the wonders of Italy and Albanian bulldogs while wearing an oilskin duster in burnt sienna, a color that brings out my eyes. As my channel gains subscribers, I’ll start a companion blog and podcast and soon become a widely recognized blogger and YouTube celebrity.

So you see, I’ve got this all figured out. The end of generic full-stack web development will ultimately be a good thing for me. Maybe it can be a good thing for you too.


Introducing MonkeyType.js!

When I needed to choose a Javascript framework for a work project, I put a lot of thought into it. I tried Angular, Angular 2, Ember, React, Redux, Backbone, Dojo, Vue, Mithril, Marionette, CanJS, Knockout, Polymer, and js_of_ocaml. None of them worked. They all just felt wrong.

What I eventually realized is that these frameworks felt wrong because they don’t use the right abstraction. Modeling web apps as MVC, MVVM, MVP, MVT, MVASDFASDHSFGSDFGHQRTQRTAFGLKJNNGJSKL, these are all the wrong abstractions.

That’s why I decided to create my own Javascript framework. Instead of using broken models of abstraction like Model-View-Controller or Model-View-View Model, it uses MOT: Monkeys On Typewriters. And I called its name MonkeyType.js.

I know what you’re thinking: what does a stupid front-end engineer who took on $157,000 in student loans to follow his passion and get a degree in Lithuanian literature with a minor in Cloud Shape Interpretation Studies, laid around on his mom’s couch for five years, got an online Master’s degree in Motivational Speaking, worked as a tutor for left-handed children, decided to enroll in divinity school, dropped out after accruing another $34,000 in debt, lucked into a plum job at a grocery store making $15 an hour where his only real duties were printing signs for the manager to stick in the break room, learned HTML, CSS, and Javascript after the manager asked him to make a website for her side business selling purebred blue fawn Azawakhs (also known as the Tuareg Sloughi according to the AKC), found out you could make money with this Javascript stuff, and finally moved out of his mom’s house, know about designing a framework? Way ahead of you! MonkeyType.js is based firmly on MATH! It uses the celebrated Infinite Monkey Theorem, described by famed French measure theorist Félix Édouard Justin Émile Borel in 1913, to created a model of UI firmly based on MATH!, with grounds in MATH!, concretely resting on a foundation of MATH! to create a uniquely appropriate abstraction coming, like all the greatest and most appropriate abstractions, from MATH!

The Infinite Monkey Theorem states that given infinite monkeys banging the keys on infinite typewriters for an infinite length of time, the probablity that Hamlet will appear somewhere on one of the monkey’s typewriters is equal to 1, i.e. one of the monkeys almost surely produces Hamlet. MonkeyType.js takes this theorem to heart and uses it to create an abstraction for UI programming that’s so wrong, it couldn’t be more right. The best part about a client-side framework based on the Infinite Monkey Theorem is that the Infinite Monkey Theorem is MATH!, and uses terms like almost surely in confusing ways that only make sense if you know MATH!, and are otherwise just confusing and misleading! You have to be really smart to know MATH!, so you also have to be really smart to understand MonkeyType.js. No dummies who only know how to make solid, functional user interfaces that are intuitive and aesthetically pleasing; only the best front-end engineers need apply to use MonkeyType.js, because with MonkeyType.js, you have to be able to do all of those things, and also know MATH!, and not dumb kiddy stuff like fractions, but REALLY HARD MATH! that famous French guys invented. Everyone knows French stuff is really cool and hard to understand; the other night I watched Amelie, and I had no idea what was going on, but it was French, so I can just go up to people and say “Hey, have you seen Amelie? It’s French” and they know how smart and cool I am to be able to understand French stuff. And then they’re even more impressed when they find out I’m the inventor of MonkeyType.js and I understand MATH!

A typical MonkeyType.js program has two parts: the monkeys, and the typewriters. The monkeys represent the data. They’re sort of like the model in other frameworks, except with more MATH!, and more French. The reason monkeys are a better abstraction for data than a model is that models are stupid and for babies. When I was a stupid baby I got this model of an airplane for my birthday. It was wood. I kept trying to build it and getting splinters in my fingers that really freaking hurt. Finally I got a splinter under my fingernail, and it hurt so bad that I got mad and threw that dumb airplane model across the room and it broke, and my mom had to come in and hug me. I wouldn’t stop crying, so finally my mom had to take me to the zoo to make me quiet down. I didn’t stop crying until I saw the monkeys. I was only fifteen years old, but I kept that love of monkeys my whole life, and I never cried again, until I got home and stepped on a broken piece of the airplane model and got a splinter in my foot.

The typewriters represent the appearance, sort of like the view in other frameworks, except with more MATH! Typewriters are way better than views. I hope I don’t have to explain this one; views remind me too much of 1985’s A View to a Kill, and then I spend all day mumbling “Dance into the fire” under my breath and my smarmy co-workers who pretend to be my friends but secretly laugh at me because they all hacked into the Pentagon’s computers when they were ten years old and I didn’t learn to program until I was forty-seven start talking behind my back.

The monkeys pound on the typewriters to create the website. Unlike other dumb frameworks that have something like a controller standing between the model and view, MonkeyType.js lets the monkeys pound directly on the typewriters. Here’s where the really cool part comes in. Obviously we can’t have infinite monkeys and infinite typewriters on a modern computer with finite memory, so MonkeyType.js uses a clever optimization called a monkey barrel. Instead of infinite monkeys, the monkey barrel contains about twelve or thirteen monkeys that it keeps recycling. Every time you ask for a monkey, the monkey barrel gives you a monkey. It might be the same monkey you got last time. It might be a different one. Since one monkey’s as good as another monkey, with this approach, you effectively have infinite monkeys. The typewriters are stored internally in a circular buffer, which gives the impression that there are infinite typewriters, but it’s actually just, like, twelve or thirteen typewriters on a loop. And to create the impression of infinite time, MonkeyType.js is coded in an excruciatingly dumb way so that all the pages hang for at least a minute before doing anything, and when they do do something, they just load a spinner that swirls for another minute or two before the actual page you were looking at finally loads. This impression of infinite time is increased even further in production enviroments, where hundreds of trackers and advertising services also get to load before your content. This makes MonkeyType.js the perfect framework for rich media sites like Buzzfeed, Huffpost, and ZergNet, where every page is so obviously loading five hundred ads before it even thinks about delivering the content you asked for, because the advertising is actually the content and the content was actually just a bait-and-switch to get you to look at ads. But who cares, because we deliver ads with a firm basis in MATH!

In conclusion, where other JS frameworks give you broken abstractions based around dumb ideas like being easy to learn, easy to write, or easy to use to create great UIs, MonkeyType.js gives you abstractions based on MATH! and awesome stuff like monkeys and typewriters. Who cares if it causes memory leaks in your browser? It’s MATH! I hope you’ll consider MonkeyType.js for your next project, and finally learn what a real abstraction looks like.

A Paean for the Proxy

These verses were composed in trying times. Upon a summer’s day in August, the Year of Our Lord Two Thousand and Sixteen, it suddenly became indispensable that I should write a small bit of boilerplate, many times scrawled carelessly upon my IDE window, and never once committed to memory, with the end of orchestrating that the Play Framework, on which firmament rested my code, accomplish some minute but needful end, I remember not what. Raising anchor and casting off into the wide seas of Tela Totius Terrae, I came upon a small inlet at Stack Overflow which seemed probable to house the lore I sought. Clicking upon it, I chanced to provoke the wrath of the Proxy, the gatekeeper which guards our office network. Three times I gave the pass-word, and three times the Proxy denied me, and at last, defeated, I turned to other matters.

In the proximal hours of this mortifying rebuff, I anathematized the Proxy thrice over, and thrice maledicted it, doubling the trials it had lain upon my back like three lashes of a cat-o-nine-tails. But in the following hours I reflected on the happenings, and it came to me that I was like a child before a good shepherd, squealing to be let beyond the pasture, and the Proxy was the good shepherd, the pass-word prompt his crook across the gates, an inexorable guardian, keeping my toe upon the path of truth and my ken upon the course of righteousness. And upon that realization I composed these verses, which I dedicate to the Proxy, in admiration, may it ever watch over us sinful software developers, and keep us from temptation.

Oh Proxy, wondrous, on the net
Above us like the moon, so silvery grey
By blocking sites you never let
We software developers go astray.

You keep us, and guard us, and ensure that we
are never tempted from our tasks
You maintain our morality
But sometimes relent, if we ask.

Oh Proxy, how glorious are thee
A shepherd for this software flock
Forgive us if we question thee
On why you chose Stack Overflow to block.