The third hardest thing in IT? Hiring a JavaScript developer

When I started programming in 2001… I could open just about every article that way by now. The world somehow seemed simpler, or maybe that's nostalgia. I started as a frontend developer. I think we called it web application development then. My toolkit included the usual HTML, CSS, JavaScript, knowledge of browsers (which at the time meant Internet Explorer and, I suppose, Mozilla or Netscape?), and a little of the more obscure stuff, such as XML and XSLT. In those days, the height of excitement was getting document.getElementById to work. I'm serious. The specifications must have been smaller or simpler, since one person was expected to handle it all. It was quite practical too. Today you have a designer, an HTML coder and a JavaScript developer doing what I did on my own. I knew what would work and how to do it, and I managed to avoid shooting myself in the foot. And of course it was cheaper. Working on a web application, or more accurately on its face, was seen as your ticket into the ranks of real programmers. A bit like getting into secondary school. It changed nothing, but you felt better. I left that world after a few years and followed web technology through what I picked up from colleagues or guests on our @czpodcast.

I paid attention, so I did not miss jQuery, YUI, the rise of MVC frameworks such as Angular.js, and everything up through React.js, isomorphic applications and the arrival of JavaScript as an established server-side technology. I heard about the trouble we had at @gooddata with Ember.js, the difficulties hiring and the rewrite in React.js. But I only understood how serious it was at @zonky_cz. Finding capable JavaScript developers is practically impossible. It is the third hardest thing, after cache invalidation and naming things.

In what follows, feel free to swap in your favorite technologies and frameworks. In the JavaScript world you can count on mentioning technology A and hearing about B, C, D and E. I'll explain in a moment. We use Angular.js and Ember.js, and we are moving from Angular.js to Ember.js. There are two views on that framework. One is that it is terrible and we're mad. The other is that it isn't bad. The first view is more common, which might mean the majority is wrong. It wouldn't be the first time. One feature of the JavaScript world is its immaturity, summed up by the quip, “Every day there is at least one new framework.” I remember our JavaScript friends mocking Maven as if it were yesterday. “It downloads half the internet,” they said. Then they came up with NPM. They just forgot about pinning versions and making transitive dependencies immutable. Then someone deleted the library for left-padding and broke the other half of the internet.

Our inability to find Ember.js developers could be down to several things.

• Everyone wants to work with React.js or Angular 4, or whatever version the clever people at Google are calling it now.
• The framework really is rubbish.
• There simply are no developers.
• Our project is uninteresting.

I'll leave the last point aside for now and come back to it later. Nobody believes the second-to-last point. The second might follow from the first, so let's look at the first. Does everyone really want to work with a single technology, React in particular? I thought we could hardly go wrong with React. Surprise. Judging by the reactions, the world is moving with Vue.js instead of React and with Elm instead of ECMAScript. Well, excuse me.

And so it goes with everything in JavaScript.

There is no equivalent to a written or unwritten standard like Java's Spring Framework, much mocked by Jiri Fabian ☢. What fascinates me is that developers give no thought to the product they would work on. Since we're on React, Facebook is the obvious example. You have surely come across plenty of people who turned up their noses at PHP. I would bet a month's salary that nine out of ten of them would go to Facebook in a heartbeat. They would even write Perl just to be there. I keep saying it. Focus on the product and the business, and the technology will follow. Sadly the tendency is the other way round, with technology coming first. I have no idea whether that is because it improves their job prospects, because they want to play with something new, some combination of the two, or something else.

For all my fondness for React, this seems like a dangerous game for a company to play with developers. Say I found five React.js developers because it is fashionable now. What would happen if Elm were in fashion in a year? Would we rewrite everything? It is unlikely all five would agree. The team would be more likely to fall apart. You can play this game, but you will always be at a disadvantage. I do not think technology should be the main criterion. If it is, you have to ask whether you want that developer at all.