Video size:

0:09 Miko Pawlikowski

Hello and welcome to another episode of Conf42Cast, the podcast from the neighboring galaxy. My name is Miko Pawlikowski and today I'm super excited to be hosting Felienne Hermans, an associate professor at Leiden University, Netherlands and the author of "The Programmer's Brain" book from Manning. Hello Felienne, how are you doing today?

0:29 Felienne Hermans

I'm good, how are you?

0:30 Miko Pawlikowski

I'm doing great and I'm really, really excited for this book. This is something that we don't get on every episode of the podcast. I was really, really happy to see that the book like this was coming up. Because this is literally the first one that I know of that is actually discussing the hardware, the human brain and how it processes it in the, you know, in the context of programming. Can you talk to me a little bit about what prompted you to write this book? What was the motivation behind?

0:59 Felienne Hermans

Yeah, for sure. So when I graduated my PhDs, about 10 years ago now, I started to teach kids in a community center, and they wanted to learn programming. And I thought it wasn't going to be hard, because they were small kids like 10, 11 year olds. So I like, 'This gonna be easy, right? They're small kids, they're not going to ask me any difficult questions, because I know everything about programming. At least I will know more than they do'. But it turned out to be actually really hard. They weren't learning so much. And that made me really interested in teaching and also in learning. Because clearly, it wasn't the motivation of these children, right? They came voluntarily on their free Saturday afternoons to learn. So like, this must be about me, I'm not teaching in the right way. And if you want to be a better teacher, you also have to be, you also have to understand learning. So then I got into this rabbit hole of how do people learn anything? And how does that apply to learning code? So my main goal was to become a better teacher. And then on the way, I learned a lot about cognitive science and a lot of my programming too.

1:59 Miko Pawlikowski

That is awesome. So it all started with Scratch, basically.

2:03 Felienne Hermans

Yeah, it's been specifically also it's a transition from Scratch to text languages. So in Scratch, you don't have to know that much, right? You can sort of figure stuff out by clicking blocks together. But then once you go to a more adult language, which can sometimes be one, they want to have the real stuff, then that was really what I started to struggling. Because you need to know a lot of things like, where does the bracket go? Where does the quotation mark go? And that was really the place where kids sometimes dropped out of the class entirely, because it was too overwhelming for them.

2:34 Miko Pawlikowski

Okay, so that makes perfect sense. And it's actually a very cool origin story. One thing that I do notice when I was reading your book is that there's actually quite a lot of good science behind a lot of this, a lot of experiments that I'm hoping we can kind of go into in a minute. But I wasn't aware that our understanding of the brain was, you know, a little bit better than just guessing. And did you know that that was the case, when you started writing the book? Or did you discover that as you kind of went into other chapters?

3:06 Felienne Hermans

No, I already had a basic understanding of some cognitive science. Actually, very long time ago, I think it was like 2014 or something, I already gave a talk about some of the things that ultimately ended up in the book. So I did have an understanding of what we talk about in the book as well. What is your long term memory? And what is your short term memory? And what is your working memory? Just by, you know, following the news, I had some basic understanding of how stuff was processed. And some of the experiments that I talked about in the book as well, the stuff that was closer to software engineering, this I also knew. Like stuff about, why do design patterns work? And what is the role of cognitive science there? So it wasn't that I had no understanding of any of this, would have been hard to write a book that way. So I had some basic idea of the directions I needed to go in. And then I just needed to gather everything up and put it in the book.

3:57 Miko Pawlikowski

That makes sense. So, Felienne's book is divided into four parts. There is a part on reading code better, thinking about code, on writing code better and then collaborating on code. So, I would like to maybe give our audience a little bit of a sneak peek of one of these parts. Perhaps we could focus on the reading part, which I guess is like a starting point for everybody who actually wants to learn to code. What are the cognitive processes at work when you're actually reading code? Would you dive into that a little bit?

4:37 Felienne Hermans

For sure. So, there are three different memory systems that I talked about in the book that we generally distinguish from each other. There's a long term memory that stores everything you know, and so that you have experiences in life and also for example, Syntax. So you know, if you're a Python programmer that's for i in range, open bracket for closing brackets, go long, that is a form, this is in your long term memory. There's also your short term memory and your short term memory holds information that you read very briefly. So if you're listening to this episodes, then maybe one sentence that you're listening to is in your short term memory. And then from your short term memory, your brain starts processing stuff. So maybe if you listen to my voice, you start thinking about something. This thinking is what happens in the working memory. And what is so important to note, that I talked about in my book, is that the working memory collaborates with your long term memory. So, everything you're listening to now, all the words you already know their meaning. So, the whole time that you're thinking about stuff, your long term memory, sometimes I've described it's like an angel that's sitting on your shoulder, your long term memory is saying, 'Oh, I know this word. I know this concept'. And sometimes random memories pop up, right? So when you're programming something, maybe you think, 'I solved something like this in the past, I used the HashMap then, so maybe this is a good idea now'. So your long term memory is always trying to like offer you help. This is stuff you already know, maybe it is useful, sometimes isn't useful. But often it's very useful. And I think in programming generally, we very much focus on the working memory. We always talk about, you know, thinking and problem solving. So we always talk about, think about the working memory, which should be like the processor of the brain. And we tend to discount a bit the role of the long term memory, when we actively say stuff like, 'Oh, you don't need to know Syntax, because you can simply look up Syntax on the internet, you don't need to know anything, you don't have to have this good knowledge base'. Those are things we typically say. But this isn't really true. Because your long term memory really plays a big role in everything you do. So that's one of the things I talk about in the book, in great lengths.

5:13 Miko Pawlikowski

Yeah, that reminds me of the experiment I thought was rather elegant. And here, I'm gonna attempt the pronunciation, please correct me. Adriaan de Groot.

6:46 Felienne Hermans

Adriaan de Groot is what I would say my native language.

7:01 Miko Pawlikowski

With the chess. Do you think you could talk about what he discovered with that experiment?

7:07 Felienne Hermans

Absolutely, absolutely. So, Adriaan de Groot was a mathematician, actually, in the 1940s, a Dutch mathematician. And he was supposed to write a PhD thesis on Math, but he ended up writing a PhD thesis on chess. And with that, he sort of accidentally started a whole field of cognitive science. Because he wanted to know why are some people better at chess, he was also himself a good chess player. So he was curious at what makes people good at playing chess. And initially he thought that a very good memory makes people really good chess players. So he had these experiments where he showed people at chess boards, and then he showed this to not really like random people off the street, but sort of proper chess players versus chess grandmasters. And then it turned out that these grandmasters were very much better able at remembering chess setups. So he would show them a board for a few seconds, and then you would cover the board with a blanket or something, and they had to put the pieces back and experts were really good at this. So it's like, maybe these grandmasters have a superior memory, maybe they're just really good at memorization, and that is what makes them really good chess players. But then he did an interesting second experiment, where instead of having a normal chess setup, he just scrambled all the pieces. And then he did the exact same experiment, which he has average players and chess grandmasters reproduce the chess setup. And in the second experiments, both were bad and equally bad. So it wasn't like the chess grandmasters had a really good memory for everything. They didn't even have a really good memory for chess pieces. They only had a really good memory for chess setups. And the reason this is what Adriaan de Groot dove into is that the chess grandmasters weren't remembering individual pieces. They weren't thinking like, 'Oh, a rook at A5, a pawn at B7, because then it overflows your short term memory that we know is very, very limited. No, they weren't doing it. They were looking at chess setup and were like, 'Oh, this is Sicilian opening, but one rook is a bit to the left', or, 'Oh, this reminds me of that game that I played with Betsy on that rainy Saturday afternoon in London'. So, they had a very good long term memory for chess setups. And this good long term memory was helping them in processing, remembering and thinking about chess setups. And some similar experiments, that I described in the book as well, were also done, basically the exact same experiments, for TRON codes, where experts were very much better able to remember regular programs than experts. But for scrambled programs, where all the lines were mixed, it was basically the experts and officers were basically equally bad. And this is interesting to know about programming. That's if you're an expert in a programming language, or in a domain, or in a codebase, you really see something different. I look as code in my codebase, I see the code and I immediately, I remember when I wrote it, I remember what I was thinking when I was writing it. I know all the concepts, and then I'm onboarding an undergraph into my open source projects. And it's really hard to keep telling yourself, they aren't seeing the same things. Maybe they're like stuck on the first line, because it has an unfamiliar word or concept. And then the rest of the code just, if the brain is full, then no more information is going to be processed by them. So, that's really something that just might seem a bit far away from programming. But these exact same principles also holds for reading code.

13:02 Miko Pawlikowski

Yeah. In a way that's kind of just lacking pre-loaded libraries or something.

13:09 Felienne Hermans

I love that analogy. I've never described it like that. But I'm going to steal it from you. It is very much like that. It is like you're lacking a pre-loaded library. So you cannot, you cannot call that certain method, because you haven't loaded the library. I love that. Yeah, that's it.

13:23 Miko Pawlikowski

All right. So, tell me about cognitive load, because this is something that now people just throw around on the internet to mean different things. But what is it really and where does it come from?

13:38 Felienne Hermans

So the cognitive load is very, very closely related to the limits that we talked about, these four to six elements. More elements at the same time aren't really processable for your brain. So if you have to do too many things at the same time, then your brain gets overloaded, and then just you can do Effective Thinking anymore. And I guess this is something that programmers all recognize where you're very deep in a codebase, like, 'Oh, let me see, this method is coming from there. And then it initializes this class and this method, oh, and it has some database activity'. And at one point, you just feel you almost like physically feel your brain, you feel that there you are reaching the limit of what you can still process. And this is maybe the moment where you start making bad decisions, because you cannot fully grasp the codes. That's the principle of cognitive loads. It was designed by a researcher called Sweller. And he described this principle, he studied also children learning Math, but adults as well, processing all sorts of topics. And it seems to be the case that this is just for everyone. Some people might be a little bit better, or a little bit worse. But there's always for people this cognitive limit, where they're holding too many things at the same time. And again, this is also very related to the long term memory and the stuff you already know. Because if you're just thinking, 'Oh, this is the decorator pattern, you have lots of cognitive room left. But if you're focusing at lower levels of code, at lines of code or individual variables, then your brain is a little bit more likely to get fooled very soon. So that is the principle of cognitive loads.

15:15 Miko Pawlikowski

Thank you. Thanks for clarifying that. One other thing that I really loved about reading that first part is that I've been meaning to do some coding during an MRI scan for myself for ages, I've always wondered what it would actually show. So I was really relieved to see that someone has actually done that. And you're describing an experiment from, and again trying to not butcher that, ‪Janet Siegmund about putting someone in an MRI scanning machine and making them do some Java programming. Can you describe what they found and what we can apply from that to our daily lives as programmers?

16:00 Felienne Hermans

Yeah, for sure. So the sad thing about an fMRI scanner is that people can't move in the scanner, because that then destroys the scan. So the experiments that Jen Siegmund has done, she has specifically looked at people only reading code in a small screen in a fMRI scanner. So those experiments, just because of the context, are a little bit limited. There's more actually, that we described in the book, there's also very useful. There's also a device called a F-nips device, which is like a fMRI scanner, which you can wear it as a headband. And so those experiments are a little bit more closer to programmers lives, because then people can look at the IDE while they're programming. And the results so far, so it's all new, and we aren't really sure. But the stuff that seems to be the case is that your working memory is working really hard if you're programming, which of course is not a surprise. And that people with a larger working memory sometimes have a little bit easier time reading code. And there's very interesting sort of sometimes a bit conflicting results on the role of mathematical thinking and language thinking. So some of the initial results of Janet would seem to indicate, although we have to be a bit careful, as I said, because of the limited setting that language parts of the brain play a role in processing programming code, which I think is interesting. If we look at how we talk about our own field, very often we say stuff like, 'Oh, you know, you have to be really good at Math, to become a programmer'. Computer science programs at the university typically are quite Math-heavy. And people that like languages, sometimes might not feel so at home in the computer science department, they might not think that programming career is for them. So it's very interesting from the perspective of thinking about what matters for our field, that it seems to be the case that the parts of the brain that we use for programming are also the parts of the brain that we use for processing normal natural language. Which of course isn't surprising either, because I don't remember exactly the number, but it is in the book, but something like 75% of a codebase is word, right? Variables and keywords and metanames. So yeah, it's not weird, of course, that our language brain also plays a role there.

18:18 Miko Pawlikowski

So is that just correlation? Or does it mean that this actually not that different to learn a programming language than it is to learn, let's say, French?

18:27 Felienne Hermans

Yeah, that's a great question. There's another paper that I talked about in the book by some researcher called Pratt. And they actually did a study in which they tried to understand, is this correlation or causation, where they trained people, non-programmers, in a language, and also in programming. And then indeed, they found a correlation, sort of a prediction. That's if you're better at learning natural language, you will also be better at learning a programming language. Again, these are all preliminary experiments. So it is a bit doubtful how strong this relationship is, and whether this will hold for all sorts of populations. But the initial results he really showed it, if you are good at learning a language you will also be better at learning a programming language, which, again, as I said, about the things we believe about our field is really interesting, because this isn't typically something we say, and people that are really good at learning languages might not feel so welcome, or might not think they will be very successful at learning a programming language.

23:03 Miko Pawlikowski

And speaking of hard things, you know, a lot of people say that there are only three difficult things in computer science, right? One is naming things. And the other one is one by one errors. Can you talk to me a little bit about the actual science behind why naming things is so important and so difficult at the same time?

23:28 Felienne Hermans

Yeah, for sure. So, naming things is hard, separate from programming, right? Big parts of philosophy are about, what does this concept mean exactly and how is it different from other concepts. And that's sometimes what we're replicating in programming, you have to pick a word that's ambiguously going to say, this is the thing that we've talked about. And it's definitely not like the other thing that's also in this codebase. So naming in general, it's very hard. But there's one resource that I talked about in the book that I really very much like, and that's about the principle called 'name mods'. One of the things that, I have to take a step back there, one of the things that make doing stuff easier is if stuff is always in the same way. Like I put my keys next to my front door, they're always there. I don't have to think about where my keys are. I exit the house and I grab my keys, and they're always there. That is the idea behind name mods. Name mods talks about how to structure a name. So it doesn't really talk about how to name something, because that is just really hard. But something we can make easier is giving names always the same structure. So for example, you have the maximum interest rate, how do you call that? I'm sure that if we would sample codebases out there, there are many different ways that people will do that. People would say, interest rate maximum or max interest rate, or maximum interest rate, or maybe maximum of interest rates. So there's all these different forms that you can use, and the idea of name mods is that in a codebase, or maybe ultimately if this catches on in a programming language, we say the way we do stuff is we first say the quantity, we first say interest rates. And then we say the quantifier, maximum, minimum, first, whatever, or the other way around, doesn't really make that much difference what you pick. But if you always pick the same thing, like with your keys next to the front door, it takes you less energy to process. And also it takes you less energy, of course, to decide what you're going to do, because you can just always pick the name mods. So there's stuff that we can't make easier. Describing a concept is really hard. But something like name mods is a relatively easy thing to do. So if you're working on a codebase, you can just have a little meeting and say, 'Okay, this is our name, mod'. And going forward. That's what you use, that's relatively easy and cheap thing to do. And you can also just start, you don't have to necessarily refactor every name in your codebase, you can start saying from now on, if we introduce new variable names, this is the mod we use. If we see variable names that aren't in this mod, we just refactor and then we can take it slow. It costs almost nothing, and it is definitely going to help you. So that's just something, like I love this paper. Sometimes, if you're a scientist, you're like, 'I wish I came up with this idea. It's such a lovely and simple idea that you can explain to anyone'. And it's not like you need an expensive AI tool to do anything. This is like super, super easy. So I just like want to talk about this result, because it's just an easy thing to do. And it's such a lovely, cute idea. I love this paper.

26:33 Miko Pawlikowski

It certainly does. And I can definitely relate to the feeling of oh, for once I put my keys somewhere else. And now I have a mini heart attack, because it doesn't compute. That's just scary. I love it. I basically loved pretty much every minute I spent reading your book. For everybody else. This is just a small portion of the goodies that you find in Felienne's book. Other things, like actually writing the code, code smells and the cognition effects on that, patterns, anti-patterns. In general getting better at solving problems, you're going to find plenty of more science-backed evidence for this things in the book. The book is available from Manning. You can go to money.com/books/the-programmers-brain or go for Amazon. The book is already available in print, and it will shortly be available as a digital version on Amazon. And can you tell us Felienne, where to find you with any questions or just to chat about amazing things in your book?

27:43 Felienne Hermans

The best place to find me is on Twitter. My Twitter handle is very conveniently just my first name. So if you know how to spell my first name, then it's easy to find me on Twitter and I guess you could put a link to my Twitter as well in the show notes. And my website is similarly easy. It's just my first name.com, where I sometimes blog about research and papers and stuff. Well, usually I blog if I go to conferences, so it has been silent for a while.

28:06 Miko Pawlikowski

It's been an absolute pleasure. Felienne Hermans, Associate Professor at Leiden University, Netherlands and the author of "The Programmer's Brain". Thank you so much for coming.

28:16 Felienne Hermans

Thanks for having me.