The head chef shouldn’t chop vegetables
There is a world-wide shortage of developers. The gap between developers needed and developers available is ever increasing. This means that the amount of software that stays unwritten, the bugs that never get fixed and the user experiences that never get improved keep growing.
The direct and unavoidable consequence of lack of developers is a worse digital experience for all.
With the growing cost of development we also see a growing digital disparity: when only a few can get their digital needs fully met, the group that ‘wins’ is the group with the most money. This is why the mobile application for the CEO gets delivered with great UX and in record time, while other employees consistently have to close the same popup every minute for over three years before the bug finally gets fixed.
On top of that we see that the (lack of) diversity of those who design and build IT products directly reflects the ability of those products to deal with a diverse user set. (For a classic example: look at the difficulty facial recognition technology has with correctly identifying people from different races.)
We all spend a lot of time interacting with technology, both voluntarily or as part of our day-to-day obligations. Software sometimes sucks due to lack of developers, and that matters. Not just because it hampers the future, but also because it adversely impacts the now.
So what are we going to do about it?
To start with the obvious: we need to grow the number of developers. The obvious place to get them from is from the groups that have been consistently been underrepresented in development: women, people who aren’t white, and so forth.
I suspect that demographical attributes like sex, age and race do not affect peoples’ affinity for technology, but it definitely has affected entry into the development profession. So if you are looking for unutilized technical talent you are more likely to find it in these groups. As a bonus we would have a more diverse developer population, which could improve the digital experience for certain groups of users.
Clearly we should continue encouraging young white males to become developers as well, it is all hands on board in the development world. And just as a point of nuance: there are plenty of reasons young white males might have self-selected out of becoming developers too, some of which are discussed later on.
Secondly, we should clearly try to avoid losing existing developers to other career paths. I spend my working hours talking to people in IT adjacent functions, and I find that there are a lot of people who introduce themselves as ‘used to be a developer’.
People move out of the developer role all the time; either because their career takes them to management or architecture roles, or because they do not enjoy writing code as much anymore after doing it for ten years.
I am not going to argue that developers should not be allowed to have careers, and I think there is a lot of value in an Architect or IT manager with in-depth technological knowledge.
However, sometimes moving out of development is the only way for someone’s career to progress to new challenges or responsibilities. Those who leave out of boredom might not always become great managers or brilliant architects, but they are definitely a loss to the development world.
So why do developers sometimes bore-out? Just a short google and you’ll find that most anecdotes are about fundamentally unchallenging tasks, long projects that call upon the same skills over and over again or not being asked to understand the bigger picture.
Learning a new programming language can be fun, solving a specific problem for the first time can be a stimulating puzzle and even being able to do something well due to experience has its charm. But when you find yourself routinely doing the exact same task without understanding how your contributions solves problems….? Yeah, you get bored.
Think of the career of a chef: at culinary school they learn how important it is to chop vegetables, and learn how to do it well. They start their career path as a sous chef: chopping vegetables and doing other preparations for cooking. It is important for them to build these skills, and they will continue calling on them when they move up in the kitchen hierarchy.
However, as their careers progress they learn new skills and contribute with new expertise, while others chop vegetables for them.
When low-code gets introduced in organizations, I often hear people say: “Oh, if we had had this when I was a developer, I might still be one.”
It is not inherently more fun to drag and drop than write, of course, but low-code does shift peoples attention from the coding itself to the puzzle solving aspects of programming.
Just like a head chef should only occasionally have to chop their own vegetables, a “head developer” a.k.a. a Software Engineer) should only occasionally have to write their own code.
This also nicely bridges into the third item on how to address the developer gap: We will have a developer shortage for the foreseeable future. So lets use the development time we have as effectively as possible.
Luckily the IT world has been building accelerators for as long as IT has existed. We have moved up several abstraction levels in code, we have been building open source libraries and setting up an impressive amount of API’s to fill parts of our solutions. The world is filled with software packages, services and other accelerators. Lets use them.
This means shifting the paradigm from thinking that programming means building things from scratch, to understanding programming as a way of assembling existing functionalities where possible.
We think of chefs as someone who creates meals, not of someone who chops veggies. Similarly we should think of developers as someone who creates software, rather than someone who writes code.
In short: I do not aim to argue that coding is an irrelevant skill in developers. Rather, that as developers progress through their careers and assembly becomes more important in the market, it is a mistake to have a rigid focus on coding ability alone.
By making this paradigm shift we might succeed in keeping more developers interested in the long run. We might also be able to attract people who would love to be someone who creates software, but can’t imagine themselves as someone who writes code.
With all of these approaches together, more bugs will get fixed, user experiences will be improved and more software will be created.
I hope it all ends with a better digital world for all. (Including the developer.)
