I’ve had an amazing time teaching aspiring software developers. Over the course of the last four years I’ve had the privilege of teaching over 400 students how to use Linux, how to build their first web sites, and how to write their first software applications. I’ve met some truly incredible people and forged some great relationships which I hope continue on for many years. But today I turned in my letter of resignation and am looking forward to what lies ahead. I’ve accepted a job offer that was too amazing to pass up, but more on that later.
I’ve learned so much from this experience. I’ve learned how to teach a diverse group of people. I’ve become more comfortable than ever dealing with politics, time crunches, leadership changes, disgruntled customers, and of course, the fundamentals of computer programming. In order to teach those things well, I had to go back and relearn things myself. I now have big ideas about teaching software development to adults, and I hope to share those thoughts as time permits through various outlets.
I’m leaving behind an incredibly talented and wonderful team. They’re among the best people I’ve ever known and they’re going to continue to do great work. I will miss them. I will miss the students as well. It’s incredibly rewarding to see someone transition from knowing nothing about programming to a professional software developer who can do great things for others and provide for their families. I have so many stories like that and am fortunate to have been a part of that journey for these four years. I am forever thankful for that.
But it’s time for a change. I’ll announce exactly what that change is when the time is right.
In the mean time, I’m still hacking on Codecaster and working on a couple of other projects. And I’ll continue to find ways to help people get better at software development.
I’ve been around software development a long time, and a reoccurring theme is to see this kind of feedback from peers:
I’ll never understand the logic behind [some thing I think is dumb / disagree with strongly].
If you’re not using [some technology I like] you’re doing it wrong.
Or a variant of
You’re using [some programming technique I think is dumb]? Well I write big applications. [that thing you’re doing] doesn’t [scale / work well / work at all].
This is so common it’s part of our vocabulary now. And I think we say these things without even thinking about how negatively they can affect people.
When I started teaching, I found myself having to constantly give feedback, and I had to learn to do it in a way that would improve the skills of the recipient. And I think that’s what people are trying to do with these kinds of comments. We all have experiences that we want to share. But in the world of 140 character tweets, it’s hard to do that. It’s easy to be unintentially snarky in a tweet, pithy in a pull request comment, or terse in an email.
So strive to get the behavior you’re after instead. By being a good critical friend.
Ask questions that provoke. Provide actionable suggestions. For example:
I notice you used [x instead of y]. I like y because [some amazing thing it lets me do.] You should spend a few hours with it; you’ll be amazed!
That one works because you have experience you can draw from. But it’s only valid if you’ve actually used both. Don’t just shoot down something you’ve never used.You’ll look like a fool. Experienced programmers are pretty smart about figuring out if you know what you’re talking about.
There’s also this angle, which is similar, but more focused on negative side affects:
I notice you’re using [x instead of y]. I did that a few times and it bit me hard. I wouldn’t recommend it because [x,y,z].
See, starting with one of those things contributes to the overall goal; you want to convince them to use your idea, your approach, your methodology.
You could even go farther. It’s never a good idea to assume they have the same situation you do, so why not ask?
I noticed you’re [doing x.] I’ve had problems with that in the past, but I’d love to know why it’s working for you.
I’ve never had much luck with [doing x]. What benefits are you getting out of it?
This helps the person fill you in on their situation, if they care to engage in the conversation. It lets them teach you something. And it may help them arrive at a different conclusion by themselves, in a strange form of rubber duck debugging. After all, explaining something is a great way to demonstrate correct understanding of a topic.
The other option is to say nothing. Are they doing something that will destroy the world? Will it make you come in on the weekend to fix it? Or do you just find it irksome? Search yourself for the answers to these questions, and if it really is of no consequence to you or others, let it go. Put your energy into something awesome instead.
We’re all programmers, working in a field that’s so new that nobody really has all the answers. When your convictions or beliefs about something are so strong that you must comment, be a good critical friend to the recipient. They may not choose to listen. But I guarantee you have a much better chance that they will than you do with something that puts them on the defensive or makes them feel stupid. I’ve gotten this wrong in the past. Join with me to be better.
There’s no shortage of software developers who are eager to share their passion with others through writing and teaching. It’s an amazing time, and it’s great to have all these resources out there for us to all get better at what we do.
If you’re a software developer who wants to teach others how to do things, listen up, because there’s a chance you’re derailing your students and undermining their confidence before they even get started. In this article I’m going to point out some real quotes and statements I’ve seen that hurt, more than help, the student. And I’m speaking from experience, having done a really good job derailing readers and students by doing these things myself. I’m sharing what doesn’t work, and what does work, in my own experience. I believe that this advice applies not only to people who teach programming, but also to people who write books, articles, and screencasts about programming. By avoiding these things, you’ll create better learning experiences.
#1 Saying “This is really hard.”
If you start off with this one, you’ve already lost people. You’ve demotivated all but the smartest, advanced student. Students want to know they will be successful. Thy need reinforcement from you. They need to know that you’ll guide them through the things that are hard.
Tell them that many people struggle, or that the path will be difficult, but far from impossible. Show them what they’ll be able to accomplish when they’re done. If you’re teaching object-oriented programming, show a before and after example at the beginning of the lesson. Show them the spaghetti code, then show them how much cleaner it will be. Don’t worry about whether or not they’ll “get” what you’re showing. If you take the time to plan what you are showing, your simple example will make sense.
#2 Saying “This is really simple.”
On the other hand, if you tell the students something is simple, you run the risk of derailing novice students who run into errors they caused by themselves. In programming, nothing is simple. A small typo can cause all sorts of trouble for the inexperienced, and then their confidence is undermined. “But she said it would be simple! What am I doing wrong?” And then the learning stops.
You want to avoid “easy”, “simple” and similar words for this reason. You can certainly tell the student that the concept you’re introducing is basic, or introductory, or “the first step.” But keep in mind that everyone starts at a different level. Something as “simple” as declaring a variable has a lot more going on.
#3 Saying “Don’t worry about this right now, we’ll talk about it later.”
This is almost always a sign of impatience on the part of the teacher or author. You want to get to the good stuff, but you’re stuck in some kind of “chicken and egg” situation, so you show something advanced, and promise to explain it to the student later. The problem is that we don’t know when that will be. Be specific. Say “We’ll cover this in a few weeks” or “We’ll get into this topic in detail in chapter 14.”
But more importantly, ask yourself if now is the time to show this to your students. Is there a more simple way you can do something, even if it’s not the “right” way? If you don’t have time to explain the “why”, what is the benefit of introducing the concept at all?
#4 Saying “Don’t worry about this right now, you’ll get it eventually.”
This is similar to the previous one, but it’s a little more problematic because it’s putting the effort entirely on the student to figure it out. Instead, tell the student that they’ll get a lot more practice with the concept. Again, make it clear at the beginning why you’re introducing the concept and how they’ll benefit.
#5 Not Having A Plan
If you’re composing a chapter or a lesson and you don’t have the end in mind before you start, you’re going to be all over the map and your students or readers will be confused. If you’re doing a tutorial, write all the code first, then break it apart, break it down, and explain it. Don’t just write words and throw code samples in. That’s not a tutorial. That’s a reference guide and there’s a big difference. There’s a big difference.
Students need to know the plan at the beginning. They need to know where they’re going and what they’ll be able to do at the end. If you don’t have that plan, how can you convey it to them?
Use mindmapping, use outlines, use some technique that lets you easily figure out what your grand plan is. If you can, start with a “competency-based” approach:
Figure out what you want them to be able to do
Come up with how you will evaluate that they can do it (a test, a project, etc)
Come up with the exercises you’ll have them practice so they can eventually do #2
Fill in the explanations.
This is what’s called “performance based learning” and it’s really effective, but it has to be planned out. Trust me on this – it works so much better than winging it. I’ve done both, and I will always have a plan now, and it will always be based on this order.
#6 Not writing code at the students’ level
If you’re an experienced programmer, and you’ve been through lots of code reviews, you’ve probably developed a style of coding that’s clean, compact, and free of duplication. But if you’re teaching someone how to do something in your language, being terse is going to freak a lot of students out.
When I’m writing examples, I tend to break things into as many statements as I need based on the audience at hand. If I’m writing a book on “Beginning CSS”, I’m not going to write code like this:
That is, I’m going to spell out each property, and then I’ll show the condensed version if it makes sense:
age = prompt("What is your age?");
age = parseInt(age);
even though I might be tempted to do this:
var age = parseInt(prompt("What is your age?"));
When you’re teaching, you need to explain the meaning of things. I know when the long version is appropriate, and I also know when the short version is appropriate. The students don’t, and it’s my job to get them there.
Silence the voice of your peers that will tell you to refactor your code Production code is not learning code. Show the cleaned up version later and ask thought-provoking questions about the differences.
#7 – Having out of context, incomplete, irrelevant, or broken examples
Your examples need to work and they need to have context. While some students do just fine with
array = ["a", "b", "c", "d"];
Many others don’t. There are many ways that people learn.  Try to adapt a bit and use examples in context.
In addition, make sure the code works. Make sure it’s free from syntax errors, and make sure it’s reproducible given the steps you wrote. Nothing frustrates a reader more than trying o follow directions with steps missing. It’s really hard to write tutorials that people can follow. It involves a lot more work than doing it once and writing the steps down.
It’s easy to be teacher-focused and say “Well, they’ll learn from figuring it out.” They’ll learn, alright; they’ll learn that you don’t care about them learning what you’re teaching.
Treat example code like production code; use proper variable names, write it cleanly, and test it every so often. Test not only your code, but the process you’re using to teach it. If the new Android SDK comes out and the new project generators break things, you need to have that in your tutorial too.
#8. Flying Solo
If you’re writing a book, you need an editor. Maybe you don’t need a publisher, but if you’re going it alone you still need a development editor who can look at what you’re doing and help you find the holes. You also need to have your content peer-reviewed. Get feedback from experts, get feedback from readers, get feedback wherever you can get it. You will get better results.Every single person who creates learning material can improve, no matter how long they’ve been at it.
The last thing to think about is your conclusion. Don’t just throw a last bit of code out there and jump to the next topic. Recap the concept you’re covering and give the reader or st8dejt t9ke t0 reflect. Metacognition (thinking about thinking) is pretty powerful stuff, and a good closing really helps things stick.
So, all of these things, from avoiding dangerous words, to planning, feedback, and a strong closing, are the things I look for in my own writing, in my own class preparation, and in the writing and course design of others I provide feedback on.
Take some time and reflect on these things. Which of these do you do in your current writing or teaching? What ways can you do better?
Finally, take a look at this passage from an online tutorial about Objective-C:
Pointers can cause a lot of confusion with newcomers to programming or just newcomers to C. It is also not immediately clear to some people how they are useful, but youʼll gradually learn this over time. So, what is a pointer?
[… example omitted….]
Clear as mud? Donʼt sweat it. Pointers are hard – often considered the hardest thing to learn when picking up the C language. Pointers will eventually become second nature to you though, and there will be more on pointers within Objective-C further in this series.
I’m not linking to this tutorial because I don’t want to pick on it too much, but this is one in at least 10 articles and books that I’ve read that bring up this topic of pinters in the first chapter. After reading that, what problems do you see here that could derail a beginner? Are you motivated to keep going? How do you feel after reading that?
Got any other things you think I missed? I’m always interested in improving my own writing and teaching.