Felienne joins host Jeff Doolittle as a guest on the show to discuss her book, The Programmers Brain. Based on her extensive research and experience as an instructor of software developers, Felienne explains the general need for coders to be able to do a variety of cognitive tasks. Although programmers’ brains are not special in comparison to others, they face unique cognitive challenges due to the specialized and thinking-intensive nature of their work. Felienne provides a general framework for thinking about how we think and offers practical examples to help programmers better leverage the power of their brains.
This episode sponsored by LogDNA.
Show Notes
Related Links
From the Show
- https://www.felienne.com/book
- Java (JVM, Checked Exceptions)
- Python (List Comprehensions, Snake casing, PEP8)
- C# (LINQ)
- Dunning Krueger effect
- Positive and Negative Transfer
- Cognitive Load
- Cognitive Restructuring
- Cognitive Dimensions (Transcription)
- Dave Snowden, Cynefin Framework
- Intersectionality
- Two Hard Things in Computer Science
- Github
- Visual Studio Code (VS Code)
- Misconception Catalog from Visual Program Simulation in Introductory Programming Education. PhD Dissertation by Juha Sorva – Page 366 ff
From IEEE
- Developing the Complex Thinking Skills Required in Today’s Global Economy
- Higher Order Software
- Complex Problem Solving as a Construct of Inquiry, Computational Thinking and Mathematical Problem Solving
- Block-oriented programming with tangibles: An engaging way to learn computational thinking skills
- Teaching and Learning of Divergent & Convergent Thinking Skills using DCT
- Systems thinking skills of undergraduate engineering students
- Developing a Procedural Problem-solving-based Framework of Computational Thinking Components
From SE Radio
- 238 – Linda Rising on the Agile Brain
- 200 – Markus Völter on Language Design and Domain Specific Languages
- 433 – Shawn Wildermuth on Diversity and Inclusion in the Workplace – https://www.se-radio.net/2021/01/episode
- 443-shawn-wildermuth-on-inclusivity/
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Jeff Doolittle 00:00:16 Welcome to Software Engineering Radio. I’m your host, Jeff Doolittle. I’m excited to invite Felienne as our guest on the show today. Felienne is associate professor at the Leiden Institute of Advanced Computer Science at Leiden university with a focus on programming education. She also works at the Vrije University of Amsterdam where she teaches prospective computer science teachers. In 2021, Felienne was awarded the Dutch Prize for ICT research. She is the author of The Programmers Brain, a book that helps programmers understand how their brain works and how to use it more effectively. It’s so great to have a fellow host on the show as a guest. Welcome.
Felienne 00:00:53 It’s great to be here, thank you.
Jeff Doolittle 00:00:56 Well, as I said, in your intro, your book is titled The Programmers Brain. Is there something unique about the programmer’s brain?
Felienne 00:01:03 Yeah, I don’t think so. I mean, we’d like to say yes, right? Because it feels so cool to say I have this special brain that’s different from other people’s brains, but actually recently research is actually showing more and more that to be a good programmer you need to know a variety of things or you need to be able to do a variety of cognitive tasks. So, there’s a little bit of math reasoning; there’s a bit of language thinking; there’s also the working memory that you also use if you are looking up directions to your favorite restaurant, or if you’re reading difficult piece of nonfiction. So, it’s not that we have special brains. Maybe we use the different underlying cognitive skills in a unique combination, but it isn’t that our brains are different.
Jeff Doolittle 00:01:43 Well, hopefully that’s not disappointing to our listeners to discover, but I imagine putting a brain that maybe isn’t unique into different contexts than others perhaps lends itself to what you were just saying there, that our brains may be an operating in different ways because of the context and the kinds of problems that we tackle. Is there something to that?
Felienne 00:02:02 Yeah, it’s definitely true that everything you do often you’ll get better at. So, it’s definitely true that if you program a lot — like, if you read lots of Java code — it will get easier and easier for you to read Java code, and there might be a little bit that will transfer — this is a topic we talk about in the book, as well – so, your knowledge of Java might transfer to other programming contexts. Specifically, if you think of C#, for example, if you can really read Java well, probably you could also read C# well. The farther away the programming language is the less likely it is that your knowledge is going to help you. So, reading Python is less likely to be supported by Java. A bit – like, you might recognize a for, but then there a for each. That’s a thing we don’t have in Python and the forms are different. Like, where are all the curly brackets? So, the farther away a context is the less likely your prior knowledge can help you.
Jeff Doolittle 00:02:58 Isn’t it possible in some of those situations that maybe we think the correspondence is greater than it actually turns out to be? For example, you mentioned C# and Java and language transference or correspondence there is one thing, but then you have to deal with the underlying framework. And so, can our brains trick us or maybe help us in trying to distinguish how much we really know versus how much we just think we know in a situation like that?
Felienne 00:03:12 Yeah. So, it’s definitely important to be aware of both negative and positive transfer. So, positive transfer is if your knowledge helps you because you already know something, but you also have negative transfer. So, I used to be a C# developer, and then I became a Python developer, and there was so much negative transfer there. Like, have you seen OO in Python? It’s like, oh, I’m going to make a class. I know how to make a class. Let me just define all the fields on the class. And then Python is like, sure, you can do that in the constructor. But wait, the constructor will crash because I haven’t put the fields on the class. So, this is definitely an example, which I think is recognizable for people also from other programming languages, where you think you know everything, but you end up being wrong. So, I think the most important lesson is, as always, to check your assumptions. So, know that there is sometimes a benefit and sometimes a hindrance of prior knowledge. Don’t assume that things are similar because it isn’t always, and there are so many different programming languages, and as you say, it’s not just about syntax; it’s also about how does the runtime work? Like, .Net and the JVM have some subtle differences, even though the programming languages Java and C# are syntactically almost the same, but then there are underlying ideas like checked exceptions in Java, for example, that are quite different from what you might expect.
Jeff Doolittle 00:04:54 Absolutely. So, you mentioned just a minute ago positive transfer, negative transfer. Are those actual terms in the realm of cognitive science?
Felienne Yes.
Jeff Doolittle Okay. And then this is actually a perfect segue because I was about to ask you what about our brains can make programming difficult? And we just hit on one, and it reminds me of a quote from Richard Feynman that’s one of my favorite quotes ever, and it’s “the first rule is not to be fooled, and you’re the easiest person to fool.” And that sounds like a good summary of kind of what you’re saying there. Does it also relate to cognitive science — say, you know, I think a lot of our listeners might be familiar with Dunning Kruger and I can put a link in the show notes for those who aren’t — and the best summary I can give it is that low competence and experience often leads to high confidence. Is that related somewhat to what you’re describing?
Felienne 00:05:41 Yeah. So, somewhat. I’m not really an expert on that, but it is indeed the case that sometimes people that really know nothing think that they have a very good understanding how everything works, and it could be somewhat true that if you step into a code base in a programming language that you’re unfamiliar with, that you think, ‘oh, this is going to be easy; I learned the other language, so this will be easy, as well.’ If you take that there’s an opportunity to learn, then everything’s fine. But if you take that as an opportunity to correct the other people because you already know how everything works, then you might fall in the trap.
Jeff Doolittle 00:06:14 Right. And also that desire to correct others leads me back to that Feynman quote, where instead of us thinking everybody else is the easiest person to fool, maybe as part of recognizing our human brains is starting and asking, maybe I am the easiest person to fool.
Felienne 00:06:28 Yeah. And that’s definitely what we talk about in a chapter about transfer is just be aware that around every corner there might be another programming concept that is just slightly different from how you learned it earlier.
Jeff Doolittle 00:06:41 Can we train our brains to, rather than settling for the dopamine hit we get off that excitement of, “oh my gosh, this works like I thought it would,” instead sort of prepare ourselves to be excited for what’s next. Like, “oh, I learned this, but now this excites me that maybe there’s something else I don’t know that I can learn,” because that’s something we can improve at, or is it just never going to be that easy?
Felienne 00:07:06 Yeah. It’s likely never going to be this easy. And that also has something to do with how your brain works. So, your brain is always trying to save energy because your brain is an expensive thing in your body. So, where possible your brain is going to rely on your long-term memory rather than on your short-term memory. So, short-term memory is what comes into your brain through your senses, and long-term memory is what you already know. And I think we all know these nice examples of headlines with a typo, right? And then you’re like, how could people be so stupid? How could they not notice that there’s a typo right there? I actually, accidentally, in the first chapter of my book, I put in a typo; and a few people have been emailing me like, “oh there’s a typo there,” but we put it in the typo because it’s likely that many people didn’t notice the typo; we put it into the method called main. So, that’s something you’ve seen so often. So, rather than actually read the individual letters in a main method, you look at the structure of the code and you assume, oh, that’s probably main. And there are like 2000 people who already bought my book, and like ten people will send me an email about the typo. So, I’m just going to assume that many of the other people are, maybe there were two mains, but many of the other people were indeed just fooled by the typo where the long-term memory takes over, and this is because it’s easier for you, it’s way easier and cheaper for your brain to assume, “oh, that’s a main method” or “oh, that’s a for loop” rather than actually reading the code letter by letter, or character by character; that’s slow, and in most cases it isn’t needed because so often your brain actually exactly is correct, right? where your long-term memory tells you, oh, this is what it is. And that is what it is. So, your brain wants to do better matching. Your brain wants to save energy by looking at unfamiliar information and connecting it to things you already know. And that’s what the brain was made for. So, new information overruling prior information that you already know is always going to be hard because it’s expensive for your brain to learn new things. It’s way easier to not learn new things. Sadly.
Jeff Doolittle 00:09:13 Right? Right. So, we’re always going to be working against that. But I think recognizing that alone can perhaps help us, even if we have to have external constraints that are even possibly self-imposed that can remind us about these things about, “Hey, our brain wants to be lazy and it doesn’t want to expend excess energy,” which just makes sense from an evolutionary standpoint, right? It’s conservation of energy. So, our brains are part of the universe, and therefore they are beholden to the laws of the universe. What else about our brains can make programming difficult in general?
Felienne 00:09:45 So, what also makes it difficult to program well, I think, is indeed this interplay between the short-term memory — you have to remember many things, so if you’re reading unfamiliar code you just have to remember the method named, arguments, what are the concrete parameters, what class is this in, what domain am I working on? So, that is known to overload your memory, and we know from cognitive science that your short-term memory can only hold five or six items more or less. So, as soon as you read a method with many arguments, then this is going to be heavy on your brain. And then it isn’t just your short-term memory. So, your short-term memory is for remembering, but you also have your working memory, and your working memory is for thinking. So, in addition to remembering many things, you also have to sometimes calculate, right? So, there’s a pointer and it’s moving in the array. Oh, now it’s at the first element, and then it’s at the last element. So, you also have to puzzle information together, so the fact that those two memory parts — the short-term memory remembering information and familiar information, and also processing and thinking — that that has to happen at the same time, that interaction is something that makes programming really hard. But again, this is also something that makes reading nonfiction really hard. If you’r reading an article about a topic that you’re not so familiar with — like, they found a new type of RNA or something — then you’re doing the same thing. So, we have to remember the name of the scientist and the university, and oh, what exactly is the study that they did? So, in a similar way, piecing information together into working memory is something you do in other contexts also.
Jeff Doolittle 00:11:27 That makes sense. When you describe it that way, it sounds exhausting. And I think that is probably very, in some ways, relieving to our listeners. I know it is to me because, you know, I recall hearing things from other people, including family members, along the lines of “You don’t really work; you just type on a computer all day.” But what you just described is a high energy system within our bodies, and in order to do these tasks with heavy cognitive load actually bears a cost, and it could lead to exhaustion. Is there something scientifically to that?
Felienne 00:12:07 Well, we definitely know that the brain takes lots of energy from your body. So, it is that if you’re doing cognitively demanding work, like reading or writing or whatever, that it needs it, that it takes energy. That’s very true. So, yeah, it’s not weird if you’re exhausted.
Jeff Doolittle 00:12:20 Yeah. That makes sense. I think we’ve hit on some, but maybe more generally, can you describe for us some common intellectual challenges that coders often face? You know, besides fooling ourselves with a model that doesn’t quite match or overlooking a typo, which I’m going to guess you put there on purpose just as a demonstration of how the human brain and the programmer’s brain specifically works, but what other common intellectual challenges are there that we should be aware of as coders?
Felienne 00:12:48 So, I think one challenge specific to programming (because the ones we just described are somewhat generic) is what you just said: cognitive load. So, let me define that for people that might not be too familiar with it and dive deeper as well. The easy description is how hard your brain is working. But in the book, we go a bit deeper into different types of cognitive load. So, there’s firstly intrinsic cognitive load, which you can describe in programmer’s terms like inherent complexity. So, if you are doing binary, for example, yeah. That’s just a hard thing to visualize like, oh, you have to listen to that side or traversing a tree, or also thinking of databases in different parts of the world. And they have to be eventually consistent. So, you have to think of all situations when something goes wrong, or is something outdated or something offline. Those situations are just hard. Like, that’s inherent load, intrinsic cognitive load is what that creates. But there’s also something called extraneous load, and extraneous load is load that is added to the problem that isn’t necessarily part of the problem. And here’s the difficult thing for programming is that what might cause extraneous load for me might not cause extraneous load for you, ok? So, if we have a distributed database system, if this is written in Python, for me that doesn’t give me extra load because I already know Python. But if you’re a Java programmer and you’re helping me work on this distributed system in Python, for you that adds extra extraneous load because you have to read all the weird stuff about OO in Python. If you work together with multiple people in a code base, then what is easy to read for me might be really hard for you to read, or what is easy to read for me now might be hard for myself to read in six months because we also forget things.
Felienne 00:14:51 So, I think that’s the real challenge where you’re looking at an artifact that firstly has an inherent complexity that can be high, that can already cause cognitive loads, but then different people have different prior experiences. And because of that, they experience different cognitive load. Like, if you have to read a poem in Dutch, that’ll be super heavy for your cognitive load because you’ll have to look up every word in a dictionary. You can get there. You can do this, but you have to look up every word in the dictionary. You know, we have these weird words that maybe look like in English word but then they’re not. So, it isn’t that programming is hard in general — well, it is, but then also if you have a team, different team members might experience entirely different cognitive loads. So, something that we’ve described in a book that can actually help with that a bit is the idea of refactoring for cognitive processing, and I’ve started to call this “cognitive refactoring.” So, if I’m new to the Python code base and there’s lots of list comprehensions, and I’m a Java programmer, then with every list comprehension I’m like, ‘oh, what is happening here?’ Like, ‘Oh, this is this, and oh, the If is there?’
Felienne 00:16:04 So, for you, as someone new to that code base, you might just want to refactor a bunch of those list comprehensions temporarily to for loops, just because those are easier for you to process, or you might, if you have this very interconnected code base that other people in the team already familiar with, but you’re new to the team — not necessarily to the programming language but you’re new to the team — and every method calls another method on another class, maybe for you temporarily you might want to inline a bunch of methods so you can get the sense for what is there. Maybe some people are now like screaming at their phone or computer, like, “No, but then you’ll be making the code base worse if you remove them; don’t inline the methods!” Yes, yes, just calm down. This can be temporarily for that person. And the nice thing is that we have the technology to do this. I can be on my own branch of the code, and I can inline a few methods, and I can rewrite a few things so that I gain a better understanding of the code. And I can just be in the branch and do other useful things. I can easily roll it back, but we really have to step away from this idea that a code base can have code quality, because then I can say, “well, Jeff, look at this beautiful Dutch poem. Why don’t you like this? It’s so beautiful and deep.” This is also — of course, to a lesser extent than natural language — but this is the way we’ve been approaching code quality: like there’s one thing, one code base, that will be ideal for everyone. And of course there’s some stuff that’s great for everyone. Like calling your variables, A,B,C, and X12. That’s just helpful for no one. But some constructs can be useful for you as an expert in the domain, in the programming language, in the code base, but it can be really harmful for beginners. So, this idea of cognitive refactoring is you take the code and you make it closer to what you already know, and then it’s easier for you to process.
Jeff Doolittle 00:17:58 And I think, maybe for some people in our industry, that can be difficult because oftentimes the sense is given that coders should just code. And I tell coders and developers that I mentor, I say, if you’re actually coding the code that’s going to be “the code” — okay, you might be fiddling around or things like you’re saying, but if you’re spending more than 20% of your time doing that, you’re probably doing something wrong because 80% of your time should be improving your craft. It should be doing things like you’re describing: moving the code around, seeing how it works, knowing you’re going to throw this branch away, or interacting with product owners, interacting with project managers, interacting with colleagues, making sure you have the right solution before you write the code or know that you’re just exploring the space in order to see what code you might write.
Felienne 00:18:44 Yeah, that’s so interesting, because we actually describe a little bit about that in the book as well, that if we say “programming” we probably mean a large variety of different tasks. So, in the book we describe a number of different activities. Like, sometimes you are exploring — like, programming in an exploratory fashion. This is: I want to have a new feature, but I don’t know how to do it. And maybe I sketch out bits on paper, but I also go to my IDE and I sketch there. I create a class, and I create some methods, and I can write a few tests. Like, this is what I want. And this is very intangible, right? You just want to see how it feels. I was just working on our programming language and we have this two-step model. And when I was first writing that, I didn’t know if I wanted to have a two, like if I wanted to do parsing and then transpiling, or if I wanted to do the whole way in one go, I didn’t know. I knew what I wanted, more or less, but I was like, I just want to try out, like, what happens? What will the interfaces be if I try a two-step model versus a one-step model? That’s exploratory programming. And that might be in a branch that you throw away, which is a very different type of programming activity from a model that we described, that cognitive dimensions calls “transcription.” So, transcription is: I have a plan. I exactly know what I’m doing either because this task is really easy or because I charted it out on paper or someone did that for me. And the only thing I’m going to do is I’m going to go into the code base. I imagine the code can be done in one hour. It’s like, do you see the error message? Yeah, I know what’s up. You go to the right place in the code. You go there, you fix the bug and you’re done.
Felienne 00:20:25 You see how different those activities are. And both are programming, of course. Even, they’re both creation. I’m not even talking about reading code, which is yet another different activity, but those two activities place so many different constraints on your brain, on your workspace — like, do I need a whiteboard? Do I need a keyboard? — but also on your programming or your IDE. So, if you distinguish these different activities, as we describe them in the book, then you also get a better sense of what am I doing? And you can have what I hope, if multiple people in the team read the book, then you get also a shared vocabulary. So, you talk about a new feature and then someone might say, okay, but are you going to implement this in the transcription way? Like do you know where you’re going, or do you want to explore this? Maybe we can explore it together. So, if we say programming really mean a bunch of very, very different activities that are cognitively very different from each other.
Jeff Doolittle 00:21:21 There’s a wonderful thinking tool that — at least that’s what I would call it — called the cynefin framework. That’s a Welsh word, and I don’t recall what it means, but I’ll put a link in the show notes to that because how what you’re saying maps to that is the cynefin framework lays out these different domains, and the domains one is an “ordered domain.” And so, when you say transcription, I think of, ‘oh, well these are the known knowns and we do best practice,’ but then there’s the complicated where it’s, ‘well, these are the known unknowns,’ and maybe there’s good practice. And then you get into the complex domain, and now you’re into the unknown unknowns. And now you’re trying new things, you’re exploring, you’re trying to figure it out. And I imagine that kind of framework can map in some ways to what you’re describing and maybe give us one of those thinking tools that we need to help us discover how to attack some of these tasks.
Felienne 00:22:10 Yeah, yeah. That’s definitely true that for all the different tasks you also need different strategies to approach them.
Jeff Doolittle 00:22:16 Absolutely. So, in general, there’s a lot of foundational concepts in this book, and we’ve touched on a few: cognitive load, short-term and long-term memory. And I think an underlying one that we haven’t really directly tackled yet, but you address it a lot in the book is this idea of confusion. Before you were mentioning different people might have different extrinsic versus I think it was intrinsic and extraneous. That makes me think of when we talk about human freedom and the things that have held some people back that we’re trying to free them from, it almost sounds like an intersectionality of your brain, right? Intersectionality in sociology is the idea that somebody who has historically been oppressed in one way may have other factors that cause them to even have multiplicative effects on things that have made life more difficult for them in ways, and given them challenges that others don’t face, in an expanding level, right? Not just additive, but multiplicative. Is that true here as well? Does that same kind of concept apply that some of these things, we have one and then we have another, and it’s not just additive in it’s difficulty, but this is even like expanding the complexity and the difficulty of what we’re dealing with?
Felienne 00:23:28 I really like the angle that you take here. I think this is very true. So, what we describe in the book is that, we’ve talked about these three memory systems: long-term, short-term, and working memory. And in the introduction of the book I described that those give rise to different forms of confusion. So, long-term memory confusion is if you don’t know something; there’s a key word and you don’t know it — something like [inaudible] in Python; you’re like, why is the is at the end? What does this do? That’s confusing that is solvable with more information, whereas there’s confusion of the short-term memory, where you have to remember many things and you’re like, oh, I have to hold everything in my head. This is the moment where if someone like your spouse comes in and they’re like, “Hey, do you want to go for a coffee?” you’re like fire out of your eyes.
Jeff Doolittle Not now, not now!
Felienne 00:24:17 That’s also confusing because of a lapse in concentration. But you see that’s not confusion that you can solve with extra information. This is confusion that you can solve with training, best practices, etc. And then there’s the working memory where your confusion is, like, what’s what goes where? And maybe you can finish all the syntactic elements, maybe you can remember everything, but you have to piece everything together. And that’s yet another form of confusion. And what we see with people that come into programming or come into a code base or a programming language is indeed it adds up. So, I go to code in that I’ve never done before. Now, I don’t know the code sense, I don’t know the syntax. I might not be aware of some of the constructs, like the fundamentals of the programming language. And then imagine I’m doing an iPhone app, and this is a domain I’ve never done before. I don’t know the names of the frameworks. I really have no clue what’s going on. So, indeed if you just have one confusion, one dimension is fixed. Like, you know all the syntax and it’s not so terrible if your working memory is thinking really hard. But then if it’s and, and, and, indeed then it isn’t just a bit of cognitive load here and a bit of cognitive load there; then it’s just ‘arrgh’ and you get stuck. And the sad thing is of course that for some people getting stuck, I mean, confused leads to in young people and people that are learning leads to ‘oh, shoot, program’s really hard. Maybe I don’t want to be a programmer.’ And it’s sad if we lose people just because they don’t know that we can solve that confusion and that it is indeed, it’s not a terrible situation. It’s just three things together, and some others maybe as well, that together form this, this horrible confusion, but these are individual things that can be solved in different ways.
Jeff Doolittle 00:26:01 Your passion is evident there. And I think it’s wonderful that you’re an educator — and not just college students or university students, from what I understand, but also for high school students, is that correct?
Felienne 00:26:10 Yeah, that’s correct. I teach at two universities and also at one high school.
Jeff Doolittle 00:26:15 And what a great opportunity for you to help those students encounter what you just described and tell them it’s going to be okay. It doesn’t mean that your brain doesn’t function or that you’re less than, or whatever it might be. You know, especially in an industry that at times has, it may be more than at times, but has had situations where people who don’t, quote unquote, get it right away sometimes are downplayed or not included or pushed aside.
Felienne 00:26:43 That’s very true. So, there’s this video of me of a talk that I did at Strange Loop 2019 where I had some screenshots from “programming for children” books, and they’re so much filled with like, “yay, pain is great.” There’s this screenshot where it says, like, “if you learn programming, this will be confusing and it’s going to be frustrating. And sometimes you will fail.” This is for ten-year-olds, right? It’s going to be frustrating. You will fail. And you just learn by trying out things, and trying out things isn’t terrible. But if you have no idea what’s going on, then what can you try? And I think that’s one of the biggest things that I’ve really learned from teaching in the high school, more than from teaching in a university, mainly because high school students, they tell you if they’re confused; they tell you if something is unreasonable, whereas university students are more like, oh, this is hard. Well, they’ve already learned it’s about them. They’re like, oh, well maybe I’m not that smart. But then your 12-year-old will just say, I don’t understand this. What is this? This is unreasonable. One student said to me, about a syntactic element in Python, she said “this is unreasonable.” And this was actually about list comprehensions, where in the for loop at the end of the for loop in Python, it needs to end with with a colon and that’s mandatory. So, I trained them “colons, colons, colons,” so they’re like, “Oh, for; don’t forget the colon,” and they learned that. And then I teach them list comprehensions, which are really nice to make lists and to filter data, but then it starts with a for and it doesn’t end with a colon, and she’s like, this is a reasonable. And I was like, “You’re right, sister. This is unreasonable.” Right? Why is there a colon there and not here?
Felienne 00:28:28 So, that’s, I think the thing that you take away that if you’re an expert — and senior programmers might recognize this if they’re onboarding more junior people. I had never thought about that because I didn’t even see the colon; I didn’t see the brackets. I just see the concept. But if you’re learning, yeah, then it is a bit unreasonable that there are these syntactic differences. Like, third graders — that’s 14, 15-year-olds in the Netherlands — first we did Python and we’re doing SQL. And they have to integrate SQL queries into a Python program. And they’re all like, well, why is it different now? Why is this capital letters? It’s all so weird. And that’s, I think so wonderful because you forget how hard it is if you’re old, because it’s so long ago.
Jeff Doolittle 00:29:15 It’s true. And that’s true in almost every every domain. I mean, as a musician, I have to remind myself that people who haven’t played an instrument for as long, it’s going to be hard for them learning. And I think that’s one of the great reasons to teach. You know, you do this, you know, you professionally teach, but for us as software developers and engineers to be teaching as well and giving people that freedom and, you know, ironically, the teacher always learns more than the students. So, one of the reasons that you’ve gotten where you are Felienne is because you are learning more than your students are.
Felienne That’s true.
Jeff Doolittle 00:30:20 I want to go back to something you said before, because you’re not just giving us the programmer’s brain. You’re giving us a life lesson when you say you’re going to fail and it’s going to be okay, and you’re going to learn, and you’re going to try again, I think that message just needs to be given loud and clear, not just to kids, but as you mentioned, as we get into college and later into life, there’s so much freedom in that. It’s, I’m not going to be perfect. I’m not going to have all the answers. I’m going to need others. I’m going to need their knowledge and experience, and it’s okay. Would you say that’s a mindset that you’ve discovered is helpful or even maybe even, I don’t know if it’s required, but can sort of set our programmers brains free to be more productive?
Felienne 00:31:02 Well, I think the biggest thing that you can do is, so I wouldn’t say to lean into the struggle too much, because if you’re struggling something might be wrong. So, I would rather say, and this also what I say to students, both at the high school level and at a university level, if you’re confused, don’t be stressed and upset, but do try to learn something there. So, what we often see in programming culture is that we celebrate this confusion to the point where people are just confused all the time, and they’re not fixing it. So, something, for example, that we really celebrate in programming culture is not knowing syntax. It’s like, ‘oh, I don’t know that; I can just Google the syntax.’ And this is true, but is it really effective? Wouldn’t it be? And this is a rhetorical question, but wouldn’t it be way more effective if you spend two minutes every day for one month to memorize the syntax? This is going to save you so much time. So, if you had gone to a programming concept, what is this? And you would look it up. Why look it up every time? You look it up once and memorize it. Because the sad thing about our brain is actually that if you look it up, instead of trying to remember it, then your brain will never learn. Your brain — this is really interesting — your brain actually strengthens if you’re trying to remember something. Even if you don’t know it and you have to look it up later, just trying to remember something is a really strong way to strengthen your memory. This is called retrieval practice, trying to remember something. So, if you keep struggling with something, then you can say, oh, JavaScript is stupid because I have to each time Google if it’s set two equal signs or three equal signs, I can’t remember this because JavaScript is terrible.
Felienne 00:32:52 You can also say, okay, let me take a piece of paper. I write down once what is the difference between these concepts? And if you practice with the code or the piece of paper just a few minutes every day for awhile, you can actually learn. So, this is more, I think, my message to kids rather than programmers, that if you’re confused, do something about it. And if it’s confusion at the long-term memory level, because you don’t know something, you don’t remember it, you can use flashcards this technique to practice your long-term memory. If it is your working memory, then try equivalent refactoring the code in such a form that it’s a bit easier. Or we ask lots of other techniques in the book as well. Like use some specific diagrams who can help support your memory. So, yeah, of course you’re going to be confused, but if I’m sometimes confused, if I read the newspaper, as I said, if it’s about the topic I don’t really know. So, it’s fine. If you’re confused, it’s nothing to be scared about, but it’s also not something you should accept as a given. There are things you can do to minimize your current and future confusion.
Jeff Doolittle 00:33:56 Yeah. It’s when you’ve seen that same stack overflow article three times in the last month that you should probably stop and say, maybe I should work on memorizing this.
Felienne 00:34:05 Yeah. Or the most terrible form of that is actually if you Google something and then you go to your own blog or your own research paper. I wrote this, how can I not remember it?
Felienne 00:34:19 You don’t always have the mind space to reflect, but I really try to reflect more and more if I’ve forgotten something that I wrote by myself. Because some things also, they stay in your memory when you use them often. And if this is a technique you haven’t thought about for a long time, this is when your brain is trying to be helpful. It sort of drifts away and things you have more recently thought about many times are a little bit more likely to actually show up in your memory or things like your spouse’s name. Even if you don’t use it a lot, it’s just always there because it’s really important to you. So, you have to reflect on like, why did I forget my own stack overflow posts or blog post? Haven’t I thought about this, or worked on this technique for a while. Why is that? And especially if it then turns out to be useful a bunch of times in a row, then it’s definitely something you want to explore and work on.
Jeff Doolittle 00:35:08 Well, let’s move on to another topic in the book, because I think this is going to draw a lot of listener interest once they grab a copy of your book: speed reading for code. I mean, that just sounds like the magical tool you need to solve all your problems with confusion and getting things done quickly. So, let’s start with, I mean, I think it’s kind of obvious, but as someone who’s studied in this area, why is it helpful to be able to read code quickly? Like I said, it may seem obvious, but maybe there’s to the cognitive science behind this.
Felienne 00:35:39 Yeah. So, there’s a lot of cognitive science behind it of why is this useful, right? It says in the book that we spend, we professional developers, spend about 60% of our time on actually reading code. So, reading code is a skill you do a lot, and you do this in a variety of ways, right? Sometimes it is reading your own code because you haven’t worked on it for a while, or reading a library on GitHub that you’re like, oh, maybe I want to use this in my project, let me just see more or less what’s here. So, there are different forms of reading code, but it’s always really hard to read code. So, if you get better at it, then yeah, you’ll be a more effective programmer because you can read more code at a glance.
Jeff Doolittle 00:36:24 And so you say we spend 60% of our time reading code when we’re in the code. And that makes sense. You have to understand what you’re looking at before you can work on it. Or at least we all hope that you attempt to do that before you make changes to the code base. You mentioned before, and this kind of triggered something in my mind that, it’s when you go to do a git blame and you discover that it was you. And again, it’s that well, that code was out of sight out of mind that moved on. So, to some extent, it reminds me of what I call the Homer Simpson rule, which is the don’t hate your future self rule. There’s Homer Simpson with a bottle of vodka and a jar of mayonnaise. And Marge basically says Homer, I’m not sure that’s such a good idea. I can’t do a Marge impression. And Homer says, oh, that’s no problem. That’s a problem for future Homer. Boy, I don’t envy that guy. And he proceeds to consume the vodka and mayonnaise. And you can imagine that probably didn’t go so well for him. So, let’s talk about, I mean, speed reading obviously is important, but I imagine that’s somewhat related as well to readability in code, meaning is it easier to speed read code that is more readable? And then, how do we make that code more readable for ourselves, our future selves, and also for other people who may have to interact with or maintain this code in the long term?
Felienne 00:37:35 Yeah, that’s a great question. So, I’m going to try to answer two questions at once. Like how do we speed read and also how do we write code that is easier to speed read because it’s more “speed readable”? It sort of comes down to the same thing. And we have to go back to that pattern matching that I talked about earlier, and that we talk about in the book in more detail. And this pattern matching, we usually call that in cognitive terms, “chunking.” So, chunking is if you look at information and instead of looking at individual elements, you process the whole thing at once. So, if you read English, then you aren’t, if you’re proficient adults, you aren’t going to do like “T-H-E, the…” You just immediately see that word at once. So, there’s lots of code structures, of course, that also lends itself to being chunked, and an interesting thing that we talk about in a lot of depth in the book is that experts — people that are expert in something — really use their long-term memory very, very extensively. So, we do these experiments in which we have beginners and experts remember code — maybe some of you that follow me on Twitter have seen where we were recruiting subjects. The study was, we give you Java, and you have to memorize it. And what you see in those studies — not just in programming, but also in board games and natural language — is that experts tend to remember a lot more code in a short period of time than beginners. And this isn’t because experts have extensive memory; it’s because you break up the information in small pieces. So, if you have to remember five for loops, then you can probably do that because you’re not going to remember for i in range zero, coma, five, closing bracket, colon; you just think, oh, well look at the iterators: i it goes from zero to five and it prints i. Okay, next one. Oh, here it is. It goes from zero to ten. Oh, it prints three first. You can easily process the information not because you are a good information processor, but because you’ve seen for loops many, many times. So, the trick in speed reading is to learn a large vocabulary of different chunks. So, practice — and I have no great answer like, oh, this is going to be free, right? Oh, I’m going to be a great speed reader tomorrow without any work. No. Sad. You have to put the work in. But if you have a large variety of different chunks in your long-term memory, then you can read code more easily. And you can practice this in yourself also by doing this exercise of trying to remember code, to just take random snippets from your code base, you put your hand on it and try to reproduce the code. What you can reproduce, the biggest chunks will be from your long-term memory because you can easily remember five lines at once if it is a for loop or if it is an API call that you use very often, you’re not going to think “um…” you’re just going to remember the whole thing at once. So, if you have this large vocabulary of chunks, then it will be a lot easier for you to quickly read code because you can just read the whole block at once. So, that’s my tip for quickly reading code. Going back to your other question, like, how do you read code that’s confusing to be chunked? Once you are aware of this idea of chunkable code, you can use that in code. So, you know that something like a for loop, a while loop, a null check — is this variable null, if so, access it; is this connection open, if so query it — those are recognizable blocks. So, you want to use those blocks and put them, for example, a white space above them so we can see this is a block of code where I think this is what someone will use. We also talk about another technique in the book called using beacons, and beacons are things that make people think of a certain chunk. So, the word for, for example, in a for loop can be a beacon. If you see the word for, you know what’s coming, or it’s something like a null check, you see if it’s null, you’re like “Oh, now I know.” So, you can deliberately leave beacons — comments, by the way, can also serve as beacons, as recognizable warning signs, like “warning a recognizable chunk is coming.” So, if you have this vocabulary, you can use it because it makes you read code quicker.
Felienne 00:42:01 And also you can use it so that you can structure your code into recognizable blocks. And it can also be the case that in a team — we talk about teamwork also in the book — in the team that some people use one form of a chunk because some people always use a JavaScript edit that they just explicitly say, oh, if this is null then do this. And other people use this two ampersands where it’s like, “oh, if this isn’t the null, then I can access the other side of the and sign.” Those are chunks that are different forms for the same thing. So, it’s not great for your brain if it alternates, if the whole code base is filled with this style and that style. And I think we talk a lot about code style, and systematic code style as a form of layout. So, we all want to have the same layout, and many IDEs also fix this for us.
Felienne 00:42:52 So, there’s many other dimensions that we talk about in the book as well, like these synonyms. So, to say in code, if people use different synonyms, then they can all abide to the same style, but then it’s still very hard for your brain where you have to switch with, “oh, this is an explicit null check; oh, this is the implicit version.” It’s just, extraneous load. Also, in terms of variable names, right? We talk about Campbell case versus snake case. It’s nice, of course, if you use that case and it’s all the same, but there are other things, and what’s also in the book, is like if you’re calculating the maximum interest rates, is that going to be interest maximum, maximum interest, max of interest? And we often see that in code bases these different styles — and there’s extensive research, not my research, but I’m super excited that we talk about in the book called name molds. So, what molds does your name fit in? And you see in the code base, if you have maximum interest, interest max, max of interests, if you have all these different forms, you can say, oh, you know, this is bad because it’s all the same but we use Campbell case or snake case on the variables and Campbell case on the variables. So, we have the same style, but that is surface style. If you go to the cognitive level, you also want to have it easy for your brain to chunk a variable name. And if the information is sometimes at the beginning and sometimes is at the end, you can imagine that impedes my speed reading because then I’m reading both from the beginning and the end. And so, there are all these things that we talk about that it’s just going to make code easier for your brain to process. But again, as one of the reviewers of the book said, yes, but this is hard because then me and my teammates have to make a decision on the how to structure names. Yes friend, I’m sorry. I have no better news for you.
Jeff Doolittle 00:44:39 It’s the second law of thermodynamics: There’s no value without sweat, so you’re going to have to work for it, and that’s just the way the universe works. You know, as you’re talking, I have this thought in my mind and you know, listeners can’t see us. I wish they could see, you know, when you did the head explode sound before your hands doing the actual motion — full disclosure, I have no vested interest in GitHub whatsoever, other than I love it as a tool, as so many of us do — but you know, as you’re describing this, I recall early days of trying to learn linq in C# and link stands for language integrated query. And it’s basically something that Microsoft created to allow you to define things like a SQL query, but using C#. And it’s not just for SQL queries, but this is one example. You know, you mentioned before your students trying to learn SQL while they’re trying to learn Python and they’re complaining about the differences and this is crazy. And one of the really helpful things for me in those days were refactoring tools that allowed me to shift because linq has two views to it. There’s one that looks more like SQL — it’s not exactly SQL, but it’s closer — and then there’s another one that uses method chaining, where you do a method, say dot where, and then you put in a where clause and then you say .select. And then you put in your select clause. And I preferred the method chaining method, but I couldn’t comprehend it as well at first. And so now back to what I was saying about GitHub or other tools online, and it seems to me, there’s a space for tools that would let you look at the code in a view that is more conducive to the way your brain works personally, while allowing the team to still standardize on something that may not be your personal preference. And then instead of forcing you to adopt the team’s convention, the tool, the source code host, the IDE could give you the, your view to reduce your cognitive load while reading. But then if you have to modify it or even convert it for you when you’re done. I don’t know. It seems to me there’s a space for that. So, maybe GitHub or vs code can get on that.
Felienne 00:46:30 Yeah. That would be great. I thought about this idea, and I thought about a demo actually, but then I ended up implementing other things. If you’re listening, people that make programming tools, this would be tremendously useful. And not just for this scenario of onboarding someone so they can look at their version of the code, but also earlier in the show, we talked different activities. So, if I’m reading code, I probably want to have small methods that are very, like, everything is abstracted because that makes organization easier. But then if I’m working on code, if I’m adding a new feature, maybe I do want to inline everything for now because I don’t want to, like, I’m debugging and I have this web front end, and then I have these three different classes processing. So, I’m stepping with my debugger because I’m hunting for a bug and then it just halts, right? Oh now I’m at the front end, So, okay, now I’m in the HTTP requests, okay. They come in correctly. Okay. Now I’m going to go to that class. Oh now It’s pre-processed; oh, now it processed. So, now we go to the transpiler now. If I’m fixing something, I don’t want to hop through three files every time. Think about your brain. Every time you go to a new file, your working memory is like “what, what?” Your short-term memory is like “oops, I forgot everything of the other file.” If this is what you want to read, of course Felienne, here is a fresh blank slate to read from. Just for the activity of debugging, the activity of adding, fixing a feature, you can say “oh, by charm” — and doesn’t have to be a given feature, could be an IDE feature as well — Whoever is managing my code, inline everything. I don’t care that I want this in three. . .
Jeff Doolittle 00:48:03 Collapse the stack and give me everything top to bottom in a linear view. And if you wrote code that way, that would be a procedural nightmare because it’s not maintainable.
Felienne 00:48:11 Your colleagues would stab you.
Jeff Doolittle 00:48:14 Yeah. That’s a great way of, I think in general, we’re exploring this space, which I know you spend a lot of time doing as a researcher, but I guess the thought occurs to me is this, they used to joke that programming C was basically just having an argument with the compiler, and it still feels that way sometimes. And what I just felt like you were describing was, you know, debugging is you having an argument with your debugging tools, and who of us has an accidentally, you know, told it to run when we meant to say step over step into, and then, oh, and then you got to restart a debugging session,
Felienne 00:48:42 And not just restart your debugging session from your compiler right or your IDE, but also from your brain, because this is the working memory, right? I’ve made my model of, “okay, so this is what happens.” Oh, why is this value of zero? This should never possibly be zero. And then we talk about mental models in the book as well. You build your mental model of how everything is working and then indeed accidentally you hit step over instead of step into. And then it goes to the next line. And then your value isn’t — no, oh! Now it is 12, like it’s supposed to be
Jeff Doolittle But why?!
Felienne 00:49:19 And it should be somewhere in between. Talking as someone that was born in the eighties IDEs nowadays are amazing, right? Some IDEs will let you — I still think this is mind-blowing — will let you actually go back in time. You take the print point, you shift it back. I know how this works technically, but it still blows my mind that this is possible. Even if it is possible from an IDE perspective, from a cognitive perspective, this isn’t free because you were there and you’re like, oh crap, I have to go back. And then your brain is thinking about where do I put the break points rather than about filling a mental code. So, it would be cool if it could just give me a slice of code. So, a slice is all the code that is related to the line that I’m looking at. So, you could say, give me the slice of this code, which is everything in the code base that relates to this bug. How cool would that be, and so much more effective, if someone would build this for us?
Jeff Doolittle 00:50:19 It would be amazing. As you’re saying this, I’m even visualizing the experience of being able to still see the layers of the stack, and the methods and the classes — assuming that what kind of language you’re in — but having this sort of. . .
Felienne 00:50:31 There was this really cool tool a while back (and by a while, I think, I mean a decade or something), it was called Code Bubbles. And this is an alternative resource IDE that lets you do something like that. So, instead of looking at classes as files, you could make bubbles; you’d have to place them yourself, but you could place bubbles. So, you’d have one method and then it calls the next bubble next to it. So, rather than going to a different tab in your IDE, it would have the bubble next to it. And then the next bubble. So, you could make this cool stacked visual. Maybe we could put it in the show notes if it’s still like, I don’t know what happened to it — I know it’s definitely not mainstream. All my friends used Visual Studio to code and not Code Bubble. So, I think they stopped working on it, or it didn’t catch on.
Jeff Doolittle 00:51:18 Yeah. And then even layers of, “give me full procedural,” and I don’t want any of that other stuff. And then I want to add a little bit of that.
Felienne 00:51:24 Hold the functions; I don’t care about what goes where. I just want to see the stack trace.
Jeff Doolittle 00:51:28 This speaks to, you know, you’ve talked a lot about us humans as pattern matchers, and that absolutely is what we are — not only, of course, but that’s part of what we are — and we’re also toolmakers. And so, now that’s kind of what we’re exploring here is how can we make our tools work for us? And as advanced as IDEs are right now, to improve them to another layer, this would be great to see toolmakers start to explore a space like this, where we can have multi-perspectival views over code, different views for different reasons. I mean, yeah, we have a debug window and we have a stack trace and a watch and a locals and these things, but you’re still jumping from file to file, method to method. And that adds cognitive load. Does it not?
Felienne 00:52:11 Definitely. That adds cognitive load, definitely. So, a little bit of cognitive load, a little bit of your working memory is inevitably going to be spent on remembering where you came from — like what method you went through — and because we are pattern matchers, your long-term memory is always in the background, like you have an angel on your shoulder, always trying to be helpful — so, you’re reading the name of a method, like it’s maybe ‘find customer,’ right? Your long-term memory is like, ‘oh, they want to find customers,’ Finding is a synonym for searching, customers, database. So, it’s trying to throw all this information at you that’s relevant. And this is helpful all the time, right? This is why we have a compilation because you say something and I’m like, “oh, but that makes me think of. . .” So this is very, very useful, but that is also crowding your working memory. So, if you have to see if true and class names and function names that aren’t so relevant for your current task, your long-term memory is trying to be helpful and you have to suppress it. This all goes subconsciously, but sometimes you have to literally say to yourself “no, no, no, stay on task. I have to think of what am I doing.” So, if you can remove all the fluff that isn’t necessary for the current task, then yes, it’s likely to make us more effective. If people are actually going to implement this, I can run a user study. So, if you actually want to know if this is working, I can do some observation studies.
Jeff Doolittle 00:53:36 You heard it here, everyone who is involved with building developer tools, we want not a stack trace; we want to see the linear, procedural, the stack as code, and be able to debug it and have it help us modify that code. So, please get on that. And we will thank you for that. And you can contact Felienne if you want to have her include that as part of her research. This would be wonderful. Here we are solving the world’s problems.
Felienne 00:54:03 But then again, until this exists, there are things you can do yourself, right? Of course, it would be very cumbersome to put everything inline. But as a technique, of course, this is something: you can inline a bunch of methods. So, I hope what people take away from this, apart from our crazy ideas for IDEs, that they also take away that sometimes it’s okay to make code worse. So, I really love this focus that as a community we’ve been having on craftspersonship — like, we want to make code better, we want to hone our craft, we want to make code in a perfect state. We want to have short methods, short parameter lists. I stand by all this, so don’t go tweet that “Felienne Hermanns hates readable code.” But it has to be useful. It has to serve its purpose, and sometimes it can be totally okay to inline a bunch of methods, for now, if you feel that’s supporting your working memory. If you are in this state where continuously you’re hopping between files or between methods, because there is a feature that is in both of those methods — it might be a signed that maybe those methods should be one, because why are you hopping? — but also, it is fine for now to just put it in the state that you wouldn’t commit to help it support your working memory. Then that’s, as I said, this is what we call in the book a “cognitive refactoring.” It’s okay. Don’t worry about your teammate saying “oh, but that’s not a proper form.” It’s just temporary to help you support.
Jeff Doolittle 00:55:28 Absolutely. Let’s make sure we haven’t missed — one of the topics that comes up often in your book, and I want to make sure we haven’t missed any — bugs in our thinking. I think we’ve hit on a few, but maybe highlight them a little more obviously, these that we’ve discussed before bugs in our thinking and any we’ve missed that you want to make sure that we cover as well.
Felienne 00:55:47 Oh, that’s a great question. So, there are lots of details. Bugs in our thinking, which in cognitive terms are called misconceptions. So, misconceptions are not if you’re wrong but you’re unsure if you’re wrong, but rather that you are wrong and you also are sure you are right. And that’s the most terrible form of being wrong. So, in cognitive science we talk about misconceptions — for example, if you explain something to a child a bunch of times, and still they have the wrong idea about something. I cite this in the book as well, there’s a really nice PhD thesis by someone called Juha Sorva, and he wrote a PhD thesis that lists 176 programming misconceptions, and this thesis is available on the internet. So, that isn’t all the ways, but many, many, many different ways in which people can be wrong about programming. So, I could give like 50 examples, but the most important thing I think we did talk about is this often happens if you transfer.
Felienne 00:56:50 So, I’m just going to assume that everyone that’s a professional Java programmer, probably they don’t have Java misconceptions; probably they know how stuff works, but then going to another language is where misconceptions happen, and sometimes also if you go to a different domain. So, if at first you work in finance and then you go work in insurance, many words are the same –like, portfolio, for example — but that really might mean something very different in trading than it does in insurance. An insurance portfolio is different from a stock portfolio. So, that is also a situation if you were transferred to a new domain where you might think, oh, I know portfolio, and then it’s slightly different. It isn’t of course something entirely different, and that’s where the trick is: because it’s somewhat similar — it’s a collection of things — you assume it will be the same, and that’s where misconceptions happen. So, they’re very related also to negative and positive transfer that we talked about earlier in the book.
Jeff Doolittle 00:57:46 Absolutely. And we’ll put a link to that PhD thesis that you mentioned in the show notes for listeners. I imagine you probably referenced it in the book as well.
Felienne 00:57:53 Actually we take out a few misconceptions, like for example, a famous example that happens if kids learn to program is that they think that a variable can never be changed. And then you’re like, that is so weird because it’s literally called a variable. Why would you think that? But then this often happens with kids that have extensive experience in math because in math, a variable isn’t variable, right? It is variable in the sense that in a proof you can define it at will, but it never changes. You don’t have a mathematical proof where you say at the top X is 12 and then in the middle of the proof you say haha, X is 17, so people who come from a heavy math background, they come into programming and they read something that is X equals X plus one, and they’re like, well, that’s false because there’s an X and it cannot be equal to itself plus one; nothing is equal to itself plus one, and then this makes no sense.
Jeff Doolittle 00:58:50 Yes. Whoever decided equal was the assignment operator, I kind of want to say couldn’t we have had a different assignment operator?
Felienne We should have a different assignment operator.
Jeff Doolittle It’s too late now. It’s too late. Well, I don’t know, maybe it’s not, but . . .
Felienne 00:59:03 Well, you can go make your own programming language, but that’s a typical example, and you also see the role of transfer, right? No baby is born with an intuition for what the equal sign means. First, we put it in, and then later we say, oh, haha, now it’s different. Different subject. And sometimes this is very tricky for high schoolers. Also for university students, they have algebra where the equal sign is something entirely different, and also like functions. We have functions in math are always immutable. They take in something and they return a value. So, they’re doing algebra at 9:00 AM and then the next hour, I’m like, “Hey, I’m defining a function in Python,” and I’m just assigning a value to this global variable because I’m the king of the universe. So, you see that this continuous transfer between topics with slightly different interpretations. And this of course that isn’t just with university students; also in the code base, your front end and your back end, they might have different programming languages.
Felienne 01:00:04 They might have slightly different versions sometimes in code bases, especially if they live very long and there was a change in definition. So, initially we called something, we called it the parser. And then later on, we split this into two different functions and then, well, there’s also called the parser or so now we have the parser and the parser. And it’s not great, and we all know it’s not perfect, but they just ended up that way. And like with the assignment operator, everyone knows now that that’s a bit of a weird API call, but that’s how we do it. And then yeah, newer places in the code base, they might have a slightly different convention because new people come in and they’re like, what is this? We’re going to do it properly. And then you switch between code bases or between methods or classes, and stuff is subtly different. It’s just a little bit different. This is where bugs are conceived, right? Because you think “I know what this function does. I know what this concept does.” And it’s, you’re almost right, but not entirely.
Jeff Doolittle 01:01:02 And almost right can be very dangerous.
Felienne 01:01:05 And this is the interaction of positive and negative transfer, right? Because in many places you’re right, so this transfer gives you the confidence that this next thing will also be true. And then that’s where it’s not.
Jeff Doolittle 01:01:15 Well, and that’s great, because that comes full circle to what we started with and to kind of sum up that thought, we’ve explored humans as pattern matchers. We’ve also explored humans as toolmakers. (And again, toolmakers, you know, please do some of the things we talked about in this episode.) But now it occurs to me as well that humans are storytellers. And that seems to be a big aspect of this, but I really appreciate how you connected it with usefulness. And I think in all three of those areas, that’s something that we ought to use as an evaluative tool for how well is our programmer’s brain serving us in those three areas of pattern matching, toolmaking, and storytelling: is this useful?
Jeff Doolittle 01:01:54 And with that, I want to go to the hardest thing in computer science, which of course those of us who know — and I’ll put a link to it in the show notes — but basically there’s only two hard things left in computer science: cache invalidation, naming things, and off-by-one problems. So, let’s talk about naming things. What makes a good name? Before, you mentioned max of interest or interest max. And of course, I’m thinking in my mind, somebody’s going to want to call it max int, which would just be sadly hilarious and painful. So, let’s end there. What makes a good name? And then we’ll wrap up the show after we kind of explore this topic.
Felienne 01:02:29 In the book we describe different perspectives. So, there are different perspectives; there’s tension. So, you want to have a name that is descriptive. That clearly explains what it’s doing, which can be at odds with you want to have a name that is short, because the shorter the name, the quicker it is read and the easier it is to parse and to quickly process. Longer names just take more time, but shorter names, if they’re very short, also take a longer time to read through. There’s really nice research that we cite in the book as well, and the title of the paper is “Shorter Variable Names Take Longer to Comprehend.” Leaves nothing to the imagination, right? So, shorter is not better, but very long isn’t great either. So, this is something sadly — I mean, we we are all engineers and we all want to have something like, give us the magical formula. So, it is the name of the concept divided by 17 plus four, and that’s the ideal length, but there’s no such thing as “ideal.” So, this will always be a trade-off. And what we talked about before, I think, that’s one of the most interesting works that I cover in the book is this idea of name molds. That if you put names in the same systematic form that really supports your pattern-matching brain. So, you want to have this first there’s discussion or the decision, what do I put in a name, right? What are the relevant concepts? Because once you’ve found that, once you have decided these are the things that matter, always put them in the same form. And this is very new research. It was really like last year. So, there hasn’t been so much research into what form is better, what name mold performs better? I hope that scientists will go that direction. But I think for now, not knowing what form is better, knowing what we know about the brain, I would say it doesn’t really matter which one you pick, but pick the same one.
Felienne 01:04:13 So, bite the bullet with your team and decide, okay, what do we do? Do we do noun first, or do we do for verb first? And this is what we do throughout the code base, where it’s relevant. That will be a process that takes a bit of time; easier for fresh code bases, harder for extensive, lonely little code bases where your a long-term memory, for awhile, will be like, “Hey, oh, that looks different; now I’m confused.” So, it’ll take a while before you get used to the new variable form. But I think that’s something that you can really do. What we know from cognitive science just tells us that if stuff is always the same, your brain will be like, “oh, I know this.” It’s just easier than having to read and figure out the variable. And it will be easy also in a sense, once you’ve made the decision, which I know is not easy. But it’ll be easy to maintain. You can put it in your readme. You can say, okay, this is the name mold that we use. If many people read my book this vocabulary will be well-known. This is the name mold that we use. So, you can just use it everywhere.
Jeff Doolittle 01:05:14 Consistency and standardization are going to reduce that cognitive load.
Felienne 01:05:18 And specifically consistency, cognitive consistently. So, we use snake case, which is definitely useful, and it already reduces load a bit. But within a framework like using snake case, you still have so much freedom of where to import the parts of the name code that you want to be a little bit more precise.
Jeff Doolittle 01:05:36 Yeah. And I’ll just add it’s fun to hear you talk so much about Python. You mentioned PEP8, which of course we’ll put in the show notes. It’s a particular way of formatting your Python code, and there’s tools that will tell you if it’s off and help you fix it. But then you’ve mentioned list comprehensions. You’ve mentioned snake case, and for our Python listeners out there, they recognize and fight hard for doing things the Pythonic way. And so, congratulations on making the switch from Java and C# Oop, and actually embracing the way of Python. So, that’s just fun to hear and we’ll add links to all that. Yeah.
Felienne 01:06:08 In the last few years, I’ve only been both teaching and using Python for my own projects. So, I think that shows in the examples that this is your long-term memory, right? Those are the examples that I thought about most recently. So, in the heat of the podcast, it is easiest for me to come up with these examples that are fresh in my memory.
Jeff Doolittle 01:06:26 Yeah. And that’s great that you began your career one way and with a couple of languages that in some ways are even a different paradigm, there’s obviously some similarities, but that’s just hopefully encouraging to listeners as well, that: it may seem daunting — there’s all these new languages to learn, but it can be done. And I think that represents as well that having a community, and it’s your smaller community of your team, how are we going to do name molding and how are we gonna apply that, but the broader community as well, that adopting new principles of how they do things that can be another way to reduce your cognitive load, reduce your confusion, and help you be more productive.
Felienne 01:07:01 Yeah, definitely. And I wish now in retrospect that I had already written and read my own book when I was making the transfer, because in many situations I was so, so confused. And it’s so hard if you’re an expert, because I was, like, a good C# programmer. So it was like, it’s just because I’m old. It’s because I can’t learn another language. I will never learn this. And it’s just because I lacked the techniques to learn. And I lacked the understanding that the confusion I was feeling wasn’t “I’m aging,” but was just negative transfer hitting me in the face all the time. So, I really hope that knowing about these techniques and knowing about the vocabulary that you can say to yourself instead of, “oh my God, I’m stupid,” you can say, “Maybe I’m experiencing too much cognitive load.” What can I do to manage my own cognitive load? That’s really a nicer, like inner conversation with yourself then “you’re too old; go back to sharp programming, you will never learn anything.”
Jeff Doolittle 01:07:58 Yes. It’s an enabling thought rather than a thought that shuts you down or discourages you. And we could do a whole, and this wouldn’t be a Software Engineering Radio episode, of course, but I’m sure a whole episode could be dedicated to the internal conversations we have with ourselves that hold us back and how to overcome that, as well. But, your passion is evident, and it is clear that, as you just basically said it, you wrote the book that you wish existed when you needed it. And it didn’t. So, you wrote it. And those to me are often some of the best books you’re ever going to read. So, if people want to find out more about what you’re up to, where can they go?
Felienne 01:08:34 You can follow me on Twitter. My first name is very unique in the world, so that’s easy. So, my Twitter is @Felienne. My website is felienne.com, and there you can read also about all the research I work on. And if you want to know more about the book, specifically, you can simply go to Felienne.com/book, where there’s a link to the publisher and some background information.
Jeff Doolittle 01:08:54 That’s great. And for listeners, that’s Felienne, spelled F-E-L-I-E-N-N-E, Felienne. So, I’m very jealous and I’m sure some of our listeners are that you have one name. And so, you know, you’ve joined that club of celebrities that are known for just the one name. So,
Felienne 01:09:13 That’s great. Thanks to my creative parents that has this.
Jeff Doolittle 01:09:17 Oh, no, no, but it’s great. And it helps people find you and learn more about what you do. And clearly you’re making great contributions both academically, but also to those of us who are practitioners and professionals. So, I’m so grateful. Thanks for joining me today on software engineering radio.
Felienne 01:09:32 Thanks for having me. It was great to be on as a guest.
Jeff Doolittle 01:09:35 Absolutely. Well, this is Jeff. Do little for software engineering radio. Thanks for listening. [End of Audio]
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
Very nice professional presentation by the experienced guest and the host asking the right questions. Many examples of the aspects of real life programing situations spiced with humor. As I am already retired real-time programmer for several years, I enjoyed all aspects of this radio show, which confirmed a lot of my personal experiences.