May 27, 2014

...Learn TDD with Codemanship

Don't Say "Junior", Say "Trainee"

It's been a very rough coouple of weeks, so I'm just starting to climb back on the horse. But there was something I really felt needed commenting on, so here's a short post about the experience balance of development teams.

A typical model followed by employers in the UK is to hire one or two strong and very experienced developers and get them to lead a team mostly made up of less experienced and less skilled developers.

The problem with this pyramid model is that it just doesn't work. Writing software is complicated. It tales many years to become competent enough to make a decent fist of it at all. Per se, a competent software developer is not a "junior" software developer. They've been doing it, and learning about it, for quite some time.

We've probably all worked on teams where we've seen a couple of good devs scrambling on a daily basis to undo the damage caused by less skilled and/or less disciplined developers. The phrase I hear a lot in this context is anti-work. Far from adding value by throwing more and more warm-but-inexperienced bodies at a problem, it just makes it worse. Two strong developers working together on a problem would normally fare better than the same two strong developers trying to herd a team of half a dozen inexperienced cats. The hedring will take up most of their time - been their, done that - and the rest of their time will be taken up clearing up after them because they're not house-trained yet. (Okay, analogy over.)

It's understandable, in a world where most employers believe that 9 women can have 1 baby in 1 month, that hiring cheaper "junior" developers sounds like good value. But the reality is that it's actually very poor value indeed.

Better, in practice, to hire a smaller number of stronger developers who will get more valuable work done iinstead of wasting their talents on cat-herding and cleaning up the mess.

Ah, but how, then, do "junior" developers learn and become stronger developers?

This is where we turn the pyramid upside-down; smaller teams of stronger developers, mentoring one or two apprentices. So, there's less cat-herding and less litter-cleaning, but still there are the learning opportunities for our developers-in-waiting.

Financially, this model makes the most sense. It takes care of the now, by freeing up more time for good developers to do good development, but still makes room for the future by creating real-world learning opportunities for the good developers of the future.

On the practical side, this shifts the emphasis of what "junior" developers do from the day-to-day grunt work to a focus on learning. We seek good learning opportunities, and - because the "senior" developers are taking care of business themselves - we can prioritise and reward learning over delivery to begin with, so our trainees can focus on doing it right.









Posted 3 years, 9 months ago on May 27, 2014