#61 - The Programmer's Brain and the Importance of Cognition - Felienne Hermans

[00:00:53] Episode Introduction

[00:00:53] Henry Suryawirawan: Hello again, everyone. Hope you’re doing great today. I’m back here again with another new episode of the Tech Lead Journal podcast. Thank you for tuning in and spending your time with me today. If you’re new to this podcast, please follow Tech Lead Journal on your podcast app and social media on LinkedIn, Twitter and Instagram. Also consider supporting the show by subscribing as a patron at techleadjournal.dev/patron, and support me to continue producing great content every week.

Have you ever worked on a piece of code that is quite hard to understand? Maybe the variables naming are cryptic? Or maybe you need to trace a certain flow within a software module that keep you scratching your head to make sense of it? How about learning a new programming language after you’ve worked on one particular language or programming paradigm for a long time? When we encounter difficult or new programming tasks, our brains and cognitions actually work really, really hard, and having a good understanding of how our brains work can bring us a lot of advantages in order to help us design our code better, improve the way we work, and master new technology.

My guest for today’s episode is Felienne Hermans. Failing is the author of “The Programmer’s Brain” and an Associate Professor at Leiden University. She is also the creator of the Hedy programming language, the co-founder of the Joy of Coding conference, and a host at Software Engineering Radio podcast. In this episode, Felienne explained why programming is one of the most demanding cognitive activities based on her own experience and the research that she has done. She described the three different cognitive processes involved when we are writing code, and explained how each of them plays a part for a particular situation. We also discussed a number of interesting programming activities that are cognitively challenging, such as why code reading is hard and how we can get better at it, why naming things is also hard but still it is important for us to get it right, the surprising connection between learning programming languages and spoken languages, and how we can be more conscious and avoid having bugs in our thinking.

This is really a very interesting conversation, and it is like learning the meta skills for being a good programmer. I really enjoyed listening to Felienne’s sharing and explanation, and I hope you find this episode interesting and useful as well. And if you do, please help the show by giving it a rating and review on your podcast app, or share some comments on the social media. Those reviews and comments are one of the best ways to get this podcast to reach more listeners. And hopefully they can also benefit from all the contents in this podcast. So let’s start our episode right after our short sponsor message.

[00:04:18] Introduction

[00:04:18] Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal. Today I have with me a guest named Felienne Hermans. She’s actually from Netherlands. She’s currently the Associate Professor at Leiden University. She’s the creator of the Hedy programming language, and was one of the founders of the “Joy of Coding” conference. Interestingly, she is, and she has been a host at Software Engineering Radio. It’s actually one of the most popular software engineering podcasts. Even I sometimes listen to it. Felienne is the author of “The Programmer’s Brain”, which is the book that we are going to talk about today. I find the book very interesting because it is like the meta thing for programmers to know about. How your brain works? How it actually helps you in terms of doing the coding and all that. So I’m really super excited to talk about it today with Felienne. So welcome to the show.

[00:05:07] Felienne Hermans: Thanks for having me.

[00:05:09] Career Journey

[00:05:09] Henry Suryawirawan: Okay. So maybe Felienne in the beginning, can you share about yourself? Maybe your career journey, any highlights, turning points?

[00:05:16] Felienne Hermans: I guess it’s interesting for people who know, people might know me from my previous work on spreadsheets. So from 2008 to 2012, I did a PhD on spreadsheets where basically the summary was that I made something like an IDE for spreadsheet. So that was my PhD work. And then it was actually a turning point afterwards. After my PhD, I started to get really interested in teaching. I started to teach kids, and that really made me curious about how to teach. Because I will admit that initially I had underestimated teaching. I thought it was going to be easy teaching kids because, you know, they’re 10-year-old, so they’re not going to ask difficult questions because I thought about the programming perspective. But actually it was pretty hard to teach kids, and then I started to get really interested in teaching and then ultimately also in learning. Because if I want to be a good teacher, I have to understand how learning happens in your brain. So this turning point happened. That really was a career path that led to both the book, I would say, and also to the programming language I made for kids.

[00:06:15] Kids Learning Programming

[00:06:15] Henry Suryawirawan: So basically as part of your journey, right? You actually switched your career during that time to more teaching and teaching kids in particular. So from your observation throughout that journey, what did you find about kids learning programming?

[00:06:28] Felienne Hermans: I think that what I found about teaching kids is also true for teaching adults. There’s not that big of a difference. So one of the things I found is that initially, I assumed, which was really a flawed assumption, that if I explain something once, then the kid has heard it and understood it and remembered it. That turned out to be not so very true. There’s a little bit of frustration on my part where kids would ask something that I already told them. I was like, “Well, I told you that”, of course I didn’t say that to them, but I was thinking like, “Well, I told you this last week, so how do you not remember?” That was for me surprising that it is really hard to get information in someone’s brain. And of course, it isn’t so surprising if you look at other things that we teach, let’s say, addition. It isn’t a case that we tell kids, well, you have three apples and then you have two apples and then together you have five apples. Conceptually, this kid has understood addition, it’s not so hard. But then, even if they’ve understood it, they still need to practice. Like five, six-year-olds, how often do they practice addition? Hundreds of times. And there’re all sorts of different variations. One plus four, four plus one, two plus five.

But then in programming, we only do the first part. We explain what is an If statement, and then maybe conceptually a child gets it. But that doesn’t mean that they can apply it. Especially also in application, if you talk about textual languages means getting commas and curly brackets or indentation correct. So that was really for me surprising that the fact that the kids understand something doesn’t mean that they can do it, and the reverse is also true. Sometimes kids are very capable of programming through combination of copy pasting and trying out stuff and looking on YouTube. And they can do some things that makes you impressed like, “Wow. You made this fantastic interactive fiction. Tell me about how it works.” And then it turns out they can do something, but they don’t truly understand it. So both the sides is needed. It is needed that we have a focus on concepts and an understanding, but it’s also important that we have a focus on being able to do stuff. Often in programming, it’s one of the other, and it takes efforts to get kids that can, into kids that know, and the other way around.

[00:08:39] Henry Suryawirawan: As you explained that, actually I’m laughing myself because I am looking at myself. Sometimes, yeah, there are stuff that I know, like all this language syntax probably because of the career. But there’re also stuff that I just copy paste or learn from the blogs and it worked, but yeah, I really don’t know how underlying it works. So I think kids and adults not so different after all, right?

[00:08:57] Felienne Hermans: No. It is very true.

[00:08:58] Writing “The Programmer’s Brain”

[00:08:58] Henry Suryawirawan: Yeah, which actually, I think it led you to writing this book, “The Programmer’s Brain”, and the subtitle is called “What every programmer needs to know about cognition”. Maybe can you share the reason why you actually have interest to write this book, and actually write it in the first place?

[00:09:14] Felienne Hermans: Yeah, I think this was a book that I wish had existed when I was struggling so much with learning and teaching. Because it’s sad that in Computer Science curricula in university, but also in bootcamps and in high school curricula, there isn’t this course about how people learn stuff. Which as you see in my book, also, it might seem like a little bit far away from programming, but there’s so many areas in which people that are programming need to know a little bit about understanding. Most just because they’re teaching and even professionals are teaching because they might be onboarding. But not even if you’re teaching, if you’re trying to learn something yourself, it is very useful if you know how your brain works. But also in writing code, someone else will have to read these code. And we always talk about, yeah, we want to have readable code, right? This is something we value. And we have such really nice frameworks, like code smells. Code smells are not readable. But why? What are the underlying cognitive principles? Because code smells, I have a whole chapter about them.

I love code smells. Half of my PhD thesis was about code smells. But you have to understand why code smells are smelly. Because otherwise, you get this situation like, “Oh, we don’t want to have a long method, so all our methods are no longer than five lines.” Yeah, why? Well, this is in Fowler’s book. So understanding what makes code readable from a cognitive perspective will help you design better. Better user interfaces, better APIs, better libraries. Just better code bases that are easier for people to get onboarded into. So there are so many areas of programming where knowing something about knowing it’s just going to make you happier and more effective. It is a surprise that this doesn’t really exist, and it’s also hard like there are many introductory cognitive science books, so you can have access to that information. But then if it’s not contextualized to programming at all, then why would programmers read that? It isn’t very clear what the benefit is? What I’m going to gain if I learn this? So I thought, well, maybe it’s good if we have a book that has a little bit of introductory cognitive science, and then a lot about what that means for programming, for different aspects of programming like design patterns and naming and code smells and onboarding, like all that, the stuff I talk about in the book.

[00:11:19] Programming as Demanding Cognitive Activity

[00:11:19] Henry Suryawirawan: And you mentioned in the beginning, it’s interesting for me, right? The fact that you said programming is one of the most demanding cognitive activities. Maybe you can compare it with some other demanding cognitive activities? And then the second question will be what does that imply for us as a programmer to actually maybe prepare us physically or maybe mentally, or even like part of our brain or diet or maybe something like that?

[00:11:40] Felienne Hermans: Sure. That’s a lovely question, by the way. So of course, everyone will say that our work is harder, right? I’m sure that housepainter say that their work is the hardest, and nurses say that their work is the most demanding. So you have to take this with a grain of sand, coming from a Computer Science professor says, “Oh, programming is the hard.” So I have to start with that disclaimer. But what I think makes programming so hard is if we compare it to writing nonfiction, writing an essay or writing a letter in which one has to convince someone, I think those are at the same level of hard. You have a solution in mind. You have a plan. These are going to be my five arguments that I used to make my case. However, then programming adds this extra layer of you cannot freely express your thoughts. I was just before this interview writing a column for a magazine that I write a monthly column for, and I can freely switch over to paragraphs. Word is not going to tell me, “Oh no, you cannot switch those paragraphs because you make an argument in the second one that you only started in the first one.” So now there’s an error, right?

So at one point, programming is about these big ideas, classes and methods and user interfaces and calls to the database. But at the same time, every change you make has to be in this very constrained form of the syntax has to be correct. And in some languages, depending on your language of choice, the type system has an opinion about what you’re doing. So it has to translate these very high level ideas into very, very specific forms, and it’s very hard. We talk a little bit about it in the book as well. Programming languages are not made as means of thinking. Like languages, as I said, if you’re just writing fiction or nonfiction, you can make sentences that are incorrect for now, like just put a placeholder that’s half finished, and I can save my word documents in that form, and then the next day I come back and I can fix it. But these are hard to save code that isn’t like compiling, because this is maybe… I don’t want to commit this form of my code. Or yesterday I was like committing code in which tests were still failing, and then I feel a bit like dirty, right? I don’t want to be in this situation, but you know, I had to finish because day was ending. So I think that is what makes programming hard. You have to have both big ideas and plans, but you have to do that while fighting with the syntax, the compiler, the transpiler, and in many cases, type systems and other details. So that’s switching of mental modes is just really hard.

[00:14:09] Henry Suryawirawan: So, yeah, related to my second question is when programmers understand about the cognitive demand of this job, yes, then you will need to understand how the brain works, in order to be a much more effective, more performant as a programmer. So what should we do actually as a programmer to actually first be conscious about it and do something about it?

[00:14:28] Felienne Hermans: That’s again a great question. So there’s a bunch of things that you can do. The book has many exercises that people can try. One thing I think is important to realize is that syntax might be more important than we think. So we have this culture in programming in which we explicitly tell each other and also novices that syntax doesn’t matter. You can just Google the syntax. It is all about logic. You can look everything up on the internet or your compiler will teach you. There’s very much this under stream of that a compiler can be a teacher to kids like, oh, if they make a mistake, then you’ll get an error message. And that will be informative and very clear, and then the kids or the programmer know what to do. So we told each other that syntax knowledge is irrelevant. This is interesting because this is at a certain level true. Like, I am now learning Rust, coming from a background in C# and in Python, and I can express some of my ideas half assed, and then I Google for the rest syntax and I get there.

So this is true at a certain level. But for beginners, it is not all that true. It is a bit like rich people saying money is not so important. Yes. It’s not so important if you have a little bit of money, but if you have no money, it is very important. So I think this is something we underestimate that if you don’t know the basics of the language, then it takes so much energy and efforts to find the syntax that you’re not going to be productive. Even in languages you know really well, if there’s a few syntax concepts that you have to look up, every time you’re spending time and energy, switching to Stackoverflow, Googling, figuring out what you need. Just a little bit of syntax practice is going to go a long way. So that’s something, I think people discount because practice is boring. We don’t want to do boring stuff in programming. We want to do cool stuff. And programming certainly is more fun than drilling syntax. I make a more elaborate case, of course, in the book. Drilling syntax is actually a very effective way to make yourself a more effective programmer.

[00:16:23] Code Reading is So Hard

[00:16:23] Henry Suryawirawan: And maybe this is also related to how we actually read the code, right? Because sometimes if we don’t know the syntax, of course, it’s like very confusing. It’s like, I’m an English speaker, but I read something like Chinese. You don’t even understand the syntax. And then you have a whole section of how to read a code better. In the first place, you mentioned that actually code reading is so hard, and we should get better at reading the code. So maybe can explain more, why is it so hard for reading code?

[00:16:48] Felienne Hermans: Yeah. So there’re two things that make code reading hard. The first thing is inherent to the activity of code reading. And this is basically I’m going to make the same argument I just made a little bit before, that you have to have these two levels. So at one point, you are reading variable names and maybe you’re reading syntactic constructions, where you’re like, “Hmm, what exactly happens here?” But at the same time, you have to get this high level of thinking, in some cases, only from the code. So you have to re-engineer what was this person thinking? And maybe this wasn’t you, or maybe this was you two months ago under a very strict deadline, not making the wisest of decisions. So it gets really hard to form this abstract thing that is syntax. You have to reconstruct the mental model of the programmer, which is really a little bit easier if you were the person designing the codes, or if there’s really good documentation, or if you had extensive communication with the person that made the decisions. So that is what makes code reading hard. From one perspective, this is inherent. There’s not much we can do about it.

But a second thing that makes code reading hard is that we never practice it. Again, Computer Science curricula in universities, but also in bootcamps, are solely based on production. In the university where I went to school, when I was doing my undergrads, we have literally programming 1, 2, 3, 4, 5, and 6. In these programming courses, we’re all writing code. Sort of this assignment like, “Oh, you have to reverse a linked list. You have to create a hash map. You have to print Fibonacci’s sequence.” You know these things. And it was always the goal of the student to write that code. There was no course called reading codes. Of course it happens here and there, but no one ever taught me, “Hey, here are five strategies you can use to read code.” No one ever says, “This is your homework for this week. Here’s code. Tell me what happens here. Tell me how you would improve this.” So it just isn’t a skill that we ever practiced. So of course it is really hard. Because you’ve never done it. Like, I have almost never thrown a Frisbee in my life. This will be really hard for me. Maybe throwing a Frisbee isn’t necessarily harder than hitting a tennis ball, but if I never practiced this, of course, initially it will be harder. So I think the fact that we don’t do it that we have this unspoken subtle belief that if you want to get better at programming, you have to do a lot of programming. And that just writing more is magically also going to make you better at reading code. I think that also makes it harder. And that second thing, of course, clearly we can do something about.

[00:19:14] Henry Suryawirawan: As you mentioned that, actually I was thinking maybe because a lot of interviews these days asking you how to write code, how to solve a problem. But no one, actually, I think I haven’t seen in my career anyway, ask you to read the code and maybe, do some change or maybe modify or even explain what this code does. I think it’s quite interesting concept.

[00:19:32] 3 Cognitive Processes

[00:19:32] Henry Suryawirawan: The other thing, I think you put it maybe as the center of the book, right? There are three different cognitive processes that maybe we should be aware of. The first is called short-term memory, and then there’s a long-term memory and there’s also working memory. So for people who are probably not into all these, right? How the brain works? Maybe you can explain what are the relations of all these three into what I should know about as a programmer?

[00:19:55] Felienne Hermans: For sure. So the long-term memory is what we usually say, if we say memory and memories, right? So this is like your hard drive. This is where everything you have experienced in life is stored. But also where syntax knowledge is stored, for example. So if in Python I want to make a For loop, then I know For loop and Python and my long-term memory tells me this is For i in range, open brackets, For closing bracket. This is in my long-term memory. Some things might be more assessable. So for Python, for me, it’s easy to say the For loop. For C#, which was a longer time ago, I already have to start thinking. So I think it starts with open brackets, For, and then there’s a semi-colon. I think I do i is 0 semi-colon, i smaller than N semi-colon, i++ closing records, curly. So you see some things are more readily available than other things. So that’s the long-term memory.

And then you also have the short-term memory. Short-term memory is where stuff is stored briefly. It’s like an IO buffer. If you read something or if you’re now listening to my voice, then the last sentence is in your short-term memory. And your short-term memory is really like a buffer, so it’s very small, and it lasts only for very short periods of time. If you don’t process it, then it just evaporates. That processing is done in a working memory, which you could see a little bit like the processor of the brain. If you were thinking about something, and if I just gave you an example, like I said, For loop, and then you’re a Scala programmer, you’re like, oh For loop, oh, I know the For loop in Scala. So if you’re thinking about something that wasn’t explicitly told, but you were thinking about it, this is really where the working memory becomes exist. The working memory very much relies and collaborates with the long-term memory. So the fact that you can understand what I’m saying is because the long-term memory for every word I’m saying tells you what the meaning of the words is. You already know this. Also, all the knowledge that you have is sent to the working memory from the long-term memory. That’s the basics. Of course, in the book I explained with a little bit more depth than examples, but those are the basics.

[00:21:58] Henry Suryawirawan: Yeah. So for people who are interested in this concept, I would highly suggest you to read the book because there are so many different examples how all of these three could interrelate with each other. So it’s quite exciting research, I would say.

[00:22:09] How to Improve Code Reading Skills

[00:22:09] Henry Suryawirawan: Talking about research, right? So I think many people maybe by now should have realized it. Almost 60% or maybe more of our time as a programmer, unless you’re working a greenfield project, of course, is spent actually understanding existing code base instead of writing a new one. So based on this research, I think reading code becomes much more important. What will be some of your tips for all of programmers here to know about in order to improve their code reading skills?

[00:22:36] Felienne Hermans: Yeah. So you have these three different memory systems and all those three are in play when you’re reading code and you can all strengthen them in different ways. So sometimes if you’re reading code, you really have this long-term memory issue. There’s a certain keyword or maybe a variable name, a concept that you don’t know. That’s an issue with long-term memory. There’s a word, you don’t know the meaning. If that is the case, and your best strategy there is to look up this word, and then to make sure you learn this word or the syntax, they call it. If you’re working in a code base in Python for example, and there’s lots of list comprehensions. Maybe this isn’t something you’re familiar with, if you’re not an expert or an experienced Python programmer, this is just something you can train. So that is the long-term memory.

Sometimes, there is a working memory issue. It’s really a different problem. Maybe sometime you’re reading code, you know, the meaning of each line of code, but you have trouble figuring out what’s going on. Ah, okay. So this variable there. Oh, and then there’s an API call and then there’s some database activity. What actually is going on here? What is the essence of this? That’s different type of problem. Then more information isn’t going to help you. Because you know everything, but you don’t really understand. You can’t really see it, like see through the code. So there are other strategies that are useful. For example, you can support your working memory, which is also very limited, by putting some stuff on paper. So we have a few exercises and diagrams in the book of how you can offload information that’s in your brain to the paper to free up more mental reasoning space. So the first step I think of reading code, if you’re like, “Arghh, this code is terrible. I hate this. What idiot wrote this?” And then you are the idiot six months ago. So it was like, “Oh shit, I did this.” So if you’re in this situation, that code is hard. First, start to understand why is this hard? Do I have a knowledge problem? Do I lack certain information that I can find somewhere? Or do I have a processing problem? Do I understand everything that’s there? But then the issue is seeing how it all fits together. So I guess that’s the first step is self-diagnosis of understanding why is this so hard.

[00:24:41] Henry Suryawirawan: So, I think it’s interesting when you say you should ask question to yourself, why is it hard? Because to me, even my personal experience, sometimes I don’t ask that question intentionally. And I just know that, okay, this code base is hard. But yeah, I just don’t know why is it hard? That is actually a very interesting awareness question, I would say. Sometimes I think we need to ask why is it hard, right? By then, we should know, okay. What things should be there in order to make the code base maybe more understandable and more readable.

[00:25:07] Power of Chunking

[00:25:07] Henry Suryawirawan: You have few strategies in the topic of “power of chunking”. So a few topics like design patterns, comments, and beacons. Maybe you can share a little bit here. What do you mean by the power of chunking and how all this actually helps us?

[00:25:19] Felienne Hermans: Yeah, that is a great question. So with chunking, we mean individual blocks of information. So if you are an experienced developer, then you read code and then, for example, a For loop for you, you read it and you just see this as a For loop over the list of customers. You don’t read the individual parts. You don’t go, oh, For C in customers. You at once, grab it. Like we also grab words. If we read a word immediately, we read the whole word. But a beginner might really focus on all the individual subparts. A six-year-old, if they’re reading, they don’t go get. They go like G E T, get. They have to do these little steps first. So for a kid, chunks or letters, and for us sentences can be chunks because we’re going to read what a whole sentence at once. This is true for code as well. So if you are struggling with code, sometimes it might be because it is hard for you to chunk the code. Maybe if it’s very unconventional, that really makes it harder to chunk, or if you just lack experience with certain concept. So realizing what are the blocks here? What are the separate parts in this code is really going to be very helpful.

And then you also mentioned beacons. Beacons are things in code that helped me process code. So comments can sometimes serve as a beacon. If on the top of a For loop, it says, processing all customers or analyzing customers, then if I don’t immediately see what it’s doing, then that little bit of comments can help me divide the code into blocks. Maybe I have four or five API calls after each other, and I don’t really know what’s everything’s doing. If there’s a comment that tells me, initializing the database and grabbing the latest data or something, then I don’t really have to understand all the individual pieces. I can trust that block is doing something. So realizing the block, trying to do actively chunking, that’s really something that can help.

[00:27:13] Henry Suryawirawan: So the beacons, I think, maybe it’s like post-it notes sometimes as well. Like when you go through the code, it’s like telling you this part of the code is doing something. Or maybe even use the name of the variable, or name of the method itself.

[00:27:24] Felienne Hermans: Yes, absolutely. Names can also serve as a beacon. Anything that helps you understand this mental model of the creator. Like why are this stuff the way it is? Those are all types of beacons.

[00:27:35] Learning Programming and Spoken Language

[00:27:35] Henry Suryawirawan: So maybe switching from reading to actually writing. I think there’s one interesting topic that you probably talked about last time a lot, which is about if you can learn some language, right? Maybe take an example, French. You can actually learn Python. So what’s the relation here? Why do you see this interchangeable skills between your learning a particular spoken language and also programming language?

[00:27:56] Felienne Hermans: Yeah, this is a great question. So this is not my own research. This is research by someone else. A researcher called Prat that wrote a nature paper a year and a half ago, and they actually did a study. So they measured that students that were really good at learning a second language were also really good at learning a programming language. Better at learning a programming language than students that were less good at learning natural language. And also, of course, it isn’t surprising other research that I talked about in the book as well, has already looked at what physical regions of your brain are active if you read code, and the language processing is very active if you read code. Which of course, when you’re reading words like variable names and keywords, so it isn’t so surprising on the one hand.

But the reason I like this result is because it also goes a bit against the grain of stuff we tell each other. Because we tell each other, if you are going to Computer Science department of the university as I do, we tell students, “Oh, you have to be really good at math.” And then in the curriculum we have statistics, and linear algebra, and calculus. So we tell each other and also people outside of Computer Science that if you’re really good at math, you’re going to be a good programmer. So kids that maybe aren’t so interested in math, might not feel like they are programmers. We know we have a gender issue in programming. Girls are more likely to be good at languages. I don’t know if this is nature or nurture, but we do know that women tend to have more affinity with language. So if we start saying, which also happens to be true, Hey, programming is sure it is math and there is definitely logic in it, but also it is languagee, right? So language people will also thrive in programming. I think that might do wonder for type of inclusion to get people that are less interested in math and more interested in languages, also into programming. Because it is a bit of both. That is what research seems to indicate. And this math side, we got to go over it. We talked about that for decades. So we now also, I think, need to spend a little deliberate effort into the language side of things.

[00:30:00] Henry Suryawirawan: So speaking about logic, of course, we can’t deny about that, right? The importance of logic. Because you can’t construct a working program without the logic. But which part of the languagee, the thing that you mentioned, that actually can be translated into day-to-day programming work?

[00:30:14] Felienne Hermans: So there’re some strategies that we also talk about in the book, that are strategies from language comprehension, from text comprehension, that’s also work really well for code comprehension. For example, making a summary. Maybe something you learned in high school. I definitely learned this in high school. In English, you’re asked to read a newspaper article for five minutes, and then you close the newspaper and you have to write the summary. What are the most important points? This is something we practice for text comprehension. That’s also something that’s going to be really useful for code comprehension. Reading something, and trying to practice, teach yourself to get through the essence of a certain block of code or methods or a class. So there are lots of strategies we know from text comprehension are good strategies to quickly gain insights into something. Many of those will probably work well for programming also.

[00:31:02] Bugs in Thinking

[00:31:02] Henry Suryawirawan: There’s one in particular, very interesting topic that you mentioned about thinking about code. Which is like sometimes a bug in the code actually is translated because of the bugs in your thinking. And you mentioned that by understanding how the brain can actually hold misconceptions, and how actually those misconceptions lead to bugs. So maybe you can share a little bit more. What do you mean by bugs in thinking?

[00:31:24] Felienne Hermans: Yeah, that’s a great point. So misconceptions, we sometimes use this informally, right? If you’re confused, then you have a misconception. But technically, a misconception actually means that you are wrong, but you think you’re right. Which is a very different situation from being wrong, and knowing that your understanding is a bit brittle. So a misconception happens when you think something is the case, but it actually isn’t, but you’re really sure that you’re right. Misconceptions can often result from what we call transfer. Transfer is when you know something about thing A, and you’re going to use that knowledge to do thing B. For example, if you come from Java, and you go to C#, then those are the things you know are also going to be true. Everything is peachy. But many languages are not the same. So I made the transfer from C# to Python. And then you think you know object-oriented programming. Okay, Python, it also has classes and methods, right? So this is going to be fine. It’s just going to be easy. I trained for this. But then it is not easy because finding a class in Python, I was like, okay, I’m going to make a class. So where do I put the fields? And then turns out you put the fields in the constructor. I’m like, you can’t put them in the constructor because they have to be already on the class. I have to put them somewhere. “No, no, this is not possible. We do this at runtime.” And that sort of breaks your brain, right? You’re like, “No, but what do fields mean at runtime?” Everything you thought you knew, you didn’t. That is a source of misconception, where you really, you think, you know what OOP is, and then it turns out you don’t.

So this isn’t only true between the programming languages. Although, of course, that’s a situation in which it’s commonly happens. Even within a programming language, part of your code base or switching to a different code base, convention might be really different. So you think, “Oh, I know how this works.” And then something entirely different happens. I can give an example where a contributor on my open source repository has added some code, which I had acceptance test. I like, oh, sure. This works. So that’s fine. Let’s close this issue. But then I started to actually look at the code and it turns out he used lazy operations, which I knew it from Haskell what laziness was, but then really understanding how that works within Python. So even in a programming language, there can be concepts that you are not that familiar with, where you’re like, “Eh? What does this do?” I think I might know and then turn out your assumptions are wrong. So those are misconceptions and they are, as you nicely summarized, they are like bugs in thinking. You’re thinking in the wrong way. It isn’t like, which sometimes happens with a bug that you have the right idea, but you mis-implemented it. But you can also just have a wrong idea, and then of course your implementation is also going to be wrong.

[00:34:04] Henry Suryawirawan: And also, I think when you speak about language difference and even internal libraries of how it works, sometimes also, I think when you switch between teams, for example, I think one team’s way of doing things might also be different than the other team’s, even though it’s the same language. I think this probably is also one source of maybe misconception because some teams like to do it in a certain style, certain way, or certain paradigm while the other teams are doing it in the other way. So thanks for highlighting this misconception. I think that’s really important for us to be aware as well.

[00:34:32] Naming Things is Hard

[00:34:32] Henry Suryawirawan: Looking about writing better code, I don’t know whether it’s a joke or not, people say that there are only two hard problems in computer science. First one is actually cache invalidation. We are not going to talk about that. But the second one is about naming things. Naming things seems to have some kind of cognitive relation. Could you explain why naming things is so hard? I mean, it’s just finding name, right? After all.

[00:34:53] Felienne Hermans: Yeah. Well, so I think half a philosophy is finding names for things, right? What is this concept? And how is this concept different from that other concept? So naming something, describing what an abstract thing is, and delineating this is this thing and this isn’t that other thing. You have these subtle things in programming, like the difference between an order and a shipment. So an order is something that a customer does, and the shipment is the thing we sent to the customer, which is almost the same. And then in English, it might be different than in my language or in other people’s language, whether or not that thing exactly means the same thing. So these types of subtleties might really be hard to grasp in a name. That part is like, again, the inherent hard part of name. So there’s not much we can do about that. That is just really hard. Like group communication within your team about the meaning of stuff is important, but that principle will always remain hard.

But there’s also other stuff that’s really hard that doesn’t have to be hard where I can offer a solution. Something I talk about in the book is something I really, really love the idea of name molds. Again, this isn’t my research. This is a researcher called Feitelson that describes this research and the idea of a name mold is that if you have come up with the good parts of a name, how are you going to structure it? For example, if you have the maximum interest rate over a year, what is that variable called? Is this interest rate maximum or maximum interest rate or max interest rates? There’s so many options. This is an easy problem to fix. You can just have one meeting with your team, “Okay, what is our structure?” And then in the chapter in my book has some examples, and it doesn’t even matter that much which you pick. But if you always pick the same strategy, we know from research that it will be a lot easier for your brain to find the relevant parts. And this is something you can do at a code base level, and maybe if this result gets a bit more famous, Python can say, “Okay, this is the main mold.” Like we say, “Oh, we use snake case for variable names. Oh, we prefer this way of name moving.” And then maybe something systematic at a programming language level can happen.

This is something that is easy to do, and you can start straight away. You can make a decision and do it now, and if you don’t have to refactor everything today. If you find other molds then you refactor it then. I love this paper. I wish I would have come up with this idea because it almost cost nothing, and the cognitive benefits are immediately clear. If you’re always looking for information in the same place, it will be cheaper for your brain to process variable names. So some stuff of naming is hard. But there’s also stuff we do to ourselves and it could be fixed, and I think the name molds are a really nice step into direction of making stuff easier.

[00:37:36] Code with Bad Names Has More Bugs

[00:37:36] Henry Suryawirawan: Speaking about research, probably there’s this research where you actually found as part of writing of the book, that you said code with bad names tends to have more bugs. I think maybe logically speaking it makes sense, right? Because maybe you misunderstand, again, coming back to the misconception. If you name something incorrectly or maybe misleading sometimes, in fact will tend to lead it to more bugs. But many times in my career, I can see that some programmers just don’t think too hard about picking the right name. I think it’s quite common people just say, okay, whatever that is in the mind, just stick that in. But what will be the best way to actually have everyone be consciously picking names or maybe even coming up with the discussion, like what you mentioned, oh, which name should I choose? Because it is not common in my experience for people having such discussion.

[00:38:23] Felienne Hermans: It’s true. I think it goes back to the reading that we just don’t do systematically. Sometimes, it also makes sense that you don’t pick a good name because sometimes your brain, and we talked about the processing power of the brain, sometimes your brain is so full with the algorithm or the strategy that it’s just, I don’t have time to pick a right name. Now I will just call this X or B or U or C, and that’s fine and acceptable and understandable. But if you have in your team this team responsibility of reading code together, of maybe doing code reviews as a group looking at code together, then it’s also something you can improve. Okay, so now the code works. Okay. So I can call my processor. I can turn off the turbo button. So now I can do processing in peace.

Now once everything’s working, maybe I can do this extra step of picking good names or ask someone who wasn’t involved in writing the code, “What do you think is a good name here?” Yes, it is true that it isn’t always done, but I guess also that is because we have this focus on production. And also, of course, I’m an academic, so I can easily fantasize about hypothetical working conditions in which everyone is so interested in sipping coffee and discussing good naming. I understand that another pressure of deadlines, working code is better than properly named code that is half finished. So you have to also think about a realistic settings. But if there is time, if there has been a code that has been deployed, maybe some time can be spent on improving names.

[00:39:48] Henry Suryawirawan: I think also there’s one scare if, let’s say, in the code review, you ask someone to change the name. It could be like they treat it as like a petty comments, like, why are you so fussy about names? I think this is also coming back to the awareness for programmers, right? Actually, names tend to matter. What’s your strategy actually, when we see this in a code review that someone asked you to change the name. And it could lead to a lot of implications, because you need to refactor some of the code, probably. If the scope are larger, of course, if it’s local, then maybe not a big deal. But, yes. What do you think the trade-offs here? Should you actually make that kind of review comments?

[00:40:21] Felienne Hermans: Yes, I think you absolutely should make those comments if you think this name is confusing. And I have sometimes made these comments where I say, this name, it sends me off the wrong path. So I read, and I tried to be explicit about it as well. I read this name, and it makes me assume that such and such happens. But in fact, upon further consideration, it turns out something else is happening. So I tried to explain what connotations the name has for me, and I think that’s really a fine comment to make where you say, “Well, I was really doing my best to understand and this name wasn’t helping.” And of course, maybe you have a discussion where another person says, “No, that didn’t happen for me.” And then maybe I am the minority opinion. Okay. Well fine. Maybe I’m the only one that was confused here. It has to do, again, a lot with the prior knowledge and experience you already have. But I actually don’t think it’s a petty comment. If the name gives you the wrong impression, then that’s something to discuss. And it could end up, you keep the name and you put a comment there saying, “Oh, this getter also sets this whole thing, right? Warning! You might think this getter doesn’t have side effects, but it does in this case.” That might also be a conclusion where you keep the name. But the confusion that someone might experience is addressed in a different way.

[00:41:31] Mental Models

[00:41:31] Henry Suryawirawan: Speaking about cognitive itself, many people like I’m also interested in this topic for some other areas, not just programming, right? So there’s this thing called mental models. I follow quite a number of people, like maybe Shane Parrish is one where he talks a lot about mental models. And it’s quite interesting how you can actually use some kind of analogy thinking and map it to different ways. So in programming, what do you think are some of the interesting or important mental models? Maybe based on your research or based on your experience.

[00:41:58] Felienne Hermans: Yeah. So anything can be a mental model. So design patterns, of course, come to mind. So design patterns are shortcuts to mental models that I can think, oh, this is a decorator pattern. And then I immediately get all sorts of information. Graphs can be really nice mental models that are maybe a little bit more abstract where you think about code as something that is there’s data, and that this sends to another class. And then a class processes the data and sends it to another part of the code base. So graph can be your really nice mental model. But sometimes a table is a better mental model, if you’re really doing SQL queries, and maybe you think of a table. And you’re really thinking, the where clause is grabbing certain rows, and the select is controlling certain columns. So I guess it really depends what type of thing you’re doing.

[00:42:45] Other Cognitive Aspects

[00:42:45] Henry Suryawirawan: And when you associate the things like programmers with the brain, actually another part of maybe biology and science and all that. When you talk about brain, there are other parts, other aspects from human point of view that can actually lead to a better brain performance. So things like sleep, diet, maybe some core mental health, like all this meditation. Do you think it also helps for programmers to actually exercise from that point of view so that their cognitive is much better?

[00:43:11] Felienne Hermans: Yeah, for sure. I must admit that this isn’t really my area of expertise. But I know there’s some research that indeed says that code that is shipped on night time, or I think it was like something like Friday afternoon is more likely to have bugs. And again, I keep saying culture, that’s like my thing. Here also, you have this culture of overwork. We have the culture of you should like programming so much that you like also to program on Saturday. You know, did you work on open source projects? We’ve very much glorified people that only like programming. If you have other hobbies, especially if they aren’t traditional nerd hobbies, like I really like knitting and running ultra marathons. Those aren’t things we traditionally associate with programmers. So role-playing games, board games, computer games, reading sci-fi novels, that’s stuff that’s okay, accepted hobbies, and other hobbies are like less accepted. So we have this culture in which we say, you should program basically all day and all night. You should love that. It’s not healthy. I guess everyone knows by now that you need non programming, non work-related hobbies. It’s just not healthy to work all the time. As I said, research also shows it’s just not very effective. It’s way more effective to just work eight hours and then eat a healthy meal, go to sleep and do some exercise. Yeah, I guess it’s not surprising, but it still has to permeate all the stereotypes we have in the programming world about what a programmer looks like and likes.

[00:44:37] Impact of Interruptions

[00:44:37] Henry Suryawirawan: Yeah. And speaking about working night time, because many of us these days are interrupted, either through meetings or maybe chats or maybe just incidents during working hours. And programmers like to be interrupted by other people. So, what do you think this impact for interruptions and developers’ work?

[00:44:55] Felienne Hermans: Yeah, it’s a great question. So we have some research about that in the book as well. Again, not my research, but research by other people, that shows that it can take up to 15 minutes after an interruption to get back into work. Specifically, when you have to reconstruct the mental model that you were using to think about the code. And we all know this feeling. You’re very heavily engaged in code and someone comes in, either in Slack or physically in your office, “Oh, do you want a coffee?” Or, “Do you have a minute?” And you just sort of feel the house of cards in your brain fall down, right? It’s like, “Oh no, I have forgotten everything. Go away.” Husbands or coworker or whoever was disturbing me. “Not now!” So the interruptions are very expensive. We know, and this is something we will have to deal with in various ways. And luckily, there are lots of interesting initiatives. Like I have this example in my book of a tool called Flow Lights. That is a device you can actually put on your desk and it connects to your IDE. And it tries to guess when you’re really engaged. And then it makes the light red, if you’re very heavily involved in thinking based on IDE interactions. I think that’s a lovely idea, and this FlowLights is a physical device. But clearly, also you could have this in Slack, where it says, “Do Not Disturb, I am programming.” So there are technical solutions, but also, of course, our social solutions, like you can have only meetings in the morning. Something like that. Only interruptions in the morning, unless our website is down and is emergency. There’s technical and social solutions here.

[00:46:22] Henry Suryawirawan: Sometimes I also wonder, for example, there’s a good 30 minutes, like I do some coding, but then the next meeting will come. So I wonder if next time there is such an invention that, okay, I’m still doing this focus work. Maybe I’ll just auto reject the meeting.

[00:46:35] Felienne Hermans: Yes. Or sends an email. “Oh, I’m sorry. I am still programming. Can we push it back?” But I guess if you take that too far, that you will never have meetings and you will only be programming, which maybe your supervisor also doesn’t like.

[00:46:46] 2 Tech Lead Wisdom

[00:46:46] Henry Suryawirawan: So, Felienne, I’ve enjoyed this conversation so much. I learned a lot about the cognitive thing, the brain aspect of the programmers. So maybe as one last question before we end the whole conversation is, normally I ask all my guests to share their three technical leadership wisdom. So maybe if you can share your three technical leadership wisdom so that we can learn from you.

[00:47:06] Felienne Hermans: For sure. So I thought about this. I love this question because it’s not something I heard before. So first, kudos for this cool question. I thought about it a bit. My first leadership principle would be to really examine the culture of your team or your code base or your open source project. I have said culture in this podcast a lot, and I say it in my talk also a lot. So there are so many things we tell each other, explicitly or implicitly. Like I said, a good programmer likes to program all day. This is stuff we say. I have said this and sometimes thought it as well. So I think it’s always very important if you see people having a certain belief to keep examining that, and to pick it apart and say, “Hey. Is this actually true?” And it might be true. Now in the workforce we have many people that like to program also outside of work. And is that what we want? Is this healthy and is this good? So examining culture, I think is really something you need to do with any team. Like I lead a research team in university, and I really tried to see, okay, what are the things we tell each other? This is not easy work. But I think that is the work of leadership is to really think, what is the culture that we want? Initially, when I was a younger manager and leader, I always wanted to help all my teammates. And if they had a question, I was like, oh, it is my responsibility to help everyone. And I was like, okay. When I got a bit older, is this the culture I want? No. I actually much rather have a culture in which people help each other. Keeps me a little bit less busy. But also it’s good, and it’s healthy for medium level programmers and they might teach researchers to also help others. So then I switched from having one-on-one meetings to having more team meetings, and then if there’s a question, I’m like, “That’s a good question. Maybe Emma can help you with that.” I’d like to make these connections. So you have to think about what is the culture I want, and then how do I get there? So culture is one.

My second leadership principle is actually think about principles. I will pick that apart a little bit more. What I see very often if people are writing code together is that you get discussions about tiny things. So I’m in the design committee of JavaScript and I’m also in the Rust team. So I very much think about designing programming language. People in both of those teams are always discussing, like literally, do we put a star here in the syntax? Yes or no. And you get all sorts of discussions on what is the benefit of this syntax? And what is the downside of having a star here or a pipe here or a dash there? And it is interesting. It’s interesting to see these discussions unfold. And I’m very happy that, maybe five years ago, which was very much a discussion, and now it’s getting more towards evidence-based where people are interested in doing experiments and measuring what syntax is actually better.

However, what I see is that what often lacks in programming languages design, but also in code bases, is what are the design principles here? If you get a team first to agree on the design principles. So in this code base, we believe we shouldn’t have too much duplication. Make this explicit. Say this is our design principle, is we want to limit duplication wherever possible. Or, we say, we really value good naming over everything. Even if it makes code longer because the variable names will be longer. We care about naming over other things. If you first get a team to agree on these principles, and if you then write it down, these principles and commonly revisit these principles, this tiny discussions get so much easier, because you can say, oh, I see what you are valuing here is this principle over the other principle. Oh no, but if we pick this, then we lose transparency or whatever. In the book, of course, I talk about this also a little bit. We have this framework called cognitive dimensions of notations, which might help you design tools the principles of your language. But I really find also in designing my own language, the Hedy language, where we just have six design goals. And if we’re doubting, what should we do? We look at the design goals and we say, well, following design goal three, we should do this and following design goal four, we should do this. Oh, which do we value more? So having these clear principles, it is hard work to set that and to get a team to agree on that. But if you’re a benevolent dictator, like I am for my language, you can just say these are the driving principles. If you don’t like this, pick another open source repository. But I want to have them and people that come into your code base will adopt that. And that will ultimately, down the line, make stuff so much easier.

So I think I’ll achieve by sticking with those two. Because I could only come up with these two that I really very much value and like. So think about the culture that you have in a team and make sure that it is what you want it to be. So that’s really the social perspective. And from a technical perspective, think about the principles that you believe in as a team. And it will save you so much discussions later on about, okay, why are we doing this very concrete thing? This, I don’t want people fighting over whether or not there should be an asterix in a certain syntax. It’s just, no one likes that. Ultimately, even though people might think they like it, it is a big waste of time. So, that’s it.

[00:51:53] Henry Suryawirawan: Yeah, I love that. Especially the principles part. Because I think it may also lead to the culture that you want. Setting up the principles that matter for you or the team or the company. Actually, that will build the culture around, for example, how people should behave? What things should they prioritize over the others? So Felienne, thanks so much for this conversation. For people who are interested and want to know more about maybe your research, your book, where can they find you online?

[00:52:16] Felienne Hermans: I’m very easy to find if you know how to spell my name. Because my Twitter handle is just my first name. So that’s easy, @Felienne. And then that’s the best place also to follow me. I also have a website which is equally easy. It is my first name .com, Felienne.com. But I used to really blog a lot when I went to conferences in the dark ages before COVID. So I haven’t updated my website in two years. But maybe now that conferences are starting again, maybe I’ll start blogging. But that’s a place also to find my research, more information about this stuff I do.

[00:52:45] Henry Suryawirawan: Thanks so much for this conversation. I wish you good luck with all your teaching and research and all that.

[00:52:50] Felienne Hermans: Thank you.

– End –