Learning at Work
--
I came across an interesting discussion recently about learning at work. Although this discussion focuses on learning in a work environment, it struck me that it’s very relevant to what we do here at Launch School.
Our program prepares students for a long-lasting career, but we often stress the fact that Launch School is just the start of a life-long learning journey. As professional developers and software engineers, we are continuously updating our knowledge throughout our careers. This idea of continuous professional development isn’t unique to the tech industry, but due to the rapid pace of change in technology, it’s certainly something that takes on additional significance.
The opening premise to the discussion, that ‘Learning at work is work, and we must make space for it’, evoked a lot of strong opinions and emotive responses. There were many different threads to this discussion, but some of the key recurring themes I noticed were as follows:
- There’s an expectation from many employers, whether implicit or explicit, that their developers stay up-to-date with current and emerging technologies
- Some employers allow specific personal development time as part of a working week, but many others don’t
- Many developers say that they don’t have time to learn at work because there’s an expectation for all of their work time to ‘be productive’
- Some developers feel pressure to learn in their own time to ‘stay current’
There appears to be a clear dichotomy within this entire discussion, between personal development on one side and productivity on the other. Here’s the thing, I don’t think this is a dichotomy at all. Personal development and productivity aren’t two opposing forces pulling in different directions; one can be used to improve the other. Learning about a new design or architectural pattern, or familiarizing yourself with a new library has the potential to increase the quality of your output and so improve your productivity.
“Personal development and productivity aren’t two opposing forces pulling in different directions; one can be used to improve the other.”
If that’s the case, then why are some employers seemingly opposed to their developers spending time on learning? The key thing to understand here, and something that I hardly saw mentioned in this discussion, is that there are different types of learning. The type of learning you need to use to quickly ramp-up on a new tool or technique is called Just In Time(JIT) learning.
The best employers recognize the benefits of JIT learning and look to hire developers and engineers who have this JIT learning ability. JIT learning leverages a solid understanding of programming fundamentals combined with effective study techniques for learning about complex technical topics. It’s this combination that allows you to quickly and effectively learn a new tool, technique, codebase, or even a new language.
“The best employers recognize the benefits of JIT learning and look to hire developers and engineers who have this JIT learning ability.”
JIT learning is very different from Mastery-Based Learning (MBL). MBL focuses on taking the time to learn a topic to depth and is suited to building solid mental models for fundamental concepts. This kind of mastery-based approach can be used to build the strong fundamental understanding that can in turn help to unlock JIT learning.
When discussing learning at work, we need to be clear that not all types of learning are possible in a work environment. Employees shouldn’t expect to use work hours on mastery-based learning. Mastery of fundamental concepts should be part of an engineer’s underlying skill-set. If there are gaps in those fundamentals, they should be worked on during the engineer’s own time. On the other hand, employees should be pushing for JIT learning opportunities at work. If employers don’t already recognize the benefits of this approach, then employees should do what they can to highlight those benefits.
Chris Lee is an instructor at Launch School, an online school for software engineers. He has over 17 years of software engineering experience ranging from large enterprise to startups. He enjoys programming, teaching and talking about Mastery Based Learning.
