Whilst the ‘Age of Unicorns’ might sound like some terrible MS-DOS text adventure (oh how I miss you, Hugo), right now there is at least one new $1B startup created every month in the US. That’s all very well and good, but few people actually seem to stop and think about what this huge period of technical innovation means for everyday developers. You know, the guys and girls who actually build the damn stuff. Turns out, there are a lot of us:
As startups focus on disruption and big business focuses on how they can take the good parts to implement within their own monolithic organizational structures, both sides are paying through the nose for good talent. Supply is low, demand is high, and that’s a good place to be if you’re a skilled developer.
But what does being a skilled developer really mean?
Defining Skill
Foregoing the cliché definition of ‘skill’ from some random dictionary, skill in a development sense is almost another way of saying flexibility. Many (but not all) of the ‘good’ developers I’ve met actually associate strongly with calling themselves engineers – we like to understand how things work, we like to solve problems.
Anything between a problem and a solution is a means to an end, and it’s not always just about using what we already know or are most comfortable with. At the best of times this can be wonderfully creative and rewarding, and yet it can be soul-crushingly irritating when you hit a brick wall.
Brick walls are why tutorials exist. It’s why StackOverflow exists. It’s why many find it hard to initially switch to functional programming, and why seamlessly moving from one framework to another is the underlying promise that most books use in their promotional copy. However you spin it, flexibility is an essential part of being a good developer (or engineer, if that’s what you prefer).
The problem is that this mental flexibility is actually an incredibly rare competency to have by default. The skill of learning in and of itself takes practice. Your ability to absorb new information entirely depends on your level of exposure to new thoughts and ideas. Paul Graham’s piece on Why You Weren’t Meant to Have a Boss articulates this better than I can (alongside some other key themes about personal development):
I was talking recently to a founder who considered starting a startup right out of college, but went to work for Google instead because he thought he’d learn more there. He didn’t learn as much as he expected. Programmers learn by doing, and most of the things he wanted to do, he couldn’t—sometimes because the company wouldn’t let him, but often because the company’s code wouldn’t let him. Between the drag of legacy code, the overhead of doing development in such a large organization, and the restrictions imposed by interfaces owned by other groups, he could only try a fraction of the things he would have liked to. He said he has learned much more in his own startup, despite the fact that he has to do all the company’s errands as well as programming, because at least when he’s programming he can do whatever he wants.
This isn’t to say that working in a big organization entirely limits your openness to new ideas, it just makes it harder to express them 9-to-5 in the context of your on-paper role. There are always exceptions to the rule though – the BBC is a great example of a large organization that embraces new technologies and frameworks at a pace that would put many startups to shame.
Staying Updated
It’s hard to keep up with every framework-of-the-month, but in doing so you’re making a commitment to stay at the top of your game. Recruiters exploit this to full effect – they’ll frequently take a list of up-and-coming technologies used by an employer and scour LinkedIn and GitHub to identify leads.
But we don’t just use new frameworks and languages for the sake of it. Adding an arbitrary marker on LinkedIn doesn’t prove that I deeply understand the benefits or downsides of a particular technology, or when it might be best not to use it at all. That understanding comes from experimentation, from doing.
So why experiment with something new in the first place? It’s likely that there will be something to them – they might be technically impressive, or help us get from point A to point B faster in a more efficient manner. They help us achieve something.
It’s not enough to just passively be aware of what’s hot and then skim the documentation. It’s actually really hard to really stay motivated and generate real personal value doing that. To keep up with the rate of technical innovation you need a real interest in your field, and a passion for solving complex problems.
After all, software development really is about creative problem solving. That individual drive and creativity is what employers want to see above all else, hands down. Funnily enough, we also want to see this sort of thinking from our employers:
Turns out we care about how much we’re paid – after all, Apple won’t just give us free iPhones (not yet anyway, Taylor). It just so happens that because supply is low, we can also afford to put making a difference as a priority. Even if we assume ‘making a difference’ is an aspiration you’d align with whilst taking a survey, the relatively minimal gap from salary is a significant indicator of how picky we can afford to be.
Startups want to change the world, disrupt how established businesses work, whilst having a strong cross-functional alignment towards a legitimate, emotionally coherent vision. That fundamental passion aligns very well with developers who want to ‘make a difference’, who also have a strong level of individual drive and creativity. Larger businesses that don’t predominantly operate in the technology sector will have a much harder time cultivating that image.
This way of thinking is just another part of the harsh disconnect between startup culture and the rest of society. It’s hard if you’re not working in technology to understand the private buses, the beanbag chairs, the unlimited holiday policies – all things intended to set startups apart and attract talent that’s in high demand. All those perks exist specifically to attract talented engineers. If JavaScript, Python, or lets even say C++ were common everyday ‘second languages’, things would be very different.
Change is Coming
It’s not hard to identify this deficit in technical skills. You can see it starting to be addressed in government schemes like Code for America. In the UK, England is about to make programming a required part of the curriculum from the ages of 5-16 (with services delivered by Codecademy). In a decade the number of people out there in the job market with strong programming skills will have grown exponentially, specifically because we all collectively recognize the shortage of good engineering talent.
As the pool of readily talented developers increases, recruitment will be less about the on-paper qualification or just having a computer science background – it’ll be about what you’ve built, what excites you or what your OS contributions look like. You can already see these questions emerging as the staple of many technical interviews. Personal growth and learning will be expected in order to stay current, not just as a nice-to-have on top of your Java repertoire. And we won’t be able to be as picky, because there will be more of us around :).
Skilling Up
If that sounded a little like scaremongering, then good. We’re in a job market bubble right now, but the pop will be slow and gradual, not immediate (so maybe we’re in a deflating balloon?). Like any market where demand is high and supply is low, there will eventually be a period where things normalize. The educational infrastructure to support this is being built rapidly, and the increasing availability of great learning content (both free and premium) is only going one way.
Development is more accessible than ever before, and you can pretty much learn the basics of most languages now without spending a penny. When we’re talking about being a skilled developer in a professional market it’s not going to be about what technologies you’re comfortable with or what books you’ve read. It’s going to be about what you’ve built using those technologies and resources. There will always be a market for creative problem solvers, the trick is becoming one of them.
So the key to keeping on top of the job market? Dust off that Raspberry Pi you’ve had in your desk drawer, get back into that side project you’ve let atrophy on GitHub – just get out there and build things. Learn by doing, and flex those creative, problem solving neurons.
And if you happen to need a hand? We’ll probably have a Packt book on it. Shameless plug, right?
During June we surveyed over 20,000 IT professionals to find out what technologies they are currently using and plan to learn in the next 12 months. Find out more in our Skill Up industry reports.