The Cambridge Handbook of Computing Education Research

Matthew: Okay. Hello and welcome to another episode of the DevRel Book Club. I'm Matthew Revell, and I'm joined as always by...

Carmen: Hello, I'm Carmen. We, overall it's good to see you all. Hope everybody's having a wonderful day and yeah, so good to do another episode.

Matthew: Yeah. How are you, Carmen? Are you good?

Carmen: All fine here. Thank you. I'm having a very solid start to the year, settling into the new things I'm doing, trying out some new things. I'm excited. I'm excited. How about you, Matthew?

Matthew: Yeah, well, very similar. I am on the verge, and maybe by the time this goes out of it will have happened, but of announcing a whole new series of DevRel content that we're doing at developerrelations.com. And thank you very much to Common Room for sponsoring this episode. You can go to common room.io if you want to learn more about their platform for helping you to understand and measure your community. So lots of really exciting things about to happen and talking of exciting things. We have a first for the DevRel Book Club, which is a returning guest.

Carmen: Yes, it is my esteemed joy to welcome back our guest from our very first episode, Joe Nash. Hey Joe, how are you?

Joe: Hello. Thank you so much for having me back. I'm doing great, thanks. How are you two?

Matthew: Yeah, good stuff. Yeah, so that first one that we did, which you mentioned earlier was January last year. We've been doing this a year, Carmen, which is remarkable news to me. I didn't realise it had been going that long. Congratulations. Congratulations. It's amazing. Congratulations.

Carmen: Congratulations. Thank

Matthew: You. But when we first did that one, I don't think I have the book here, it's probably on the shelf somewhere else, but we covered quite an academic text, which was MIT Press's. Is it called Building or Designing?

Joe: Building Successful Online Communities, A Research Backed Approach. Is that the subtitle? Something like

Matthew: That? Evidence-Based Social Design. There we go. Look at that. I'm on. He's Ready to go. But that was an academic text which had lots of relevance to what we do in developer relations and we're going for a similar approach this time. Joe, you have brought us the Cambridge Handbook of Computer Education Research, which

Joe: A chunky boy.

Matthew: Yeah,

Joe: All 901 pages of it.

Matthew: So Joe, we've got to ask why this book in particular,

Joe: Why do I keep doing this to you? My new January, January rhythm is bringing Oppressively academic texts to your poor book club. Why this book in particular? So I think we spoke about it on the first episode with the Building Succesful Online Communities books, which is one of the things I found really useful about that book was there is a bunch of stuff that we are taught or we learn as DevRel practitioners that to some extent we take for granted. We're told them by people senior to us or by DevRel contours, et cetera, that this works and this is the way we do things. And some of that is backed up by things people have seen in their roles.

But that community book, what was really interesting about it for me was it had studies and citations galore from the scientific literature that it clearly explained the things we were seeing as professionals, and that was really exciting to me.

I really loved having that evidence, that data and this book is very much ticks those same boxes, but a whole heap of other areas of artwork. So it covers teaching computing concepts in general, but from all different angles. So there's a whole chapter dedicated to the challenges of teaching novice programmers, how to code and the reasons from all kinds of different angles, not just in terms of teaching techniques, but also what's happening in the brain and what's happening socially in the classroom and all these different factors that lead to students struggling on their coding journey. And it's a really broad book and we'll talk about its nature as a handbook and who it's for, I'm sure.

But it's a very broad text that touches on lots of different areas and points you to the scientific literature in a way that you can start to explore that world and bring it into your professional DevRel life.

Carmen: Thank you. Yeah, no, I was super excited when we got to read this book because very similarly to the MIT book that we explored in episode one. For me reading the parts of this book that I read, because I will admit and we'll talk about this in a moment that I didn't read all of it. What I found so fascinating is this concept that I've been discovering with reading literature in relation to communities and computer science education or teaching computing in general is that it puts a lot of, and I have to be very careful that I get this right, words to thoughts, it gives a lot. So it explains these things that I've been sort of taking for granted for context, I started out early in my career by teaching children to code, which was for me a very, very meaningful experience.

Actually. it's been long enough now that some of them are working in a game development, which is just incredible. But also that got me curious when it came time to write my bachelor thesis, to think about, okay, how does this apply to the science of learning and teaching? And it was really cool to see concepts from that research. I did come up here, concepts like constructivism, constructionism and the cognitive sciences. But of course, as I said, I didn't read all of it and when those of us who are not, even though I mentioned that I did some research, I wouldn't consider myself an academic. I'm wondering how do you recommend approaching this book for someone who's curious but overwhelmed perhaps?

Joe: So I think I have two different strains of advice. One about academic texts in general and then one in particular to this book. And actually even a series of books, the Cambridge handbooks. So academic texts in general. I think a lot of folks, especially if you're reading business books like business nonfiction are used to books that are kind of meant to be read front to back by a single author. They are laying out a set of ideas and kind of a linear narrative, and they are not to be inflammatory but quite information. They're not very dense information.

You can often listen to them at three times speed and Cliff Notes are really useful for that kind of book. With academic texts, it's a very different approach. And I think one of the things people struggle with when they first start reading academic texts, and one of the reasons why people struggle with them is this feeling that, oh, I'm reading this front to back is really unpleasant. I must be bad at reading. And no, they're not meant to be read like that.

I've recently started doing graduate study again, and one of the things we're being taught is in terms of reading, academic texts is a different mode of reading. You first of all do a surface skim to check for the relevance and check for like, Hey, what is this paper trying to convey? What's the key ideas? And then you skip the bulk of the paper and go to the conclusion and see what they actually found. And then if that information is useful to you, if that information is relevant to you, you can then start to go deeper and start to look at the method and these kinds of things. And this book is very similar.

So that is the approach. You should take this book similar to an academic paper because the way this book is organised, it's not one text by one author laying out a linear series of ideas. It's a bunch of chapters contributed by different groups of researchers in the style of academic articles. So each chapter, you can kind of think of it as an individual paper. And so they all stand on their own. Some of them refer to each other, but they all stand on their own because it is a handbook, it is a manual.

It's not meant to be read front to back. It's meant to be kind of like a troubleshooting guide like, Hey, I am interested in computing education research and I'm thinking about it and I've encountered this problem, or I've encountered this concept and I'm unfamiliar with, let me crack open my handbook and go to the relevant chapter and dig in and try and find information on that. So very much another book you read front toc, as you said, Carmen, you haven't read all of it. I have had this book for a while and have found uses for a lot of it, but there are parts of it that I have not read either because I haven't needed them in my work or research yet. And yeah, definitely pick and mix from this book for sure.

Matthew: So one word that comes up a lot is pedagogy. And I wonder if you could help us non-education experts to really understand what pedagogy means in the context of what we do as DevRel people, developer educators.

Joe: Yeah, yeah, for sure. So I'll say this is exactly the sort of stuff that I bought this book for. So as a DevRel practitioner and a lot of my involves educating developers on how to use given technologies. And so I kind of had the feeling that I was doing all of these things and I was kind of making up as I go along and doing workshops and tutorials and I was like, wait a minute, but teaching exists and has a degree in teaching, so surely there is science for this and trying to find that information and particularly pedagogy.

I'm so glad you started this because hearing that word a lot was the one that made me go, where do I learn these words? And this is why I picked up this book. This is the thing that brought me to this book. So pedagogy in particular is like the ped in pedagogy is referring to teaching children. It is the practise of teaching children and it is the methods of instruction that you use. So the actual way you teach children. And that straightaway is more or less relevant to our work. And all of us are teaching children, even when you're teaching adults, which is andragogy, you tend to still talk about your pedagogy. And your pedagogy is the manner in which you teach the tactics that you used to teach. There are lots of different foundational theories around how we learn that influence.

So Carmen, you mentioned constructivism and also constructionism. Two different things that are different foundational theories about how people learn, how knowledge is built in the brain that influence your pedagogy. So for example, a resource that I really love a lot is Raspberry PI's pedagogy, quick Cheat Sheets, quick Reads, quick Reads, I think they're called. And these are literally one pages for that explain popular research backed teaching techniques. And one of the really popular ones that they cover, which comes up in this book as well, is called a Parsons Problems, which is where you have a complete block of code and you scramble it. So you put the lines out of order, and then the task for the learner is to order the lines of code so that the code works.

And this approach, this pedagogy is based in one of the lines of thinking around one of the foundational learning theories, which is cognitive load theory, which is that the amount that you're trying to, you have short-term memory, long-term memory, your brain can only process so much information at once. And when you're learning to programme, you've got syntax, you've got semantics, you've got lots of different things.

So Parsons problems remove the syntax. We're not learning to type correct code, we're just learning about the structure of code. And so that's a pedagogy based in one of these foundations. And so these are the kind of things like when you are coming to your workshop and you're thinking, I'm going to have a demo here, I'm going to have an exercise here in this exercise, they'll be doing X, Y, Z for this. What you're doing is choosing, you're designing your pedagogy.

And so that's kind of fundamentally what we as educators are doing. And this book kind of lifts the covers on a lot of the decisions we make and puts as everyone like words explains a lot of that and will help explain your preferences and help you explore your preferences and your beliefs around what is effective teaching.

Carmen: Thank you. Yeah, it's something that I experienced as well and I wanted to dive in a little bit if I may, in chapter eight. One part that very much stood out to me was the sort of relationship differentiation adjacent nature of the learning sciences and computer education computing education in particular.

The book talked about something that really resonated with me was, for example, I'm going to quote the book if I may, on page 208, for example, a computer scientist might build educational software based on a sequence of concepts that need to be learned. If the computer scientist was also a learning scientist, they would design the learning experience about how these concepts connect to the existing cognitive architecture that the learner has and the identity motivations and experiences of the learner.

And what this really said to me was if I were to think to the most fundamental computing education step or one of the beginning ones is the hello world programme. Can you tell us about your, I'd love to hear what your experiences are between these two.

Joe: Yeah, yeah. So I guess a key thing to touch on here is bridging the gap between computer scientists and learning researchers is very much the aim of the book. So the book is aimed at two groups of people kind of distinct, which is computer scientists who are interested in the learning scientists and learning scientists who are interesting in computer education. And so chapter eight, the Learning Sciences for Computing education chapter is the chapter literally made me want to buy this book is the chapter that says like, Hey, you are a computer science person. Here is what you need to know about how learning works.

And so I think that's, that's the context exactly that this is the exact context which I came to it. The example you gave is the exact context which I came to this where it's like I have been doing lots of workshops and talks my whole career and I've observed things that work and observed things that didn't. And I wanted to know why that was the case.

I wanted to know, hey, we start with Hello world and that's a minimal example. Is that the only reason we start with Hello world? Is there more to it? And actually funnily enough, another place that I think this is not in this book but is in a paper by researcher called Felienne Hermans.. I was reading today for reasons, but there is so much we can learn about our jobs from the adjacent fields of psychology and cognitive science that are covered in this book.

And a really key insight from this paper today that's almost mentioned offhand is talking about the link between learning programming and learning natural language. So learning spoken languages, English, German, whatever, and talking about how children acquire language and in particular how children acquire punctuation. And the finding that one of the last things that children acquire in natural language is the parenthesis and the colon, which are fundamental pieces of syntax in most programming languages. And you know what? Language doesn't rely on preis and colons very often, Python, do you know what language is most popular in teaching kids Python? And that's like, there you go.

That's why a concept that's really difficult to them. They just haven't acquired it in natural language yet. I always thought Python's an easier language. Why is Python easier? Well, it's simple, whatever, but I wouldn't have made that connection. So it's that kind of stuff that's really interesting to me, that kind of stuff that this chapter in the example you gave, those kinds of connections that it makes and the ones with cognitive science as well, I also think are super important.

This book has a whole chapter on it, it's chapter nine. There's also another great book again by Flee Herman's, which we've spoken about for this podcast before or I'd spoken about doing first podcast that I think we've done it yet, which is called the programme as Brain. But another thing, the whole section of stuff that's really interesting here is just you have different forms of memory. It's also on my shelf somewhere.

You have short-term and long-term and working, and there's different types of long-term memory. And the way things are encoded in your brain is very different. The ways you can recall things is very different and you are using all those types of memory when you programme, also when you learn. And we don't often when you read that you'll instantly recognise patterns in where people have struggled with concepts in your workshops where your documentation over overloads people. Yeah, I dunno if I answered the question entirely. I got very excited by it, so it kind of ran off into the woods. But yeah,

Carmen: I mean that's what we're here for and I think that's what this book does really well. It's sort of giving us those, as I keep saying words for those thoughts where we connect these things. One particular one that stood out to me was the concept of the chapter eight spends a section on productive failure, which for me is something that I've been experiencing so much, especially in the last couple of years in my work of giving folks the opportunity to use failure as a teaching tool.

We say that very informally, learn from your mistakes. Making mistakes is the most common thing we can do and it's good for us. But having that backing to it, the fact that this is built into design. I remember when we were making games with the kids, I would allow them to put as many enemies on screen as they like tell 'em, I don't know, 10, 15 enemies on screen. And they would just mash that number nine until their computer's frozen. That's when they had an understanding of, for example, how much computing power goes into the game working. They get

Joe: The mental model of what's happening in the machine, right? In a way that you couldn't intentionally teach. And I think this chapter in particular, and I think I said this to you before in the slack, this chapter in particular is kind of like if listeners think reading this, if you take a moment now to jot down on the piece of paper just your top thoughts about what is good to do in this tutorial or what is good to do in a demo or what is good to do in a documentation portal or a workshop, and then you read this chapter, you will tick those. You'll be like, oh, that's why. That's good. That's why that's good.

So we do worked examples. We provide example code and let people play with it. We have sandboxes in our documentation portals. So constructivism, constructivism is letting people build their knowledge via taking what they already know and playing with it and expanding it and applying what they know to new problem domains and basically not direct teaching, not being told what to do, but exploring. That's what we do when we let people do. We have API Explorers and we have the idea of making their first request and letting them get on with it and that kind of stuff.

Cognitive apprenticeship is another one in here that's really interesting, which is the idea that throughout history training, lots of the way we've kind of trained people in lots of trades is by apprenticeship master teacher, sorry, master to student small class sizes, like a single apprentice, single master kind of thing, real sift setup. And that doesn't scale to classrooms, but there are parts of that that we can take and do scale. So one of the things masters do is they model their expertise.

And again, we do that, we go on stage and we do live coding demos, we model how to solve a problem, we're doing construc, cognitive apprenticeship, and then productive fail is another one we're especially in, I feel like the last couple of years of live stream content, one of the most compelling formats I think for live coders is just messing up on screen and then working your way out of it. And when we talk about demos and live coding things, one of the earliest principles I was taught around doing live coding demos is like, Hey, make a mistake and show your debugging process and show how to get out of it or encounter an error and come out of it. And literally every single thing that I know about communicating technical information is one of these theories, which is so exciting

Matthew: And it's good and exciting to know why the things that you already do work and make sense. But have you been able to then build on some of these things because you understand what's underneath it in order to create new techniques or approaches in your work?

Joe: Yeah, yeah, absolutely. So I think one of the areas of understanding these different theories is also understanding where these theories are not opposed, but these theories are all accepted, they all exist, different researchers have different opinions on them, there's different favourites. For example, me and Carmen were talking before the show, chapter eight is talking about constructivism and the author of chapter eight is a fan of constructivism.

And the author of Chapter 10 at one point calls it non-Scientific. And there's a remark in chapter eight where they're like the author of chapter 10, don't think this is scientific, but we disagree, which I just love as a textual thing. But what they do do a really good job of quite frequently is putting these techniques on a spectrum of understanding, but also kind of use cases and where they fit. So constructivism, behaviourism, for example, one of the things that this book gets into is constructivism, having people explore stuff like yes, that's really powerful, but people will often not learn what you intended them to learn. If they're exploring by themselves, they might learn something, but you don't necessarily know what they're learning.

Again, Carmen, your example there of adding loads of characters to the screen, they learn that their programme breaks, but do they connect the dots and know exactly why that is? They probably need some guidance, they need some direct instruction to know why that is. And then you get to behaviourism. And so knowing the limitations of each technique and why there are those limitations is one of the things that knowing the underlying theories is really helpful for. So another example is learning objectives, learning objectives, learning outcomes, starting your content with, by the end of this workshop you are no x, y, Z.

That's very behaviourist and behaviourism does a lot of direct instruction. So literally telling someone this function does this, rather than saying, Hey, run this function, what do you think happens? And there's a lot of interplay, especially in coding and a lot of research in coding that says that coders more effective if they see, for example, if you are learning how to build a web application, if you put someone in front of a blank for you, say build a web application, do a constructivism, they will really struggle to do it. But if they see someone build it first and then they're told to do it, they're much better. And that's intuitive. That makes sense. We understand that's people who have engaged with learning, we understand that's the way to do it. But the theories really let you explore that space and know exactly when to make a leap off to something else, why you might be seeing the results you are in the classroom.

I can bang out a curriculum for a workshop and then run that and see certain things happening and be able to reason about like, oh, that's why this is happening. I should apply this technique here instead. Right? So I dunno, I wouldn't say I'm doing anything novel. I wouldn't say this leap off for me to find new learning stuff, but it's definitely again allowed me to approach content development in a more rigorous way and know exactly why be able to anticipate the outcome a lot better. And when it doesn't work how I want, I'm able to reason a lot more effectively about why it hasn't worked out how I want. I feel like for a lot of my career, especially for online courses, I've kind of just relied on, hey, this percentage of students finished the course and that's kind of industry norm.

The one I always quote all the time is the peak industry norm is every one of us knows that 30% open rate on an email campaign is really good. I don't know why anyone knows that, but we all know that. And so that's kind of the same with online courses where it's like, yeah, 15% finishing your online course, that's really good. And this background has allowed me to plug into that and go like, Hey, this is the rate I'm getting. Oh, now I know why. That's good. Now I can see why these folks have dropped off, et cetera.

Matthew: You took us through how understanding these theories can help you to identify or understand why certain things have happened in your developer education practise, but how can we take the learnings from this book and the theories here and actually put them into intentionally design DevRel programmes and developer education programmes using them? But also I've got a note here that says, isn't it time for us to get serious about developer education as a discipline in its own right?

Joe: Yeah, yeah, for sure. Yeah. So I guess we'll start with that last bit. I definitely think it is not my first time this podcast, but also I imagine most children, it's not the first time listening to me talk about DevRel. There's a lot of areas of DevRel where I think we not wing it, but where we have reinvented things from first principles and that's the only knowledge where we're willing to explore. And developer education is definitely one of them.

I think the way we do workshops, the way we do tutorials, the way we learn to do workshops, the way we learn to do tutorials is all knowledge from within the devra field. And sometimes we're very fortunate and people come into the Devra field from an education background and kind of bring new stuff with them and help widen our horizons. But I do think, and I gave a dere talk about this in 2019 actually, that we really should stop just doing that wheel reinventing and just accept that we're educators and there is best practise for educators. And actually we should be engaging with that before we start.

My DevRelCon 2019 talk for example, was a researcher ADA Kim who had looked at all of the online coding tutorial platforms like Treehouse and Code Academy and Microsoft Learn and had basically rated them on their pedagogic approach and the validity of that and found a lot of them very wanting. And that doesn't need to be that way because there's a lot of body of science about this computer science education itself is, especially for younger folks, is still in early stages. It's iterating rapidly.

There's a lot of, lots of countries have bought in new curriculums and it's been more or less successful for various reasons. And so it's not a perfected science by any means, but there's still a lot of stuff there that we should definitely be drawing on. So in terms of drawing on that, I think the easiest way to do it is without understanding any of the foundations, without getting really deep into learning sciences, have a look at some of the pedagogy approach, I dunno that's the correct word, pedagogy that teachers are using in classrooms, bearing in mind again that these are the kids and so they will need adapting for your work, but just think about why are the techniques they're using and do they apply to me?

So again, a really great resource for this is Raspberry PI's pedagogy, quick reads, and one in particular that I think is just universally applicable to everyone teaching coding concepts is the semantic wave, which is one of the pedagogies of you're introducing a new word, a new term, a new concept. What is the process that people go through the semantic wave between understanding the meaning and the semantics of that word and incorporating it into their knowledge.

And that is like we all introduce new concepts for technology, whether we're doing a new, whether we're advocating for library in a programme, language is probably a concept, or your company's got a completely novel API or something like that. There will be new concepts. And so the semantic wave is universally applicable and is a technique that you can use to structure your content immediately. You just pick up that sheet and you go, and there's loads of things like that they're not, some of them are addressed in this.

So Parson's problems as addressed in this book and you could probably implement Parson's problems from the recommendations in this book, but just as a blunt instrument to get started, the rasp PI pedagogy quick reads, you'll find something useful in there for sure.

Carmen: Thank you. Yeah, that's really good to know as well. And I think what you touched upon there especially and also in your talk from 2019, which I'm going to have to go watch because that sounds like something I'd like to very much get a lot of use out of. So thank you for that. Something that this book touches upon that I've been thinking a lot about recently as well is this concept of teaching concepts, especially to novice programmers, to emerging developers, people who are getting started.

And one thing the book mentions in chapter 12 that really stood out to me as this sort of lack of a agreed upon list of topics that need to go into an introduction to computer science, which I mean that's a annoying chuckle. I think a lot of us have been there of thinking how do we do this? I'm curious, how does reading this section on making content accessible to novice programmers and what I mean accessible, I don't just mean in the approachable sense, but also well accessible really in every sense of the word. How has this affected the way you approach teaching concepts? Yeah,

Joe: This chapter in particular has been very useful for me. So this is something that's probably quite unique about my role and career versus some other dev folks, but I tend to focus on early in career developers in my role.

So my roles historically have been folks who are new graduates or bootcamp students or whatever and helping them become the kind of developer who would use a company's technology. So I run into this programme all the time and in particular with, so my day job at the moment is working on a game called Twilio Quest, which is Twilio's free coding game.

And that game was started out as a fun way to learn Twilio. And along the way, it being a game, it has attracted lots of newer programmers, lots of younger programmers, and we've just discovered the incredible golf between what even a couple of years into the industry to be able to interact with an API like Twilio and what someone fresh to programming knows about a computer. And the difference between them, some really common, I guess things that I encounter daily is we spoke a little bit about students learning that a computer can crash, but just understanding, having a mental model of what a computer is and how it works is not intuitive people.

And that might be taught might not, my computer science degree, we started programming in arm assembly, like assembly language, and that doesn't, lots of people will look at a computer science degree and say, well, that doesn't set you up with the skills needed for a job. You need to be learning JavaScript and like, yeah, sure, I can't go get a job writing assembly. I could go get a job writing assembly, but I'm probably not going to go get a job writing assembly. But what that did teach me is how memory worked, how a computer works, and it gave me an incredible mental model of how the computer actually functions that allowed. We were talking about how exciting transfer is.

One of the foundational learning concepts is out of transfer, being able to apply what you know to other structures, other domains, I was able to transfer that knowledge to when I encountered more dynamic languages. When you get into JavaScript and Ruby, you learn about the difference between the stack and the heap and where data is stored and how variables are accessed. And shallow copying versus de copying. That will just intuitively make sense if you know how the computer works.

But if you don't know how the computer works and you are defining an object in JavaScript and you're assigning it to a variable and then you are editing the original object, what the hell happens there and why does it happen? You have no idea, right? Absolutely no idea. And you can't be taught that without being taught how the computer works. And so these are the kind of things that when people say things like, oh, computer science doesn't teach what industry needs A, I get very wound up because they dunno what they're talking about. But B, this is the kind of just already in that incredibly simple example on this podcast in 10 minutes, the gulf of complexity in teaching people how to programme because we're not just teaching 'em how to programme, we're teaching 'em how to problem solve, teach 'em how to read them, we're teaching 'em how to read.

We're teaching 'em a new language. There's lots of similarities in natural languages. You're teaching 'em how to respond to a feedback system. No one knows how to interact with error messages when they first encounter, not all how to understand them. There's so much there. And again, a lot of that I'd observed just from my work and had started to put into my content. But then this novice programme is chapter, chapter 12 breaks down the cognitive processes that happening in the programme is head. It talks about it correlates different failure rates seen in schools with why that might be happening and the different structures of courses and they analyse courses in aggregate.

There's a paper, I don't think it's cited in this one, but it's another paper that looked at, so in America they have very uniform course names for computer science. So CS one is always the first module. And this paper found that there's basically no consistency between what's in a CS one. So all these courses called the same, but you have no idea what someone has learned from CS one. And this book points out that of CS one students less than 38, I think it was 38% was the figure something.

Around that can't write a basic for loop that works out on average of an array, but they're learning something. It's so fascinating. And I think it's just that complexity that we talk a lot in Dev row and in content about the curse of knowledge about once you've learned something, it's difficult to teach someone it because you no longer have that viewpoint. That empathy of knowing what it's like to not understand that and this chapter alone points out the so many ways that is true and why it's true.

Carmen: Yeah, I think one concept that in my experience of learning free content, I still don't have my bachelor's degree in computer science in software engineering rather. And one that I keep seeing be hopped over is that of logic of understanding a computer operates. Have you ever seen that video of that teacher teaching their students how a computer makes a sandwich? No.

Joe: Oh, wait, yes. Hang on. I have with his kids, he asked them to write out the steps to make a peanut butter sandwich and then he follows it literally like a computer would, right? And he ends up doing crazy things like just putting butter on the counter and that kind of stuff. That one.

Carmen: Yes, exactly. And I think there was a game that came out of a push for better computer science education in the United States called Lightbot, which I really liked, which was a game where you programme the robot with drag and drop instructions.

Carmen: I feel like taking those approaches to the things we do, and it's something the book covers as well, is what are the different kinds of educational platforms, I suppose, or what are the kinds of things we do? And one that they mention and that is also very relevant is that of, for example, social media, which is something we're seeing quite an explosion, especially in the last three years of short video format, educational content.

And I think taking a step back to process those and give that pedagogical context to what we're teaching and how we learn and addressing something, addressing something that addressing these new concepts in a way that makes sense is something we still need to continue doing.

Joe: Yeah, and this is one of my favourite thing, I guess I just love to be the guy that asks why all the time and content formats is one of the things that drives me out the wall in this regard, right? Cool. Short videos are trendy now tiktoks a thing, we know people's attention span is low.

Let's do all of our educational content in short form video. It's kind of why, what is the pedagogy approach there? How are you teaching them? How does that video convey their knowledge? What is the difference? Do they engage with it better than the long form content? And I don't think we often, especially in DevRel, conflate the tactical with the strategic, right? We will say, how do I do this thing? And instead of addressing asking about the higher strategic aim, we get very caught in the precise details and we don't actually really know why we're using that tactic in the first place. We haven't addressed the strategy. And I think that happens a lot in developer content.

The docs framework, the DevRel Docs framework that most people follow is very, very good. And I think it's broadly accurate, and I think this book validates it in a lot of ways. But if you're going to go write some new documentation, there's kind of rote formats that we follow and we fit our stuff into it. And there might be minor adjustments if we've got a particularly weird product or a particularly weird audience. But generally speaking, we don't sit down and think from first principles about who is the learner and what may be the best educational approach for them. And how is that reflected in the written text say, I can't remember exactly why I went on that ramble. I think you just mentioned short videos, but yeah, that was a thought I had.

Joe: Actually you mentioned accessibility. Sorry, Matthew, you mentioned accessibility and that was one thing I did just want to mention. This was a completely novel idea for me in this book. Obviously we talk a lot in the industry at large about the importance of inclusion and diversity and about making sure that everyone is able to access our materials and access our programmes and access our communities.

There is a learning theory that explains why this is important, which was, I can't remember which one it's called. It might, it is again, it's in chapter eight. I can't remember what the name of the learning theory is, but oh, sociocultural or something. But basically, and this also explains developer communities as a whole, which again, totally my jam, I love that which where it's coming from is the idea that for professions and a lot of bodies of subjects that you learn where you are entering a community by learning it, you're becoming a professional in that space. You enter into a community of practise, which is a term we've discussed before, you enter into community of practise, people who do it. But that there's a very close link there.

And I think actually the author makes a complete equivalence between the accumulation of knowledge and the accumulation of identity and how important your assimilation of the identity is for you learning that stuff and you assuming that knowledge. And that is the chapter goes on to explain about this is why it's really important to make sure that our programmes are inclusive and that everyone come into them. Because if people aren't able to assume the identity, there is literally negative learning outcomes because of this learning theory.

And so that was a really, again, just in terms of explaining a thing that we do all the time. Obviously we have intuitive reasons why this is good, we have moral reasons why this is a good thing to do, but seeing it approached from the learning science perspective was again, very new to me and was very interesting.

Carmen: Thanks for bringing that up. I actually had a moment to look it up. So it's on page 216, social cultural theory, super fascinating. And as you said, it's putting those thoughts to words. See, I'm going to mix that myself up constantly. That explains why it is that these things that feel intuitive, now we have that scientific backed research for it. You also mentioned communities of practise, which is something I'm very passionate about as well. And how, again, the book covers this of these different types of pedagogic practises that we bring in. Things like collaborative learning, cooperative learning, blended learning, MOOCs, MOOCs are mentioned. What are MOOCs again? Sorry, I keep forgetting the

Joe: Acronym. Massively online something courses like the free online universities that are like MOOC things, Coursera, edX,

Carmen: And that these are covered there and explained why we do them and how we do them is so invigorating.

Joe: Yeah, and there's also some, we've been talking very theoretically and we've started some practical stuff. The backend of the book has some really fascinating, I guess, practical material in particular. There's a whole section about what data to gather from ides to know to check the progress of learners, which should just straight away be integrated into every online sandbox and docs portal, right? There's lots of very, because again, this is a book for researchers.

These aren't just free thinkers. They're running experiments, they're doing studies, they need data, they need to test these hypotheses. And so a lot, this book deals does a lot of that. So if you are the sort of person who's like, oh, I'm going to AB test this piece of content, read the chapter on study design, read the chapter from what Data to Gather, it's there as well. Also two great chapters on how to do statistics for results properly, which definitely is valuable.

Matthew: So Joe, I think that it would be great if everyone involved in some form of developer education read at least part of this book. But let's be realistic, we are busy. It's an intimidating looking book.

Joe: It's expensive,

Matthew: It's expensive. Other than the programmer's brain from Fe Herman's, which you've already mentioned and the Raspberry Pi Quick Guides. There's also out of Raspberry Pi, there's Jane Waite's research and there's papers. We love Education Edition, which you're involved in. What are some of the resources I'm trying to ask that you would recommend people look at if they think this book looks a bit too much to start with?

Joe: Yeah, so I guess first thing I would say is just on this book and in terms of accessibility of this book, if you have a academic login of any form for any reason, whether because you're an ex student or because there's a student in your life, you can download Chaps this book for free from the Cambridge website. So it's possible to get hold of this book without having to buy a huge thing. So Raspberry Pi is two entities.

It is the company that builds and sells the computers, and it's the Raspberry Power Foundation whose mission is broadly to further the aims of computing education. The Raspberry Pi Foundation does loads of really good material, as said, the pedagogy Quick Reads, they also put out larger books that are free. So they put out the big book of computing pedagogy. So I mentioned those different techniques that teachers use that you can just pick up and apply. That is a book explaining all of them. Y

ou mentioned Jane Waite, Jane Waite, what is a research of Raspberry Pi Foundation? Jane Wait did a summary report for educators where her and a co-author looked at 150 computing science education papers and distilled the findings into one report that teachers can pick up and immediately go and say, I'm going to do this, this, and this, and you can do the same. And that's for free. Again, online SRAs Power Foundation, those stuff. They also do computing education research seminars every Tuesday that are free to attend. You can sign up for those. Felina Herman's book is really great for the cognitive chapter. If you are interested in what we're talking about, the long-term, short-term memory Felliene Herman's book is basically just a, you can just buy that.

And again, the great thing about buying a book by a researcher is it's probably the book that is for sale is probably not the first time they've explored those ideas. Go look up any of these researchers. Go look up the chapter list for this book online. If any of this is interesting, look up the author, find their Google Scholar, and chances are they wrote that chapter, they wrote a paper that's almost the exact same content.

So you can find these papers that cover these ideas. And that is, I guess the main thing I would leave it on is like this is an academic book that's giving a broad overview of a research field. All these works are published, they're freely accessible in a lot of places. A lot of them are open published. There's a collection of computer science education conferences, which are ITiCSE (ACM SIGCSE) and I can't remember, but if you go to the papers, we love education.

Read me, there is a list of the conferences we draw from Papers We Love Education Edition is a reading group for computer science education papers come and join us, but we also link to a bunch of interesting papers in there and the journals we get 'em from. So that's a really good place to start just digging in. And the way academic Journals work is they'll hold a conference every year, much like we do. We hold conferences and people submit their papers to the conferences and then they go and present them in person. But that means that if you just want to know what's happening in computer science education, just go look up the proceedings for the current year's conference and there'll be a big listing of all the papers and you can just dab on, poke through and see what researchers are talking about this year.

Matthew: And it's worth saying as well that both Felina and Jane had talks at devcon deep dives last year, if you want to find those on developer relations.com. Well, Joe Carmen, I found this fascinating and it's something I really wanted to dive more into. And I have to say that precisely this kind of crossover of learning from another area, bringing it into developer is exactly what interested me in this book club in the first place. So thank you, Joe for bringing this book to us. Ram, any last thoughts?

Carmen: No, this has been absolutely fascinating. I said this is a topic that I keep coming back to. Thanks in part, thanks to Joe. Thank you so much. Bringing me back and getting that excitement out of me. So I'm super thankful, and it's like you said, it's having these crisscrossing areas come back into DevRel and talking about them that make this podcast so valuable to me and I hope for others as well. So thank you both. Joe, if people want to keep in touch or follow along what you're doing, what's the best way for them to do so?

Joe: Yeah, good question. I am Joe Nash at Hacker Derm on Master Dom. I do a couple of media things on the interwebs about computer science education in particular that I would recommend the last Thursday of every month I run papers. We love education, which as I said is a reading club for academic computer science papers. We often have the authors come to talk about their papers. So I'd recommend coming along to that.

You can find more about that on GitHub at the papers. We love organisation slash edu. And I said I work on an educational game called Twilio Quest, but I think the most relevant thing for that is the second Tuesday of every month, me and the Twilio Quest developer, Ryan Cubic, play other educational video games and discuss how those games are teaching and communicating their concepts and what we can learn from that as game designers and educators. So that is called Press X to learn. And that would probably be the other thing I would recommend.

Matthew: How far back do you go? Making me think of things on the BBC master system from when I was a kid like Granny's Garden. And I'd love to see you attacking some of those eight bit games.

Joe: We were going to have one of the devs who worked on, oh my God, what's the really old American Frontier game? Pilgrim's Trail. Yeah, we were going to have one of the devs who worked on that come on. But unfortunately our contact left the company. But yeah, we go back pretty far. We've done a lot of Z Tronics. We've done things like code combat. Yeah, we've done a lot.

Matthew: Great. That sounds superb. Well, thank you again, Joe. We'll see you around.

Joe: Thank you so much.