Not long after I wrote a pretty well received article on how to write a good teaching book, Manning decided to get in on the video training course game, and some damn fool decided I was going to be the guy commissioning content for it. We launched our first course products a month or so back — https://livevideo.manning.com/.
Here’s what I’ve learned a long the way.
Passion & Personality Matter
The most successful instructors, across pretty much any channel, free & paid alike tend to have one common strength: energetic passion for what they are doing. How this manifest depends on the instructor themselves. There’s no set mould, and what works for one instructor won’t work for all.
Ultimately though, if you sound bored, your students will be bored. Show some energy!
If I can’t apply what I’ve learned to something real, then you’ve wasted my time
As a software developer, you’ve got to have intellectual curiosity. New ideas & concepts are a daily headwind in the grind to keep up with the pace of technology. For the most part though, if you’re taking these kinds of courses you want to build something real. For instructors, this means focusing on real-world applications of a technology.
Here’s a few questions to get you thinking about it:
- Will their boss be asking them to do what they’ve just learned?
- Will they be able to apply this to their next app?
- Is the best place to learn what you’re teaching sat in front of a keyboard?
- What’s the most useful way you applied this idea in your own work recently?
One caution I will make to this point is that there’s a major danger of just showing someone how to build one thing. A good course will teach you to predict, prescribe and troubleshoot any app, not just the single app you built.
Get me *doing* something
Too many courses walk you through the material, then just leave you hanging.
I think a lot of instructors assume that people will be typing the code as they do, and that’s probably smart, but having spoken to a lot of video course learners, many will actually just sit there watching — don’t let them! Give them something to do. Be explicit about it.
Better courses will set you practice challenges & quizzes, but very often these exercises are trivial or boring. Usually, they’re too fact based. If you’re using sand boxed exercise environments, then you’re limited very often to simple problems with rail-road solutions. These are good for limited checks for understanding, but you should absolutely be setting them exercises to perform in their own environment.
Ideally this won’t just be “follow along with me”. It’ll be “try to do this first, then I’ll show you how I did it”. For instance, say I wanted to teach someone how to build a web server: rather than simply building a web server for them to recreate, I’d teach them just enough about what HTTP is, and where the tools are for building HTTP servers in the language we’re working with. I’d maybe show them a hello world example — then ask them to build on it by displaying a complete page.
Death by Powerpoint
Remember all those conference talks where the speaker just reads out their slides? Yup, that happens all too often in video too. If you need to use slides to summarise, keep the text short and concise.
Powerpoint (and Google Slides/Pages) can be very useful though. Good software books will use diagrams, and good software video courses should use lightly animated diagrams (we call them ‘active diagrams’ internally). These are fairly simple, really: rather than just showing a static diagram, you make individual components appear frame by frame. Here’s one showing how the DOM is built on page load — created using nothing more than Google Slides. It’s much more powerful than a series of bullet points, and not a huge amount of work, if you’ve got access to a good icon library.

Audio is hard.
Recording a great audio track is tricky. The nature of what you’re doing is that you’re spending as much time typing as you are talking. Depending on your mic, this can lead to a whole lot of THUNK THUNK THUNK THUNK CLICK. Ew.
You’re also limited when editing. You haven’t got nearly so much scope for cutting out or speeding up mistakes when you’re coding.
Some other hints:
- If you’re planning on recording talking head, use a lav.
- Get a pop filter.
- Take breaks — and breathe. You can always edit out the dead air.
- Try to record in a room with lots of soft furnishing: it’ll reduce echo.
- Don’t use a headset mic. It will suck.
No, the Blue Yeti is not the best microphone for this.
There’s a lot of pretty terrible advice out there on microphones. Particularly around the popularity of the Blue Yeti in instructor circles. Avoid the Blue Yeti. It produces a fantastic sound… of literally everything happening in your room. Given the popularity of mechanical keyboards, you’ve got a recipe for a cluttered, distracting audio track, if you’re recording audio and video simultaneously
Do yourself a favour. Get a dynamic microphone, something like the Audio-Technica AT2005 if you’re looking for something easy to set-up via USB:
https://www.amazon.com/Audio-Technica-AT2005USB-Cardioid-Dynamic-Microphone/dp/B007JX8O0Y
If you have already bought yourself a Blue Yeti, and are too late to return it, please at least learn to use it properly:
Closing Thoughts
I still think we’re in the early days of discovering the best patterns and practices of good quality video training. Here at Manning we’ve really only just begun to scratch the surface, and have a long way to go before we’re achieving the kind of high-yield results learners need.
If you’re interested in creating video training courses for software devs with us here at Manning, feel free to shoot me an email: grwi@manning.com
