If you’ve ever done any computer programming, the following should probably have a trigger warning:
“I don’t need to add comments to this code. It’s obvious what it does!”
For the non-programmers among you…
Computer code is hard to read. Not because it’s a seemingly arbitrary sequence of gibberish – that’s part of it, but you get used to that. No, the problem is that every line, every word, every symbol serves a precise, logical function.
Change a plus to an ampersand and it completely changes the program.
This makes it hard to read because you need to go character by character, thinking about what it all means. You can’t always skim the code to get the gist of it.
Even if you wrote the code a few months ago, it can be like hieroglyphics.
That’s why non-insane programmers add comments – small descriptions that explain what each bit of code does and why.
It can make your job about ten times easier.
If only course designers had the same discipline…
I once inherited a course on a topic I knew a little about, but I was no practitioner. The course was a radioactive football, being punted from person to person, with no one wanting to take responsibility for it.
It landed in my lap about a week before I had to present it.
(On that count, I was lucky. It wasn’t only a few hours! Phew!)
Except these slides were complete gibberish.
One of them had a title… I forget what, but it was something like, “Don’t do this”. On the slide was a picture of a rowboat.
And in the notes section?
“Canadian boat story.”
This was an entire module by itself, so I couldn’t use surrounding slides as context.
There were no learning outcomes, no instructor guides, nothing.
I didn’t know this story or what it was supposed to convey.
That was the worst slide, but at least half of them were meaningless. They’d have four bullet points that had something to do with something, I suppose, with a comment underneath that could have referred to a completely different slide.
Even with the tight timeframe, it was easier to rebuild the course from scratch than use this festering pile.
I wish I could say this stood out because it was so unusual. It’s not. One of the many banes of bad PowerPoint presentations is experts dumping something on a slide and relying on their memory to add stories, context and exercises.
People often hate working with me on their courses. They want to dive in and assemble the slides and exercises. I always insist on creating learning outcomes first, then developing a plan, then documenting everything as we go.
Those folks might hate it, but the folks who inherit the courses love me for it.
Be like me – get your course out of your head and into documentation.
And while you’re doing that, why not snazzy them up with some new graphics, a better background, and a complete overhaul of how fun and effective it is?
You’re on your own with the first two, but, with my 12 principles of great course design, you can quickly and easily make any course a joy to take and teach.