web development today is giving me a heckin’ concern, a big heckin’ concern…

One of the recurring themes on this blog is that the world is changing very quickly and automation is making millions of workers obsolete. But say you happen to be one of the people doing the automating. What safer job could there be? You’re like the job Grim Reaper whose work may be disputed for many valid reasons, but ultimately seen as necessary, so you might think of yourself as immune to the march of progress. But what if I were to tell you that you might not be? What if I posited that we may be knocking the very first rungs off the career ladder for techies and turning the industry into a kind of tournament system starting with web development and extending into robotics over the course of the next decade or so? Crazy, right? But as I’ve spent more and more time over the past year or so more removed from writing the actual code than doing more code reviews, design, research, and prototyping, there’s something that stood out for me, and that something gave me some rather uneasy thoughts, which I hope are an overreaction.

While many posts on personal blogs and articles on Medium very accurately groan about the unwieldy complexity of setting up a website today, once you remove all the fluff, you’ll find that much of web development today is often taking existing open source libraries, customizing their appearance, making a few tweaks to their basic functions, and stitching them together into a full product that does either some basic CRUD (user-driven create, edit, update, delete) functionality, or ETL (extract, transform, and load data from another database or API) processes. Many of these resulting apps will be some sort of content management system, many will be glorified search engines, and a whole lot of them in the enterprise world will be a combination of both. The real innovations will be found in algorithmic tweaks to an industry-specific process, but just assembling the basic UI seems to be a matter of following a basic tutorial unless you really want to make it hard on yourself and do it all from scratch until you reach for Bootstrap and decorate it a bit.

But why are these things seemingly so hard to set up if we basically got them down pat by this point? A big part of the reason is that we’re seeing interest, investment, and effort in developing Javascript, long thought to be just a toy language for web designers or amateurs, into a serious contender in the dev world. And this is in no way problematic. Javascript has a lot of things going for it, like ease of use and deployment, platform independence, and a syntax that’s very familiar to pros and welcoming to newbies. But the rush to take it from a tool of choice for UI scripts to a full stack language with frameworks to handle almost any kind of project, came with serious growing pains. The lack of common tooling, the countless me-too and duplicate packages, and a whole lot of reinventing the wheel plagues the community. Again, this is not necessarily a bad thing, this too shall pass like a bad burrito, because there’s now an engaged community of experts looking to streamline the packages to consolidate them into a set of common tools that will make development far saner for the next generation of Node developers.

I’ve seen the same thing before in the .NET world where the overly complex and bloated WebForms framework gave way to stripped down MVC, which in many ways was a big upgrade of classic ASP and prioritized simplicity to add some degree of intuitiveness in building web interfaces. Javascript will eventually head towards broader conventions and more complete tools that everyone will use, winners of the current package churn. Except here’s a big difference. Once we have this common tooling, we’ll also have an enormous open source infrastructure with almost complete UIs and basic CRUD you’ll be able to download and repurpose with some tweaks. And it makes all the sense in the world to use them. Why pay between $30 and $100 an hour per coder to rebuild something that already exists from scratch? Isn’t that quite wasteful? Don’t we have a market to go to? Create your data model, use an ORM for the basics, snap it into a UI you prettied up, and off you go. You’ll need less time, spend less money, and need fewer coders.

And it’s that last one that alarms me a bit. Junior and mid-level coders are usually the people assigned to do these sorts of tasks. As we’re rushing ever faster to common tooling, common layouts, and open source scaffolding for new projects, we’ll need fewer and fewer of them. What about apps for your phone and computer you say? Those are going to start looking a lot like web pages too if they don’t already because many of them are using Electron; a self-contained browser and web site that turn web apps into desktop ones. A version for phones is a top priority right now as well, so it’s only a matter of time until just knowing Javascript and HTML means you can create any app on any platform and on the web, and deliver a consistent user experience to everyone. Programmers love it, architects love it, and businesspeople love it because all of this is a no-brainer. But again, if all of this is built using some very common scaffolding, fewer people will be required to build it, and very importantly, the easier these common tools will be to use, the easier it will be to source the basics to the lowest bidder, driving entry wages down.

This is unprecedented in computer science right now because we’re just so used to reinventing the wheel, convinced we can do it better, cleaner, and a lot prettier than the last person who did it. There was no vast open source realm to show us that we may have already been bested by someone whose solution to the exact same problem isn’t just as good as ours, but makes no sense to try and improve upon without spotting something obvious. After a few decades of trying to figure out how to do everything, we’re closer than ever to fixed recipes for basic apps. Even when we want to add AI capability to our existing products, we can just ping an API for Google’s Tensor Flow or Microsoft’s Project Oxford and have it do the hard work for us. Innovation is now moving away from UI/UX to big data migrations, robotics, and swarm mechanics. My hope is that this is where junior and mid-level will follow, to start the competition for common tooling in those worlds, and because it’s a cold day in Hell when two companies’ big data needs are identical and need no special algorithms, and each robot design brings its own challenges, this is where we won’t code and design ourselves out of a job…