I write books.
Working with my wife, Dawn, we've just produced our latest: Head First Kotlin. In the last 10 years, we've written 5 books, alongside video series and training courses. Books take many months to produce and require hundreds of hours of research, coding and rewrites to produce.
Not everyone wants to commit to writing a book, but if you work in software, then at some point you need to write something or teach someone:
- You might need to explain what the software should do.
- You might need to coach someone on how they should write the code.
- You might need to train someone to use your software.
You'll need to write proposals, create blogs, invent training courses. Writing and teaching are valuable skills to have.
That new framework you're learning? The one which featured heavily at QCon? The one that created all the buzz at Google IO a few months back? It will be gone in five years.
But writing and teaching are skills that can last your entire career.
In their book Rework, Jason Fried and David Heinemeier Hansson have an entire section called Hire Great Writers. They argue that if someone can write clearly, they can also think clearly. If you can articulate your thoughts, you will be more valuable to companies, and your career will last longer.
Is it possible to learn how to teach? You can get books on standard patterns for creating software, but what about the practical steps of creating teaching material? Is there some way of learning that?
I'll take you through one such technique. It gives you a way to teach anything. Almost anything. There are some things it can't teach:
- Music appreciation
- English literature
However, if you want to teach practical skills or something technical, it should give you a framework to get started.
Before we get into the details of this particular teaching technique, let's take a short diversion back to the 1950s.
Bear with me on this.
In the 1950s the United States Air Force asked Colonel John Richard Boyd to figure out a way to improve American pilots' success in aerial combat. Most people would have begun by looking at the design of the aircraft. They might improve the weaponry, the armour plating or the speed.
Boyd took a different approach. A fighter pilot himself, Boyd realised that the most critical part of the battle zone was between the ears of the pilot. The way that pilots understood and reacted to the combat situation was the critical feature in successful aerial combat.
Boyd worked out that when human beings are in a new situation, they go through four distinct psychological phases. He referred to these four stages by their initial letters: O.O.D.A. He called the whole process the OODA Loop. Let's look at these four stages in more detail.
O - Observe
The first stage of the OODA loop is called Observe. In the Observe stage, the fighter pilot becomes aware of some new situation, such as the appearance of an enemy aircraft.
O - Orient
Next comes the Orient phase. In this stage, the pilot starts to put the new information into context. The pilot might estimate the enemy plane's location, its speed, heading, and armament. The Orient phase is where the fighter pilot starts to compile the list of problems and difficulties that they need to overcome.
D - Decide
The pilot knows what the problems are. Now they need to Decide what to do about them. Will they flee the area, or stay and fight? How will they attack? Which standard strategy will they apply? The Decide phase leads onto the final one.
A - Act
The pilot now carries out the plan they created in the Design stage.
These four stages–Observe, Orient, Decide and Act–happen over and over again during combat.
Boyd did not design the OODA stages; he discovered them. They are merely what all humans do, over and over again, all day.
Once he had uncovered the stages of the OODA loop, Boyd set about creating support systems--like Head-Up Displays--which allowed pilots to go through OODA loops as quickly as possible. If a pilot could process loops faster than the enemy (which he called Getting inside the enemy's loop), then they would invariably win the combat.
OODA analysis is not only used in combat situations, but also in share-trading (high-frequency traders get inside the loops of their competition), sport (basketball players use situational awareness to defeat the other team), and, it turns out, you can also use OODA loops to teach.
Create teaching loops
The OODA loop is the way that your brain receives and processes information from the outside world. When you structure your teaching material in an OODA loop sequence, the person reading it processes it more efficiently. They feel drawn through it and find it more compelling.
Let's look out how we might use OODA loops to teach a complex technical subject, like the React web framework.
React is a vast topic. There are heaps of things that we could teach. Libraries. Design patterns. Internals. The history of the framework.
However, what we need to do is first take that sea of technical information and convert it into a list of skills. Whenever you are teaching anybody anything, you are making an implicit deal. In exchange for giving you their time and attention, you provide the learner with a new skill.
Here's an example list of skills:
- Building custom components
- Reusing code with custom React hooks
- Creating an app
- Managing state within the context
- Splitting code between containers and components
- Designing with the Material-UI component library
Each skill can be expressed using gerunds ("-ing" words). Skills are not collections of technical information: they are ways of doing things.
Now, imagine that you have time to teach only one thing. Focus your attention on the most valuable, most worthwhile, most fundamental skill. Out of this list, we'll choose Creating an app.
Most React apps these days are built with a tool called create-react-app. We could provide all of the details from the create-react-app and show how to use it. Instead, we create an OODA loop sequence. By setting the order correctly, we can make the content more compelling.
Why should someone use the create-react-app tool? Why bother? If the create-react-app tool did not exist, what additional problems would we have?
- We would have to manage our webpack configuration
- We would have to choose our own set of language features
- We would have to select a reasonable set of initial libraries
- We'd need to create a set of npm scripts for building, testing, running, and so on.
By understanding the problems the tool solves, we can motivate the teaching. All good teaching is problem-centric, and so is the OODA loop.
Observe – a glimpse of where we're headed
The Observe phase, remember, is where we become aware of some new situation. It might be a fighter pilot seeing a plane on the horizon. It might be a developer seeing an example React application running. In the Observe phase, you set out what the learner is going to be able to do at the end of the topic. They are going to learn how to build a simple application.
Orient – trouble ahead
The Orient phase creates motivation for the topic. Without a series of problems to overcome, the learner has no reason to learn the technical material.
Decide – hope in sight.
Act – going into combat.
Finally, the Act phase, where, as teachers, we wanted to be all along. However, now the learner is motivated. They have seen what they'll be able to do, understand what the problems are and have the tools to solve them. They are ready to go into combat and learn the material.
Then loop, and loop
You can now repeat the process over and over again — each time you need to consider the list of remaining skills. Pretend you only have time to teach one of them, and for that one skill, create an OODA sequence. Show what they can do, what the problems are and how to overcome them.
In this way, you take the learner through a motivated sequence of skills.
It is all too easy when teaching a technical topic to focus on the technical material and to forget about the student. Instead, like John Boyd focussing his attention on the pilot in the fighter jet, you should focus first on the person who is going to learn.
Write your learning material as you write your software: with the user at the heart of everything you create.
David Griffiths is the author, with his wife Dawn, of 5 books and 4 courses in software development. He is also a consultant at Black Pepper Software.