Apprenticeships are in the news today here in the UK, with the rather shocking revelation that since the government introduced their new apprenticeship levy scheme – where employers must pay 0.5% of their income into a special government-run “bank” to be used to fund apprenticeships of all kinds – the number of people starting apprenticeships has actually fallen.
I met with the people in charge of the scheme, and was less than hopeful that it would actually work – especially in our industry. Time and again I see decision makers vastly underestimate the time and resources needed to grow a software developer, and their planned software developer apprenticeship looked lacking, too. Later, I heard from multiple employers who’d taken on dev apprentices, and they were really struggling with the lack of practical support. Who will teach these young developers? Who will mentor them? How long is it really going to take before we can leave them to work unsupervised?
The sad fact is that many of these employers just heard “cheap developers” and didn’t stop to think “Ah, but why so cheap?” The brutal answer is: because they’re not developers. Yet. The whole point of the apprenticeship is that you turn them into developers. And training a software developer takes a lot of time and lot of money.
If you saw that one house on a street was half the price of the other houses, would you not stop to ask “why?” In the case of apprentices, it’s because you only bought the land. You have to build a house on it.
The main sticking point here is that somebody who knows what they’re doing has to make themselves available to help the apprentices learn. And they need to be very available, because that requires a big investment in time.
Our industry, though, has structured itself to make this investment unworkable. The most senior developers are either too busy getting shit done, or they’re not active developers any more. With the best will in the world, no amount of transferrable skills are going to get transferred if the person who has all that useful knowledge last programmed in COBOL on an IBM mainframe. It would be like being taught economics by someone who only speaks Anglo-Saxon.
In order to square this circle, our industry needs to be restructured to make sustained, in-depth skills transfer possible.
This is how it could work:
- At the start of a developer’s career, the most productive thing they can do with their time is learn. Career’s should start with a few months of nothing but learning. All day. Every day. A coding boot camp might be a model to follow here – provided we all acknowledge that the learning doesn’t end with boot cam graduation. It’s just a kick-start.
- After graduating boot camp, developers become apprentices. They work on real teams doing real work 3-4 days a week, with a the other 1-2 days released for further dedicated, structured learning. This would continue for 2-3 years as they build their skills and their confidence to a point where employers feel happy leaving them to work unsupervised. It might even lead to a degree, to validate their progress.
- Once they’ve completed their apprenticeship, developers pay their dues and return the investment employers have made in them by delivering working software of real value, while continuing to gain experience and learn more and more. There might be a decade or more of this real-world work. They continue to be mentored by more experienced developers, but in a more hands-off kind of way. A nudge here, a kind word there etc. Enlightened employers will recognise that dedicated learning time is still a wise investment, throughout a developer’s career. They may still devote 10-20% of their time to this, but at this level of achievement, it’s more like doing a PhD. We might expect developers to eventually add their own contributions to the software development landscape in this phase of their career. Maybe write a useful new tool, or invent a new technique. Maybe speak at conferences. Maybe write a book.
- During this – and I hesitate to use this term – “journeyman” phase, developers may find they’re called upon increasingly more to mentor less experienced developers, and to share their knowledge freely. I believe this is an important part of a developer’s progress. I’ve found that what really tests my understanding of something is trying to explain it to other people. An increasing emphasis on sharing knowledge, on mentoring, and especially on leading by example, would mark the later stages of this phase.
- Eventually, developers reach a phase in their career where the most productive use of their time is teaching. This is the “profess” in our profession. And this is where we square the circle. Who is going to do the teaching in the boot camps? Who is going to train and mentor the apprentices? Simple answer: we are.
Now, for sure, not every developer will be cut out for that, and not every developer will want to go down that route. Some will become managers, and that’s fine. We need more developers in technology management positions, frankly. But your average corporation doesn’t need 20 CTOs. It may well need 20 active mentors, though – keeping hands-on with the latest tools and technologies so they can offer practical help to 100 less experienced developers.
At present, in the vast majority of organisations, no such career path exists. We are set up to move away from the code face just at the time when we should be working side-by-side with apprentices. I had to invent that role for myself by starting Codemanship. Had such roles existed for someone with 20 years’ experience, there would have been no need. I didn’t start a business to start a business. I started a business so that – as the boss – I could offer myself my ideal job.
And, as the boss, I understand why this job is important. It’s the most useful thing I can offer at this stage in my career. This is why I believe it’s important that more bosses come from a software development background – so they can see the benefits. As it stands, employers – for the most part – just don’t get it. Yet.
There’s more at stake here than pay and perks for developers who might progress beyond the current career ceiling that too many organisations impose on people who still write code. One factor that strongly determines the way a business invests its money is who is holding the purse strings. I sometimes rail at the infantalisation of software professionals, where we must go cap in hand to “mummy and daddy” for the most insignificant of purchases. If I need a new monitor at home, I go out and buy a new monitor. Easy. In the world of corporate tech, not so easy. I recall once having multiple meetings, escalating all the way up to the Director of IT, about buying a £200 whiteboard.
If the budget holders don’t understand the technical side of things – perhaps they never did, or it was so long ago they were directly involved in technology – then it can be hard to persuade them of the benefits of an investment in tools, in books, in training, in furniture, etc. As a business owner, I experience it from the other side, watching in dismay the hoops some teams have to jump through to get things they need like training.
Codemanship training does not appeal to CTOs, on the whole. Most don’t see the benefits. They buy it because the developers tugged at their sleeve and whined and pleaded long enough that the boss realised the only way to make them shut up was to buy a course. In that sense, code craft training’s a bit like the candy they display at supermarket checkouts.
A very few more enlightened companies let their developers make those decisions themselves, giving them budgets they can spend without having to get purchases approved. But they’re in the minority. Many more teams have to crawl over broken glass to book, say, a TDD workshop.
On a larger scale, decisions about what developers’ time gets invested in are usually not in the developers’ hands. If it were up to them, I suspect we’d see more time devoted to learning, to teaching, and to mentoring. But, sadly, it’s not. They have to ask for permission – quite probably from someone who isn’t a a developer, perhaps even someone who thinks writing software is a low-status job that doesn’t warrant that kind of investment in skills.
When that changes, I believe we will finally square the circle.