It’s always interesting when something you post on social media seems to chime with what a lot of people think. Yesterday, I posted this:
1. “What if we train them and they leave?” What if you don’t train them and they stay?
2. “We can’t afford 20% time.” But you *can* afford to do everything the hard way 100% of the time?
3. “Our best devs are too busy to mentor juniors.” That’s *why* they’re too busy
— Codemanship (@codemanship) March 2, 2019
Judging by the likes and retweets, as well as the replies and comments, this is a debate many of us have had.
I’ve posted many times before about how most employers of software developers have an expectation that we arrive fully formed with all the skills and experience they need. They make little time and offer little support for learning as part of the job. This is one of the underlying causes of the so-called “skills crisis” in our industry: employers will wait to find someone with Java 9 experience, but won’t wait for someone with Java 8 to get up to speed.
But be absolutely sure: learning is part of this job. Arguably learning is the job. We’re innovating all the time, and that implies that we’re continually solving new problems and continually learning. It’s one of my fundamental principles of software development: it’s a learning process.
If you condemn developers to learning entirely by trial and error, with no input from other, more experienced developers who’ve “been there, done that and got the t-shirt” – whether it’s in person, from books, from blogs, from videos – then a great deal of their time – and your money – will be wasted making all the same mistakes all over again.
And if you give them no time to learn and adapt from their own mistakes – through retrospectives, root cause analysis, Kaizen and the other continuous improvement activities – then you condemn your dev teams to perpetual Groundhog Day, doing everything the hard way, again and again and again.
The smart dev organisations make time and space and assign resources to learning, sharing knowledge and continuously improving. It could be through ongoing training (pretty rare), or dedicated 10-20% time for teams to learn, experiment and improve (very rare), or structured long-term mentoring (vanishingly rare).
Many organisations expect these things to happen outside of working hours, in the developer’s own time. Indeed, many developers expect that, too. It’s a regrettable fact in this industry that if you want to learn and progress, you will probably have to invest a lot of your own time, energy and money into making that happen. This is bad news for us all when potentially great developers, with bags of smarts and heaps of aptitude, also have tonnes of outside commitments – young children, elderly relatives, volunteering in their communities, or just generally having a life outside of software.
When the signal goes out, loud and clear, “If you want to be successful as a software developer, forget having a life”, we shouldn’t wonder why the profession lacks diversity.
How do we change this? I’ve said this before, but it bears saying again: the time and resources for continuous learning will not be freely given, even when we know it’s in the best interests of employers. We must take it.
Codemanship's Blog 