The Programmer's Brain

Transcript

Hermans: My name is Felienne Hermans. I'm going to talk about my book called, "The Programmer's Brain." Specifically, we'll zoom in on the topic of how to read code.

Before we really dive into reading code, and The Programmer's Brain, I want to take you through my personal history of how I came to study The Programmer's Brain and how I came to study code reading. We have to go back to the year 2013, in which I started to teach kids, programming, 10, 11, 12-year olds at a community center in my neighborhood, wanted to learn programming. I was like, "Sure kids, I can teach you programming." I was like, how hard can it be? They're children. Even though I didn't know that much about teaching, I figured it was not going to be hard.

What happened then is subconsciously, I started to think back at how I learned programming when I was a kid. This is me programming when I was about 10 years old, behind a big computer. I was really small then, but also computers were really big in the '90s. When I was learning to program, I wasn't really going through a programming lesson or a programming tutorial. There were no programming lessons. There were no adults around that really knew programming. I never really took a programming lesson. I learned programming from a book. Maybe some of you of my age, have the same experience that these books weren't really explanatory books. They just had printed out source coding. This is how I learned programming by reading and figuring stuff out. Ultimately, of course, getting a sense of what those codes mean.

It isn't just me, many people my age share the same experience of learning programming without a teacher, without going to a programming lesson. As a field, we miss a collective history of what a programming lesson looks like. You might wonder, why is it relevant for code reading? The fact that we don't really know how to read code directly relates to the fact that we never took lessons. I'll show you in a bit why that is so related. Because we never really went through a programming lesson as a community, we don't really know how to shape a lesson. I certainly didn't know how to shape a lesson. I just let the kids explore. This is something still very visible in our self-image as a community, just let people explore, just let kids explore on their own, they will figure it out.

You still see this vibe very much in programming for kids' books that you can buy now, so not in the '90s. Today, if you look at programming books, you see that those are written by people with the same experience. For example, here's a book, Computer Coding for Kids. The snippet is in Dutch, but there's an English translation underneath. This says, never be afraid to mess around and experiment. This is very much the perspective of someone who doesn't have a teacher close. Because if you have a teacher close, maybe messing around and experimenting isn't necessarily the most effective way to figure stuff out. It might be more effective to ask your teacher in a more guided setting where that would be valued. Maybe books should say, never be afraid to ask your teacher if you're stuck. Saying something like never be afraid to mess around and experiment, it's very much the best if you don't have a teacher. Maybe it's not the best if you do have a teacher.

How Do People Learn?

This is still very much tangible in our community today. This, just let kids explore. This is what I did in my programming course also with the kids. It wasn't really working all that well. Kids got really frustrated when I'd let them struggle and explore and figure stuff out. Then after a while, I also got somewhat demotivated, I was like, why don't they learn anything from figuring stuff out? I learned stuff from figuring stuff out. Why isn't this working for everyone? Why isn't it working for the kids in my class? These were kids that came to the community center voluntarily on their day off, on their free Saturday. It wasn't like they were motivated or anything, clearly, like I was doing something wrong. At that point, I got very motivated to understand how people learn. I started to read a lot specifically about how people learn their first natural language, English, Dutch, or German, or Japanese. There's lots of research about how kids acquire their first natural language. I thought maybe there's something there that can help me gain an understanding of why the kids in my class are struggling so bad.

We Don't Teach Reading Code

From that, I got this idea that we never really teach reading code. That might, again, have something to do with the fact that we used to not have teachers. We never really teach reading code specifically. Going back to how stuff worked in my programming class, these kids would say, "Teacher, I made this code last week, and I don't really remember what it does. Can you help me figure out what this does?" Then I would be like, "What do you think it does?"

Because in my mind, I had this, never be afraid to mess around and experiment idea. This situation isn't limited to teaching kids. Even in onboarding people in my open source repository nowadays, I still sometimes feel that I am reluctant to give answers. If someone says, where in the code is this located? I could just say, it's there. It is nice to see this sparkle, to see the light go on. People would sometimes give hints rather than just give an answer. Partly, this is probably because this community was shaped so much by self-teaching, that we think that if you figure something out, you will remember it more strongly. The kids in my class, they were frustrated. The kids ask you. I don't know, so it's not really helpful to ask me what I think because I had no clue. I have no conception.

We don't really teach the act of reading code. We don't offer strategies to novices, this is how you read code. I've seen third year students in a computer science program if they needed to interact with some code and I said to them, you know what these do? They would take their finger and go to the first line, and read it from top to bottom. At first, you're like, why are you doing it? Then you're like, I never explained to you anything else. Yes, surely, you'll fall back to this strategy you know that works for language.

We Don't Practice Reading

Now we're moving more towards professional practice. Secondly, we also don't practice reading. Professional software developers spend lots of time working with code, reading code. There's an estimate that a professional developer spends as much as 58% of their time reading code. More than half of your time is spent on reading code. However, as a culture, as a community, we still very much emphasize that you will get better by writing more. If you want to get better at programming, you should have this Saturday open source project, or you should just learn a new language and make whatever you want, like make some calendar app, or something. This is again rooted in this never be afraid to mess around and experiment vibe. We want to mess with the code. The code is truth.

You see this also in the type of things we do as a community to advance. It is getting later in the year, it is almost December, so people started thinking about Advent of Code, which is this thing where in December every day, you do this little programming puzzle, which is lovely. Again, it is production. If we celebrate our skill, getting better at our skill, then it's almost always focused on practicing code writing, and hardly ever focus on practicing reading. We don't practice reading.

We Don't Have Theories for Reading Code

The third thing that I figured out from really diving into natural language learning is we don't really know what happens in your brain when reading code. We know a bit. There's some really cool work from a German scientist called Janet Siegmund, she takes programmers and she puts them into an fMRI scanner, and measures what happens in our brain, which is super cool. By and large, we're still figuring out what happens in your brain if you read code. As a society, we do know much about what happens in your brain when you read language, what happens in your brain when you process information.

Short-Term, Working, and Long-Term Memory

I want to take you through what actually happens in your brain when you process code and information, and code in specific. Then we'll see what that actually means for your daily practice of programming. If information comes into your brain, through your eyes or through your ears, it firstly enters the short-term memory where it's stored for a very brief time. This is a little bit like an IO buffer, very small and stored very briefly. We've known this for a very long time, actually. George Miller's research in the 1950s described that your short-term memory is very limited, very small. It might only be able to hold between five and nine things at the same time. It's very brief storage. It is not something you can just clump lots of information into.

Just to give you a sense, because I don't just say like five to nine elements. It's very abstract. Let's do a little experiment. I will show you a very brief sentence for a very short amount of time, like half a second, then it's your goal to remember this sentence. That was really hard. Now you're like, this is impossible. I cannot process that information. This is the limitation of your short-term memory. You look at this information and even if I would have allowed you to study it a little bit longer, you would not have been able to really remember all the characters, because your short-term memory is so small.

You also figured out that I only showed you part of the puzzle, because these weren't real letters. It isn't just your short-term memory that does the process. Your short-term memory takes information that comes into your brain and sends it to the working memory. Your working memory, that's a little bit like a processor in the brain that is processing information. Your working memory works together, collaborates with the long-term memory. Your long-term memory is a bit like an angel on your shoulder, that when presented with information, when information is in your working memory, your long-term memory will be like, I know this information. Here's related information that also might be of value to you. It's always trying to give you information that you already know, to help you process the information currently being processed.

To see this process in action, we will do another puzzle, a similar puzzle, three words shown very briefly, and it is your goal to remember the sentence. That was easy. It was still hard, but it was easier. Also, your little long-term memory angel was jumping on your shoulder. It was going like, ABC, obviously that's a K, MBR. Then probably this is when the sentence was removed. Something was happening, you were recognizing letters, and you were trying to make sentences out of the letters, or words and then sentences. This is because your long-term memory was now activated, because recognizable stuff for sure.

To show the power of the long-term memory for processing, we will do one more memory exercise, very similar, three words shown briefly. That was doable. That was probably relatively easy. You see, the more you know, the more you can process. This 'cat loves cake' for you it's relatively easy, you just look at the words and immediately you grasp it. The trick here is that your brain isn't reading C-A-T L-O-V, it's certainly not doing half a circle, and a circle, and a squiggly, and a Catholic cross and a stripe. Immediately you see the letters, you see the words, and you think of the concept. This is what makes it so easy for you to process this information.

I think already here there is a takeaway, because if you are working with someone less experienced in your code base, less experienced in the programming language that you're using, you might show something to them. You might show them it is a cat. It loves cake. Something in the code that you know very well. For the novice programmers, it might just be letters, it might just be characters, because if they don't know enough about the code base, about where stuff is and what is the meaning of keywords, what is the meaning of domain concepts, then it's not like they don't remember. It's that it doesn't even enter their working memory properly because they can't process. What you know very much influences what you can process. These individual elements are retrieved from your long-term memory. It isn't like this language, English is inherently easier than the made-up characters I showed you earlier. It's just that you know more.

Different Forms of Confusion

Let's take this back, this knowledge that we now have about cognitive science towards programming. Let's look at three different programs and the memory systems that they involve. Here's a program written in APL, a programming language. If I ask you to read this code, you can think about it for a second, what this does. You could process the 2's. You can also process the n, you know that that isn't a number, maybe an integer even. I'm going to guess that most of you are stuck there, stuck on the T, because what does this T do? This is just a long-term memory issue. You just don't know what it does. It isn't that it's hard to remember this code. It's also hard to process. It's just, you lack information.

Here is code that is confusing for a different reason. This code is written in Python, in a Pythonic way. If you're not familiar with Python, this is called a list comprehension. This creates a list. You can see that from the rectangular brackets, it creates a list based on an existing list with a filter. If you know Python, this is very easy. This is cat loves cake for you. There are many elements here. If you're not so used to Python, or to this specific language construct, and it is, customer_name, c.first_name for C in customers. This is more than the known elements that your brain can easily process. This is a short-term memory issue, potentially, depending on your prior knowledge.

Here is code of yet another confusing type. Most of you are familiar with the concepts here, even though they might not know BASIC, most of you know what a LET is, it's an assignment, and a FOR, and a RETURN, and a PRINT, and some assignment with some mathematical calculation. Long-term memory is like, I got it. I know these things. There's much information so your short-term memory might be overloaded. It's not only that, it's also that you go like, ok, I see the individual parts, but how do they work together? It's almost like you would want to take your finger and go like, ok, if N is 7, then N divided by 2, this is 3, this is string 1. You cannot at once grasp the program, you have to do this step by step. Basically, your mind wants to play the compiler to figure out what's going on. This is a working memory. You have all the information, you understand all the information, but you're not able to put it together.

Different Solutions for Each

These different forms of confusion are important, because if you recognize what part of your brain is engaged too much, is struggling with a certain piece of code, you also know how to solve it because each of these different forms of confusion have a different solution. If you just pile them together as, "Code reading is hard. This is confusing. I don't know what to do." Then you don't know what to do. Whereas if you understand, this code is hard because this presents a long-term memory issue, you also have a path towards being less confused. For this type of code, where we have a long-term memory issue, the path to less confusion is to practice syntax. A nice strategy for that is flashcards, in which you make little paper cards, like business cards. Then on one side, you put the syntax elements, and on the other side you put the definition. If you are learning APL, you could say, this is a T, it's actually not a T, it is an encode symbol, and you can practice.

Of course, assuming most of you don't want to learn APL, what you can also do is put Python on one side, and Java on the other, and then train yourself in that. Or if you're not necessarily struggling with a new programming language, but with a new business domain, you can also put domain concepts on one side and the definition of the domain concepts on the other side. You simply put this stack on your desk. Every once in a while, you'll take a card, you're like, do I know these domain concepts? Let's see, I do know this, or you don't. Then you practice again. The book has a lot more strategies to practice. This is just something you can do to practice.

It's really important that if your long-term memory is suffering from confusion, it doesn't make sense to plow on. It doesn't make sense if you're reading code in which half of domain concepts are unfamiliar to you, to think, I will just read this again. It will not get there. You really need this familiarity. It shouldn't cost you too much energy to process individual parts of the code, otherwise you will not continue. Again, think of how much easier it was to process cat loves cake, than the other two sentences. Don't let yourself be in such a situation.

Cognitive Refactoring

This code though, has a spectacularly different type of solution. If you're struggling with code of which you know the individual elements, but they are shaped in a form that isn't so convenient to you, what you can do is rewrite the code. If you were maybe coming from Java, and you're not so used to list comprehension, you can rewrite this code. This second code snippet does the exact same thing as the top code, but might be, depending on your prior knowledge, way more comfortable to you, where you say, I make an empty list. Then what I do is I loop over this list customers. For every C, I check, are they older than 50? Yes, then I add their names to the list. This is what I call in the book a cognitive refactoring. It is a refactoring because you're not really changing the behavior of the code, it is the same code snippets. You're taking the code and you're moving it closer to your own prior knowledge. If you're not so familiar with list comprehension, this second form is easier to use. Of course, this snippet isn't the code base, you must imagine that you're in a big method of which some list comprehensions are part. That's just a waste of your time if for every list comprehension you go like, yes, what is this again? It distracts you again from the bigger picture. You can rewrite parts of the code to make it easier to process. Again, the book has a lot more different cognitive refactorings, there are all sorts of other things you can do to massage the code to be more easily processable for you.

Some people now might be yelling angrily at their screen saying, this is not a refactoring, you're making the code worse. In some cases, it is true that you would want to roll back this code to its original form. If you have something like a Git repo, of course, you can just make your own branch, do some refactoring there for comprehension, and throw away the branch later. In many cases, this is not a refactoring you want to commit, it's really refactoring you use temporarily to gain a better understanding of code.

Support Working Memory

Finally, then, if you have code that is of this type, where it's just really hard on the working memory, you can support your working memory. You can use techniques that help your working memory, where you're like, I'm processing too much data at once. Let me offload some of this data onto a piece of paper or a whiteboard, or even in your code. An example is to make a little state table in which you say, I'm going to try to understand this code for the values N. Just say, this is the initialization phase. Now, this happens in the first loop, this happens in the second loop. That can give you a better grasp of what the code is actually doing.

Summary

In short, if you understand your own understanding and understand your own misunderstanding, this will really make you a better programmer. Because instead of just saying, "I am confused," you can say, "My long-term memory has too little prior knowledge, I need to improve that." It will help you, hopefully, out of a situation in which you feel confused and powerless, and gives you techniques to help you out and to help you advance to more understanding.

Resources

If you want to know more, there's many things you can do. One thing you can do is read my book. In this talk, we've covered like chapter one and a little bit of two and three and four. There are 13 chapters. There's much more to learn about the impact of naming on your cognition and the relation between code smells, and the working memory, and the short-term memory. A lot more to explore, but all aimed at understanding your own understanding in the context of being a program. Something else you can do, which is also very fun is starting a code reading club. This is an idea that I coined in the book, and that I've been exploring for a while, where people get together and they just read some code together, something from their own repo or something random from GitHub. We have all sorts of little exercises that you can do in the book, but also on a free website with resources that I will also link to, where we have code snippets that you can use for reading and exercises to use in a code reading club. If you want to explore that, that's definitely possible with free resources.

You can go to my website felienne.com for more information. Felienne.com/book is where you can buy my book and explore all the things we talked about. You can also go to felienne.com/club for a link to the free code reading club resources that I've put together with other people, as well, all names on the websites that have helped me shape code reading clubs.

One question you might have is, what about the kids? You started to teach kids, and you were failing. Then you wrote a book about programming and cognition. That's true. Then there was this other part of the puzzle for me as well. In addition to everything I learned going into a book, I also put everything I learned about how to learn into a new programming language for children called, Hedy, that really takes into account what we know about how kids learn, and tries to use that knowledge to make learning programming for kids better. You can go to felienne.com/hedy to check out Hedy, which is free and open source, and available in 17 different languages. Wherever you are, it's a big likelihood that you can do programming in Hedy in your own language, which is, of course, a lot easier for kids.

I'm one of the hosts of SE radio, software engineering radio, an interview-based podcast that occurs weekly, where we interview people from all parts of the software engineering domain, from programming languages to databases, but also soft skills, like how to interview or how to write documentation. All of that and more available also for free on iTunes, and Spotify.

Questions and Answers

Reisz: I love the short-term, working, and long-term memory. It just appeals to the engineer soul in me, helps me map and reduce problems. Was that word based on George Miller, or was it just the initial thought of short-term memory and then you shaped the rest? Where did it come from?

Hermans: It's a combination of different things. I really immersed myself in cognitive science there for a while. Definitely George Miller's work is underlying. There's also work by a Dutch chess player and also cognitive scientist, Adrian de Groot, who really researched how chess players learn chess, and specifically how really expert chess players think. He also describes that really good chess players are really good at pattern matching. Initially, they thought that maybe it's just because they have superior brains. Then it turned out, they had just seen so many chess games, that they were really good at saying, this is the Sicilian opening, or this is this, or sometimes even their own personal memory, like, this game is like the one I played with Betsy on that rainy Saturday afternoon. They just had this really big repository of patterns to use in playing. Adrian de Groot work was also very influential in my thinking.

Reisz: Patterns was the word, as you were describing it, they have design patterns for chess that they're able to apply and say, here's a pattern to actually implement that.

Hermans: I actually talk about that in the book as well, how our design patterns actually work that way, that because you know a certain design pattern that we as expert programmers we look at code, and we don't go line by line. We just say, this is the decorator pattern, apply to that variable. Then with the design pattern, it becomes cat loves cake. Whereas for a novice, a junior programmer, there's not something like, warning, decorator pattern. Maybe it's there. Maybe it's not. We can still see it from structure, even though nothing is saying decorator. Then sometimes a junior is like, where did you get that? It's like, a few decades of experience.

Reisz: You see a single thing, you immediately know the pattern. Yes, absolutely.

One of the questions that I have is in the short-term, working, and long-term memory. As you move throughout your career, do you always move through those stages? Do you just spend less time in each stage when you build up that pre-knowledge of like ifs and loops and the structure? What does that look like?

Hermans: In principle, yes. If you learn a new programming language now after having loads of experience, then yes, it becomes easier because you can do pattern matching quicker. The closer your language, of course, is to languages you already know, the easier it is. If you go from C# to Java, that's like nothing almost. You'll be able to very quickly have these concepts. I have a whole chapter about learning second languages actually in the book. There's this principle called transfer, which is exactly using knowledge that you already have in a new context. You have positive transfer, and if something's really close, like Java or C#, then you have loads of positive transfer, and maybe you have just a little bit of negative transfer, with like checked exceptions that are a bit different.

If you are going from Haskell to JavaScript or from PHP to C++, then you're going to have both positive and negative transfer. Your experience is not only going to be helpful, it's also going to be detrimental. For example, if you go from Haskell to another language, then suddenly you have to deal with variable assignments, and so stuff is mutating all over the place. You have no mental model for that if Haskell is the only programming language that you know, so then it is not helping, it's actually making you less productive. We sometimes see this with students that students with prior knowledge in a language that we don't teach actually do not have a good time, because they have to unlearn so many things, and they see themselves as experts.

Reisz: How do you unlearn things? I wonder how this applies to Java 8 streams API. He's more comfortable with the nested loops and conditionals than jumping straight into the streams API. He has this pre-built knowledge on how to solve this programming problem. In this new approach, you almost have to unlearn the other approach to be able to really grok the new approach. How do you deal with that? What's the science behind that?

Hermans: We have a lot of work on that in the book as well. Unlearning things is not a thing. Once you know something, you know it. You can't really forget knowledge. This is very hard, especially if you've used this knowledge very often, then it will continue to come back to you. I have not programmed in C# in over a decade, yet sometimes if I'm very engaged in programming, and I'm looping over list elements, I will type, for each, in Python. I'm like, don't do this. It keeps happening. Unlearning is not a thing. What you can do is deliberately teach yourself or practice new knowledge. There's this idea in the book that I describe that's called conceptual change, in which a concept for you changes into something slightly different. If you learn multiple programming languages, then the concept will morph into something generic, instead of just knowing a loop in C, as you maybe learned when you were an undergrad, now you know this concept of looping at a more abstract level. You can try to train yourself to see these concepts in a more abstract way. Learning new things is hard, but learning slightly different new things is maybe even harder.

Reisz: I'm curious, you used that flashcard example. That's one of my favorite ways to prep for a cert test. One of the challenges I have is that if I'm not actively using the construct that I'm working with, then it leaves my memory. Why is it? Is it long-term? Is it working? Where does it sit that I can't seem to keep it?

Hermans: You have the idea of retrieval strength, and this is in your brain, not necessarily how well it is stored, but how easy you can find it. In computer terms, like how many pointers do you have to this specific piece of memory? If you retrieve something from your human memory, then you strengthen this connection. The more often you remember something, the easier it is to find it.

Reisz: In your little RAM.

Hermans: Then it is cached, it is easier to access. If you haven't accessed something in a very long time, then you forget it. I now have this RFID thing in my phone so I can pay with my phone. A while ago, I had to use my old fashioned card because the shop didn't have the phone thing. I was like, what's my code for my card? I don't remember because I haven't used it in such a long time. I must know this. I know it. Of course, I knew it after a while. That exactly is retrieval strength. If you don't retrieve something often enough, your brain is a super-efficient machine. Your brain is like, "You don't use this code for your card? I will put this somewhere in the back, like an out of memory. He's not using this."

Reisz: It's like write to disk.

I'm curious about some other techniques to help teams just work on this strength, things like unit tests and code reviews. What are your thoughts on tools like that in how they help teams just level up?

Hermans: I'm going to go back a little bit to those code reading clubs, because I found that that is such a good way as a team to communicate. They've been working in ways I didn't anticipate. If you read code as a team together, then not only are you practicing your code reading skills, you're also leveling your understanding. Someone will say, this code is really hard for me because it uses list comprehensions, or it uses this type of MapReduce stuff, or immutability that I'm not really used to. People get aware of the things you do, the things you know. It's also a really nice way to discuss design decisions without being in a situation where you're making design decisions. In a code review you're never neutral. I have made code and someone says, I don't like it that you mutate state so much. This isn't neutrally saying, "How much mutation do we allow in this code base?" They say, you are doing it wrong. It's really nice to split these discussions of this specific part of code, or what in general do we want? These type of discussions about code also very much then is code review, because you then have this shared idea of where you want to go with the code, not in terms of features but in terms of design.

Reisz: One of the things that I've found that really works for me, and I call it deep thinking, I don't know if that's the right phrase, but that's what I call it. Last year, Python was what I focused on, what I dug into, because ML, AI, all those things. What I found really useful was being able to struggle with a problem, and then get an implementation, and then go back and read other people's implementation, so code reading. That's how I applied it. That in particular really works for me to be able to think deeply about a problem and then read code. Why is that?

Hermans: It's because you're an expert. It's because you're really good. There's this really interesting concept called the expertise reversal effect. If you're a novice, then plowing on isn't useful. Once you're an expert, it's actually fine because you're not going to be discouraged by all these confusing stuff. At a certain level, different things work than at a lower level, which is also very hard, because you tend to think what works for me will also work for little new junior just out of college. That's not true. If you experience this, yes, it's because you learned in your fifth programming language, and also very likely, you will have solved similar problems before. You're using a combination of your working memory, but also your long-term memory, you will be thinking, I solved this before, five years ago at this customer, maybe in a different language. You have a repository of strategies and syntactic elements and concepts that you have in your long-term memory. If someone likes that, then it's going to be all working memory for them. That's where the difference is. That's just because experts learn differently than beginners do.

Reisz: That's a huge, important concept for me to understand right now, because I've worked with so many different languages, and I just expect people to do the same, and just constantly go relearn something. If you're not relearning a new language or a new thing, you're antiquated, you're legacy code in software. I get that. It's nice to have that mental form to be able to make sure that you recognize that. That's awesome.

Speaking of senior people and junior people, what things do you recommend? We talked about code reading. We talked about unit tests. What do you recommend for senior people, whether that's leadership, or just developers, on helping more junior people get to where they're experts at code?

Hermans: Some of the things we talked about in the talk already that you can do to yourself, you can also do that for someone else. Cognitive refactoring in itself already takes some energy. This is something you can definitely do for a junior. You can take the code and you can say, I massage it a little bit. I put it in a form that will work for you. Or do scaffolding, where you put some stuff there. I sometimes do this, even with contributors in my open source projects, where I'm like, I'll make a branch, and here are some gaps for you to fill. That's useful because it lowers that cognitive load, but also, it ensures that the architecture is in a way that I wanted to go. That's definitely something you can do. Instead of saying, you add this feature, say, I already added it to the frontend, so the button is there, and drop-down is there. Here's a function, and you just implement this function. You don't have to do this switching between frontends and backend, you just implement this thing. Or the other way around, I already made the logic and you just have to add it to the frontend. Dividing a problem into sub-problems then adding, sub-goal levels, like this part of the code will do this. This is the goal of this thing. Then someone else just fills in those gaps.

Reisz: What language is really good for first year students? Obviously, Hedy. You want to talk about Hedy, and why you feel that's a great language for first time students or first language students?

Hermans: What we do at Hedy is we split concepts and syntax. Instead of saying, this is a, for loop, and you type it, like for I in range, that's super complex. We do it stepwise. First, we say, this is repetition. Then the syntax is super easy. The syntax is just repeat three times, and then you can repeat something. We first do the concept, and then once the concept has landed, we add a little bit of syntax. We try to ramp up slowly and don't overload the working memory that has to then think about syntax and concepts. We split this. It's free and open source.

See more presentations with transcripts