Greg Wilson

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).

I want a cartoon like this, but instead of being labelled “socialist” and “anarchist”, the people pointing at the stars are labelled “MOOCs” and “peer instruction”, and the building is labelled “school”, because we’re not going to get any meaningful change in education unless we tackle the political aspects head-on.

When I was seven or eight, my teacher told my class that cigarettes cause cancer. My dad was a chainsmoker–a pack a day, sometimes more–so that evening, just before dinner, I told him what I’d learned. He thought for a moment, then nodded and said, “Well, then I just won’t smoke the bad ones.”

It’s been a couple of years since I supervised a Google Summer of Code project, but I still enjoy browsing the projects and seeing what people are up to. While the 2018 projects page has a lot of information, it’s not in an easy-to-analyze format, so Elizabeth Wickes kindly scraped it and turned it into a single unified JSON file, which I have now turned into a summary CSV. I hope they’re useful: if you find any interesting patterns, please let me know.

Version 3 of How to Teach Programming (and Other Things) is now kinda sorta maybe ready for feedback: if you have time to go through 270 pages and tell me what’s missing, redundant, confusing, or just plain wrong, I’d be very grateful. I’m hoping to get the book out in June, so anything you can give me before then would be a big help.

Mark Guzdial was kind enough to take a few tweets last week to try to explain the idea of a “notional machine” to me. If I understand correctly, it’s a competent practitioner’s mental representation of how programs in a particular language are executed, which sounds like a mental model–except Mark tells me it’s not. That leaves me wondering if the term is like “computational thinking”, i.e., everyone agrees it’s important but no-one agrees what it means.

I’d like to teach scientists how to program, but that would be a lot easier to do if we had better software tools to offer them.

Back in 2007, I tried to condense everything I had learned from supervising undergraduate thesis projects at the University of Toronto and elsewhere into a short, sharp handbook for students (and their instructors). I called it The Undergraduate Software Project Guide, but didn’t manage to finish it before leaving academia to re-start Software Carpentry.

Short version: I’d really like someone who understands sociology and political science to analyze academic publishing and promotion in terms of selectorate theory.