Deliberate practice: The art of teaching and learning

Gaining knowledge about the tools, code, applications you're working with is a natural process. Just by doing your job you will improve your development skills, while building understanding of the codebase you're working on. This takes time.

My team is a group of experienced and amazing developers, but most of them have only quite recently joined the team. It takes time for any new-joiner to get a feeling for what our application landscape looks like and how applications cooperate.

I wanted to find a way to efficiently share knowledge within my team. To accelerate the time it takes for people to get the bigger picture of what we are working on. I noticed we were sharing knowledge a lot already, through regular presentations, pair programming, pull requests and many other ways. This was great, but it was hard to make sure we addressed certain knowledge gaps using these.

The idea

What I introduced was a more deliberate moment of learning. We would get our hands dirty instead of watching presentations. The topics were focussed on those areas that needed most attention. Everyone was pushed at least a little bit out of their comfort zone.

We did some small and fun exercises. Some examples of exercises we did:

• List all applications we are responsible for from the top of your head. Pick one application that you didn't work with yet, and do a 1 minute presentation about how it works next time.
• Last week we saw a small outage, but the cause is still undetermined. Find the cause.
• Draw all components that are involved in handling a single request from a customer.

These were specifically aimed at some of the knowledge gaps we had. Let's go through the things that I learned while facilitating these exercises.

1. Make it a challenge

It can be hard to really challenge yourself during day-to-day work. You don't want to pick a task to work on and get stuck, you'd rather pick something you know you can do. In general, day-to-day work doesn't feel like a learning opportunity by itself.

But when you create a specific moment for learning, a challenge is good. I tried to design challenges that would push everyone a little bit, outside of the things they normally do and work with. Without the pressure of failing, people are willing to go pretty far outside of their comfort zone.

2. Create pairs

With the challenges I gave my team, a lot of people felt lost. They didn't know where to look or what to do. If they were on their own, they would have been stuck. I learned how important and valuable it is in these cases to create teams.

For most challenges, I found that teams of two are perfect. It is amazing to see how much two people together can build on each others knowledge. Bigger teams often meant the person most out of their depth was left out of discussions. Two really is the ideal number in most cases.

3. Keep challenges short

I try to limit the time we spend on these exercises to half an hour. This keeps the investment of participating pretty low. Also, for some challenges, the added time pressure can help in making it more realistic and sometimes even more fun. For example, in one case we tried to debug a production issue that had happened earlier that week in half an hour. This gave everyone the thrill of having to debug something fast, but without anything on the line.

4. Repeat regularly

We do this weekly, which means we can repeat certain topics as well, to refresh what we've learned. Compared to a training of a day or more, this gives way more room to actually process what you learn. In most cases there are only one or two takeaways per week, which gives everyone time to investigate those a little bit more.

5. Pay attention to what people struggle with

One of the most interesting things I found is that through these challenges, it was way easier to notice specifically which knowledge was missing. While being thrown in the deep, people can more easily describe what it is that makes them feel out of their comfort zone. And because of the more controlled nature of the challenges, there is more room for people to admit they don't know. There's no important feature on the line. There are no customers that are seeing a broken application.

Also, because I made everyone learn about the same thing at the same time, it was easier to see patterns of missing knowledge. This was great input for future sessions.

Conclusion

While doing this I was reminded a lot of school. I guess those people were onto something. Short, focused and regularly repeated sessions are the norm in school. We tell ourselves that as adults we can concentrate for longer, that we can remember what was explained in a couple hours of presentation. But we're not that different from our younger selves.

I would love to know more about how you learn and teach. Please leave a comment with your thoughts!