Collective Learning
Many employers say they value continuous learning for software engineers, but what does that usually look like? In my experience, at most it involves a learning tool subscription and an annual company-paid conference. Even those perks are sometimes ahead of the curve and learning is something the boss expects you to do on your own time.
The reality of continuous learning is that humans are social creatures that learn from each other more effectively than by themselves, and we learn from failure far more quickly than from success. Unfortunately, the status quo for software team learning is a misunderstanding of these truths and this results in a misalignment of incentives. Most engineers who have access to a learning tool, and even a departmental directive to use it some percentage of their time, will rarely motivate themselves to set aside the urgent tasks assigned to them individually, or to their team.
How does a manager interested in software engineering excellence help create a culture of continuous learning? There is no single, simple solution to this problem.
In those fleeting moments where engineers sit together to solve a problem collectively, we build trust, share wisdom, and debate ideas until they are better than any one of us could have come up with on our own. My last team made a daily habit of this practice, one of many reasons I felt such satisfaction and learned so much while working with them. I believe we all should strive to do this much more often, perhaps even the vast majority of the time.
If you think this sounds extreme, I agree with you.