Use Task Analysis to Break a Skill Into Steps

Summary: Many technical books skip very important skills you need to complete a task. To avoid skipping those skills, use task analysis to break a skill into steps.

This image reminds me of so many programming language books. The first chapter introduces the syntax, the second chapter is about writing a blog. What about all the stuff in the middle? I work hard in the LispCast courses to avoid skipping these steps.

The problem is clear: most technical skills are actually made up of hundreds if not thousands of smaller skills. I mean, tons of small decisions, perceptual skills, motor skills, etc. It's amazing really what people can chunk into a single idea. There are illustrators who think of the process as two steps. Likewise, many programmers are really good and think of complex code in two steps.

Our job as teachers is as clear as the problem: break down a skill into all of the smaller skills, then teach each of the smaller skills and how they lead to the big skill. It's so easy to state, and yet most people don't do this, even when they're writing for a beginner audience.

Why do so many programming language books spend so much time on syntax but fail at the intermediate stuff? It's because syntax is easy and usually already broken down for you. Once that's covered, it's hard to know the next step to teach if you haven't done the work of discovery. But they also focus on trivial stuff, like how to type literal integers. Hello? Really? If you bang on the number keys you can make integers.

So, how do you do it? How do real teachers do it? It's actually kind of boring. The kind of boring process that you might look at and say "oh, well, obviously". The process is simply to do it yourself and keep notes about every little thing you did. Ask yourself really specific questions like "Why did I start with two circles? Why do they overlap?"

How do I make use of it in LispCast? I always start with the code I want my learners to be able to write. I write it all out first. Then I start breaking it down. Every construct (if statement, library function, etc.) is obviously something to teach. Then there are the value-add things, like why I chose one way over another. What questions do I ask myself to make the decisions? All of these things can and should be steps.

Now, the next step is matching the steps to the learners. Maybe they already know something, so I can just mention it or if it's well known, just do it without mentioning it. Some things might still be difficult, so I might need to break them down further.

At the same time, it could be better to avoid a certain concept. Like if you'd normally do it with a cond but they already know if, perhaps you should stick to what they know so you don't have to add several minutes to explain something that's not relevant to your topic. I try to go deep, so it's important to minimize the breadth of the material in order to finish on time. All of these little skills go into a curriculum, which I'll talk about in a future post.

I don't think this process is hard or original. I learned it from a book about teaching. I do think that most people who write technical books might be subject-matter experts, but they don't have any training in teaching. Teaching is a huge advantage. Even a simple process like this could really differentiate you from the other technical authors out there. And breaking down a task tells you what you need to teach (no more writer's block).

If you like the idea of teaching technical material, please sign up for my Technical Teaching mailing list, where I'll occasionally share skills for making material that helps people learn.