When Do We Learn?

whendowelearn

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:

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.

Welcome To The NEW Codemanship Blog

It’s a hard thing to move on from something successful, but even though the old Codemanship blog regularly gets more then 10,000 readers a month, I felt it really was time to upgrade the platform.

All new posts will appear here, and you can treat the old blog as an archive of all the good legacy stuff. And what a lot of legacy stuff that is?! More than 1,500 posts in 14 years (yes, the blog predates Codemanship by several years.)

This blog’s feed is what you’ll need to update your reader with if you want to keep up with all my latest spiffy half-baked ideas and opinions.