Greg Wilson

Dr. Veronika Cheplygina recently interviewed me for her series “How I Fail”. We discuss weak failure (“I put in a lot of work and nobody got much out of it”), strong failure (“I put in a lot of work and did harm that could have been avoided”), the value of sharing failures online, and butter tarts; I hope you find it useful.

An astute reader pointed out that some links on my site were 404'ing, so I ran a check for the first time in a couple of years. The results surprised me:

I am pleased to announce the publication of Teaching Tech Together, a guide to building and delivering lessons that work, and creating a teaching community around them. This book is a much-expanded successor to How to Teach Programming (and Other Things); as its blurb says:

I wrote a description last year of different kinds of exercises people use when teaching programming. In it, I talked about the many kinds of things that could be implemented by dragging and dropping labels on diagrams, from matching problems to tracing execution and even Parsons Problems.

Well, Isaac Ezer went ahead and created a prototype. The map of Canada below is stored as an SVG with the labels in the correct places but surrounded by double curly braces like {{Ontario}}; you could create a diagram of your own using any vector drawing tool without doing any programming. Isaac's Dragnet library searches the SVG for labels of this kind and pulls them over to the site. To complete the exercise, you click on the labels and drag them onto the -- markers that the library has placed where they were.

A finished tool would need more bells and whistles, like a re-set button to move all the labels back to the menu on the right, but this is pretty awesome for 147 lines of JavaScript. If you'd like to help improve it, please fork its GitHub repository and submit some pull requests. And if you're a computing education researcher and you'd like to do some studies of whether diagram labelling and execution tracing help people learn to code, please get in touch.

This post is an update to one from 2012. I’d be grateful for feedback on the question at the end.

I’ve been thinking about a recent article by Mark Guzdial in which he talks about who he’s writing for. Guzdial is a public intellectual: his research is highly regarded by his fellow academics, but he also works hard to popularize and disseminate his ideas and those of others to a wider audience.

Over the past year, I’ve run eight workshops on how to teach for various groups and companies in the Toronto area. Their content is drawn from the Carpentries instructor training, but cut down to one day; in outline, it covers:

1. Be kind: all else is details.
2. Remember that you are not your learners…
3. …that most people would rather fail than change…
4. …and that ninety percent of magic consists of knowing one extra thing.
5. Never teach alone.
6. Never hesitate to sacrifice truth for clarity.
7. Make every mistake a lesson.
8. Remember that no lesson survives first contact with learners…
9. …that every lesson is too short from the teacher’s point of view and too long from the learner’s…
10. …and that nobody will be more excited about the lesson than you are…

This thread on Twitter sparked a lot of interest, so I hope it’s useful if I publish the whole section on meetings from the upcoming revision of How to Teach Programming (and Other Things).