The Experience Paradox

One sentiment I hear very often from managers is how very difficult it is to hire experienced developers. This, of course, is a self-fulfilling prophecy. If you won’t hire developers without experience, how will inexperienced developers get the jobs they need to gain that experience?

I simultaneously hear from new developers – recent graduates, boot camp survivors, and so on – that they really struggle to land that first development job because they don’t have the experience.

When you hear both of these at the same time, it becomes a conversation. Unfortunately, it’s a conversation conducted from inside soundproof booths, and I’m seeing no signs that this very obvious situation will be squared any time soon.

I guess we have to add it to the list of things that every knows is wrong, but everyone does anyway. (Like adding more developers to teams when the schedule’s slipping.)

Organisations should hire for potential as well as experience. People who have the potential to be good developers can learn from people with experience. It’s a match made in heaven, and the end result is a larger pool of experienced developers. This problem can fix it itself, if we were of a mind to let it. We all know this. So why don’t we do it?

At the other end of the spectrum, I hear many, many managers say “This person is too experienced to be a developer”. And at the same time, I hear many, many very experienced developers struggle to find work. This, too, is a problem that creates itself. Typically, there are two reasons why managers rule out the most experienced developers:

  • They expect to get paid more (because they usually achieve more)
  • They won’t put up with your bulls**t

Less experienced developers may be more malleable in terms of how much – or little – you can pay them, how much unpaid overtime they may be willing to tolerate, and how willing they might be to cut corners when ordered to. They may have yet to learn what their work is really worth to you. They may have yet to experience burnout. They may yet to have lived with a large amount of technical debt.

Developers with 20+ years experience, who’ve been around the block a few times and know the score, don’t fit it into the picture of developers as fungible resources.

By freezing out inexperienced developers and very experienced developers, employers create the exact situation they complain endlessly about – lack of experienced developers. If it were my company and my money on the line, I’d hire developers with decades of experience specifically to mentor the inexperienced developers with potential I’d also be hiring.

Many employers, of course, argue that training up developers is too much of a financial risk. Once they’re good enough, won’t they leave for a better job? The clue is in the question, though. They leave for a better job. Better than the one you’re offering them once they qualify. Don’t just be a stepping stone, be a tropical island – a place they would want to stay and work.

If you think training up developers is going to generate teams of cheaper developers who’ll work harder and longer for less, then – yes – they’ll leave at the first opportunity. Finding a better job won’t be hard.

4 Out Of 5 Developers Would Choose To Stay Developers. Is It Time We Let Them?

Following on from yesterday’s post about squaring the circle of learning and mentoring in software development, a little poll I ran on Twitter clearly shows that a large majority of software developers would prefer to stay hands-on if they had the choice.

I’ve seen many developers over my 28-year career reluctantly pushed into management roles, and heard so very many talk about how much they miss making software with their own hands. But in too many organisations, the only way to progress in terms of seniority and pay is to move away from code.

Some choose not to progress, making do with the pay and the authority of a developer and biting their tongues when managers who haven’t touched code in years tell them to do silly things. But then we often find that ageism starts to kick in eventually, making it harder and harder to get hired in those hands-on roles. “Why is she still coding?” There’s an assumption among hirers that to still be in these “less senior” roles at, say, 45 is a failure to launch, and not a success in being exactly where you want to be, doing what you love.

A conversation I had recently with a team highlighted what can go wrong when you promote your best developers into non-development positions. They found themselves have to refer technical decisions up to people who no longer had a practical grasp of the technology, and this created a huge communication overhead that wouldn’t have been necessary had the decision-making authority been given to the people responsible for making those decisions work.

I’ve always believed that authority and responsibility go hand-in-hand. Anyone who is given the responsibility for making something happen should also be given the necessary authority to decide how to make it happen.

Not all developers welcome responsibility, of course. In some large organisations, I’ve seen teams grow comfortable with the top-down bureaucracy. They get used to people making the decisions for them, and become institutionalised in much the same way soldiers or prisoners do. What’s for dinner? Whatever they give us. When do we go to bed? Whenever they say. What unit testing tool should we use? Whichever one they tell us to.

But most developers are grown-ups. In their own lives, they make big decisions all the time. They buy houses. They have kids. They choose schools. They vote. It’s pretty wretched, then, seeing teams not being trusted to even purchase laptops for themselves. When teams are trusted, and given both responsibility and authority for getting things done, they tend to rise to that.

And developers should be trusted with their own careers, too. If they were, then I suspect there’d be a lot more active coders with decades of experience to share with the ever-growing number of new developers coming into the industry.

How A Developer’s Career *Should* Work

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.

Standards & Gatekeepers & Fitted Bathrooms

One thing I’ve learned from 10 years on Twitter is that whenever you dare to suggest that the software development profession should have minimum basic standards of competence, people will descend on you from a great height accusing you of being “elitist” and a “gatekeeper”.

Evil Jason wants to keep people out of software development. BAD JASON!

Well, okay: sure. I admit it. I want to keep people out of software development. Specifically, I want to keep people who can’t do the job out of software development. Mwuhahahahahaha etc.

That’s a very different proposition from suggesting that I want to stop people from becoming good, competent software developers, though. If you know me, then you know I’ve long advocated proper, long-term, in-depth paid software developer apprenticeships. I’ve advocated proper on-the-job training and mentoring. (Heck, it’s my entire business these days.) I’ve advocated schools and colleges and code clubs encouraging enthusiasts to build basic software development skills – because fundamentals are the building blocks of fun (or something pithy like that.)

I advocate every entry avenue into this profession except one – turning up claiming to be a software developer, without the basic competencies, and expecting to get paid a high salary for messing up someone’s IT.

If you can’t do the basic job yet, then you’re a trainee – an apprentice, if you prefer – software developer. And yes, that is gatekeeping. The gates to training should be wide open to anyone with aptitude. Money, social background, ethnicity, gender, sexual orientation, age or disabilities should be no barrier.

But…

I don’t believe the gates should be wide open to practicing as a software developer – unsupervised by experienced and competent mentors – on real software and systems with real end users and real consequences for the kinds of salaries we can earn – just for anyone who fancies that job title. I think we should have to earn it. I think I should have had to earn it when I started out. Crikey, the damage I probably did before I accidentally fell into a nest of experienced software engineers who fixed me…

Here’s the thing; when I was 23, I didn’t know that I wasn’t a competent software developer. I thought I was aces. Even though I’d never used version control, never written a unit test, never refactored code – not once – and thought that a 300-line function with nested IFs running 10 deep was super spiffy and jolly clever. I needed people to show me. I was lucky to find them, though I certainly didn’t seek them out.

And who the heck am I to say our profession should have gates, anyway? Nobody. I have no power over hiring anywhere. And, for sure, when I’ve been involved in the hiring process, bosses have ignored my advice many times. And many times, they’ve paid the price for letting someone who lacked basic dev skills loose on their production code. And a few times they’ve even admitted it afterwards.

But I’ve rarely said “Don’t hire that person”. Usually, I say “Train that person”. Most employers choose not to, of course. They want them ready-made and fully-formed. And, ideally, cheap. Someone else can train them. Hell, they can train themselves. And many of us do.

In that landscape, insisting on basic standards is difficult – because where do would-be professional developers go to get real-world experience, high-quality training and long-term mentoring? Would-be plumbers and would-be veterinarians and would-be hairdressers have well-defined routes from aspiration to profession. We’re still very much at the “If You Say You’re A Software Developer Then You’re A Software Developer” stage.

So that’s where we are right now. We can stay at that level, and things will never improve. Or we can do something about it. I maintain that long-term paid apprenticeships – leading to recognised qualifications – are the way to go. I maintain that on-the-job training and mentoring are essential. You can’t learn this job from books. You’ve got to see it and do it for real, and you need people around you who’ve done lots of it to guide you and set an example.

I maintain that apprenticeships and training and mentoring should be the norm for people entering the profession – be it straight of high school or after a degree or after decades of experience working in other industries or after raising children. This route should be open to all. But there should be a bar they need to jump at the end before being allowed to work unsupervised on production code. I wish I’d had that from the start. I should have had that.

And, yes, how unfair it is for someone who blundered into software development largely self-taught to look back and say “Young folk today must qualify first!” But there must have been a generation of self-taught physicians who one day declared “Okay, from now on, doctors have to qualify.” If not my generation, or your generation, then whose generation? We can’t keep kicking this can down the road forever.

As software “eats the world”, more and more people are going to enter the profession. More and more of our daily lives will be run by software, and the consequences of system failures and high costs of changing code will hurt society more and more. This problem isn’t going away.

I hope to Bod that the people coming to fit my bathroom next week don’t just say they’re builders and plumbers and electricians. I hope to Bod they did proper apprenticeships and had plenty of good training and mentoring. I hope to Bod that their professions have basic standards of competence.

And I hope to Bod that those standards are enforced by… gatekeepers.