Teaching

If you’ve been a subscriber of this newsletter for some time, you might have noticed that education is a recurring theme in my essays. As a professor, it’s quite normal to be obsessed with education. But it’s also because I believe that, like Former Intel CEO Andy Grove used to say: “training is one of the highest-leverage activities a manager can perform.” So when one of my online training participants asked me for advice on how to teach/share knowledge to a software team, I thought it would be an excellent opportunity to write about it.

Wait, don’t software engineers learn on their own?

According to Stack Overflow’s 2018 developer survey, while 35% of respondents received on-the-job training in software development, a staggering 86% of them taught themselves a new language, framework, or tool without taking a formal course. With such inclination to self-learning, it’s easy to understand why so few technology companies organise on-the-job training for their developers. But, while it can be fun to spend several weeks learning a new technical skill through trial and error, time is sometimes of the essence in a business context. Whether you want developers to pick up a specific framework to tackle a new project or to have the whole department change their programming style, guided learning with an expert is always faster than self-learning. You get the core information right away, your questions get answers, and you benefit from the experience of someone who probably went through a lot of errors themselves. But having an instructor doesn’t necessarily mean that the teaching should be top-down.

Peer instruction

When I started teaching, my role model was Robin Williams in the Dead Poets Society. The guy who was able to captivate his entire class with his charisma and speaking presence. Much like TED talks, the problem with one-man-show teaching (which I call edutainment) is that the participants might have a good time, but are likely to retain ten per cent of the information shared and will put into practice just about zero.

That is what physics professor Eric Mazur from Harvard University, unfortunately, realised several years ago. When he started teaching, Mazur always had excellent ratings from students and firmly believed he was a great teacher, until the day he found a test aimed at evaluating the conceptual understanding of some basic physics concepts. To his horror, Mazur realised that, according to this test, his students had learned almost nothing. Yes, they were undoubtedly great at solving the problems seen in class, but they were unable to transfer their knowledge into a different, more practical, context.

The epiphany happened a bit later when he decided to let his students discuss a concept between themselves, after explaining it twice without success. He realised that the students who got the concept managed to explain it much better than him to those who were struggling. This innovative style became known as peer instruction, a structured teaching practice where students read the material before class, have to answer questions in class and then work in small groups to arrive at a consensus. Research by Eric Mazur and others has shown that peer instruction:

• Increases students’ conceptual understanding
• Supports better retention of knowledge
• Increases course satisfaction and retention for students
• Increases student engagement

What’s even more interesting with the notion of peer instruction is that it makes you realise that you don’t necessarily have to hire an external instructor to teach a class at your company. While in theory, you want the best person, the one with the maximum expertise, to be delivering training, your best choice is actually what Laszlo Bock, Google’s former SVP of People Operations, calls the “local maximum”:

“In your company, there is certainly a best salesperson in terms of total sales. By turning to that person to teach others rather than bringing in someone from the outside, you not only have a teacher who is better than your other salespeople, but also someone who understands the specific context of your company and customers.”

That is why 80% of all tracked courses at Googleare run through an employee-to-employee network called “g2g” (Googler-to-Googler), with classes focused on general professional skills, like negotiations and leadership, and role-related skills, like sales training and Python coding.

But organising training courses from the ground up doesn’t necessarily mean that they are delivered most effectively, especially when they’re related to highly conceptual notions.

Effortful learning

In Make It Stick, Peter C. Brown, Henry L. Roediger III and Mark A. McDaniel leveraged the latest research in neuroscience to show that many of existing learning strategies, like rereading and mass practising, are ineffective. Unlike conventional practice, “trying to solve a problem before being taught the solution leads to better learning, even when errors are made in the attempt.” From a brain perspective, neurons retain better when they are traumatised: “learning is deeper and more durable when it’s effortful. Learning that’s easy is like writing in sand, here today and gone tomorrow.”

And the best way to traumatise neurons is to put the knowledge into practice BEFORE you access the theoretical content. It’s like trying to find your way to a new location without GPS; it will be hard, but you will remember your way much better than if you blindly followed Waze directions. When it comes to software, this type of learning is already what developers do on their own when trying to acquire a new skill: trial and error. They start playing with it, make some tests and then go to the documentation or forums when they get stuck.

So how do you recreate this behaviour in a controlled learning environment with just the right amount of what memory researchers Elizabeth and Robert Bjork call “desirable difficulties”? Over the years, I’ve developed the following five-steps protocol for teaching software engineers:

1/ Learning sessions should be short (less than two hours) but spread over a long period. It would be best if you avoided one or two-day-long workshops

2/ Learning sessions should start with a challenge to solve related to the skill in question and, if possible, contextualised for the participants (a bit like business schools case studies)

3/ Participants are encouraged to work in small groups to solve the challenge, and the instructor should help them using the maieutic method without giving them the solution

4/ Once the participants have solved the challenge the instructor can share the best possible solution and summarise the main concepts to memorise

5/ Additional content can be shared before or after the workshop for participants to dig deeper on their own if they want, but I’ve found that no one reads the material when shared before 😅

Remember, courses are products and, like any products, they should be developed iteratively. Try not to spend too much time writing content that might not help in the end help the participants reach their business objectives. You can build a Minimum Viable Training to test your assumptions with beta participants and take it from there.

In summary

• Software engineers usually acquire new skills through self-learning
• Guided learning with an expert is always faster than self-learning
• Peer instruction increases students’ conceptual understanding and supports better retention of knowledge
• The best teachers usually already are in your organisation
• Learning is deeper and more durable when it’s effortful

Additional resources

📖 Work Rules!: Insights from Inside Google That Will Transform How You Live and Lead - Laszlo Bock

📖 Make It Stick - The Science of Successful Learning - Peter C. Brown, Henry L. Roediger, Mark A. Mcdaniel

📼 Peer Instruction for Active Learning - Eric Mazur