SIGCSE, Keynote #1, Fred Brooks. (Yes, THAT Fred Brooks.)

Frederick P. Brooks, Jr is a pretty well-know figure in Computer Science. Even if you only vaguely heard of one of his most famous books “The Mythical Man Month“, you’ll know that his impact on how we think about projects, and software engineering projects in general, is significant and he’s been having this impact for several decades. He’s spent a lot of time trying to get student Software Engineering projects into a useful and effective teaching form – but don’t turn off because you think this is only about ICT. There’s a lot for everyone in what follows.

His keynote on Thursday morning was on “The Teacher’s Job is to Design Learning Experiences; not Primarily to Impart Information” and he covered a range of topics, including some general principles and a lot of exemplars. He raised the old question: why do we still lecture? He started from a discussion of teaching before printing, following the development of the printed word and into the modern big availability, teleprocessed world of today.

His main thesis is that it’s up to the teacher to design a learning experience, not just deliver information – and as this is one my maxims, I’m not going to disagree with him here!

Professor Brooks things that we should consider:

1. Learning not teaching
2. The student not the teacher
3. Experience not just the written word
4. developing skills in preference to inserting or providing information
5. designing a learning experience, rather than just delivering a lecture

His follow-up to this, which I wish I’d thought of, is that Computer Science professionals all have to be designers, at least to a degree, so linking this with an educational design pathway is a good fit. CS people should be good at designing good CS education materials!

He argues that CS Educational content falls into four basic categories: the background information (like number systems), theory (like complexity mathematics), description of practice (How people HAVE done it) and skills for practice (how YOU WILL do it). In CS we develop a number of these skills through critiqued practice – do it, it gets critiqued and then we do it again.

He then spent some time discussing exemplars, including innovative assignments, the flipped classroom, projects and a large number of examples, which I hope to commit to another post.

Looking at this critically, it’s hard to disagree with any of the points presented except that we stayed at a fairly abstract level and, as the man himself said, he’s a radical over-simplifier. But there was a lot of very useful information that would encourage good behaviour in CS education – it’s more than just picking up a book and it’s also more than just handing out a programming assignment. Often, when people disagree with ‘ivory tower’ approaches, they don’t design the alternative any better. A poorly-designed industry-focused, project-heavy course is just as bad as a boring death0by-lecture theoretical course.

Bad design is bad design. “No design” is almost guaranteed to be bad design.

I’ll post a follow-up going in to more detail over what he said about projects some time soon because I think it’s pretty interesting.

It was a great pleasure to hear such an influential figure and, as always, it wasn’t surprising to see why he’s had so much impact – he can express himself well and, overall, it’s a good message.