CoRecursive: Coding Stories - The Science of Learning to Code

Episode Date: August 2, 2023

Learning to code can feel impossible. Like facing a sheer rock wall with no ropes or harnesses. But what if there was a path up the mountain? A trail blazed smooth by master coders who went before?  In this episode, we'll follow that path. We'll hear the stories of legends like Seymour Papert, who championed active, project-based learning. Of Fred Brooks, who discovered that pairing accelerates learning. And more.  The research shows that with the right methods, motivation, and support, anyone can master learning curves and summit. So join me as we uncover the science behind learning to code. You'll walk away fired up, equipped with proven techniques to unlock your potential and conquer new technical skills.     The climb is on!   Episode Page Support The Show Subscribe To The Podcast Join The Newsletter  

Hi, this is Code Recursive, and I'm Adam Gordon-Bell. Today, something different. How did you learn to code? For me, it was in grade 10, the second year of high school. I took a class taught by Mr. Omar, who was mainly a math teacher. A great math teacher, I really liked him. But he also taught this programming class. The class was on the programming language Turing,

which I don't think is used anywhere outside of, you know, Ontario, Canada in the 90s, probably. But the programming language was like Python. And the class, we split up into groups of two, and we built a game, the Yahtzee game. My partner was Jason Solomon. But for me, this class was so much fun. I don't know, it was just, you know, the feeling of programming, the feeling of building something and seeing it change, making another change, seeing it change, the quick feedback cycles, the figuring things out. It was just amazing. I decided at that point that whatever this was,

this computer programming thing, that's what I wanted to do, right? And I did do it. I went to university for computer science and I never looked back. So that class was very fortuitous for me. But how do other people learn to code, right? If somebody asks me because they have a project they want to build, or because they just heard it's a good racket, or they're just curious, if somebody asked me how to code, I can't tell them, go to Leamington District Secondary School and take Mr. Omar's class, intro to Turing,

that advice doesn't fly. I'm pretty sure he's retired and the programming language probably doesn't even exist anymore. But today I want to answer that question. I want to take you through some of the education research, some of the computer science research on how to teach someone how to code. Research on how to learn and how to build a skill. And by the end of it, I think you'll have a solid answer for that question, right? How should you approach learning a challenging task like coding? How should you specifically approach learning coding? And how should you approach your own learning goals?

So that's the episode. Let's do it. So there's this story that goes back years in the world of computer science education, a story that's a bit polarizing. At its center are these two researchers, one is a professor, one is a graduate student, and this paper that they wrote with a famous title, the paper is called The Camel Has Two Humps. So picture this, it's 2006, and it's a world that's, you know, growing more and more digital by the day, a world that's desperate for computer programmers and people who can build the future. In the midst of all this,

a special test was found by Sahid Donad. I imagine Sahid and his advisor, Richard Bournat, sitting in Richard's office at Middlesex University near London, England, and they're poring over the results of Sahid's test, looking for patterns to this questionnaire, to this quiz that they have been putting students through. They were looking for an answer to a simple question,

is there such a thing as a natural-born programmer? And they found something, or so they thought, a simple test that they claimed could predict with significant accuracy who would excel at programming and who wouldn't. It was, in their own words, like separating programming sheep from non-programming goats. But before I get into what the test was, here's what happened. They wrote their findings up and they started to distribute them and the tests that they had developed. And the idea caught on, right? It was a much simpler world to believe that people were divided into those who would get programming and those who wouldn't, right? Instead of confronting the complexities of teaching methods and learning styles and the myriad of factors that influence whether somebody would

succeed in a programming class, this was just a simple test. Take this test, you're either in or you're out. Remember, this paper was making its way around the computer science world in 2006, and somewhere around the late, late 90s, computer science departments had started to get huge, right? Computer science departments were at the coalface of getting more people into technology. And that wasn't always easy. My classes at the University of Windsor, year 2000, they were huge that first year. I guess the dot-com boom had led to lots of people going into computer science and to the departments expanding a couple years before I got there. And so all of a sudden, it wasn't just computer nerds like me, right? It was all kinds of students.

But I had a class that first semester, that first year that was C programming. And I had done some programming before, but it was the Turbo Pascal, it was the Turing I mentioned, Visual Basic. And I did struggle with the pointers in C, right? Pointers were still not my thing. But here's what I remember.

I remember one day after a rough midterm, this very large lecture hall, and I remember the professor saying, let's call him John. He shows a graph of the marks for the class, right? It's projected on the board from his computer. And it isn't like a normal bell curve. It's not the hill that centers around one spot, but it's kind of this messy blob that spreads out all over the places. This is exactly what the paper was about because my professor said, there's lots of theories about what's going on here. So one theory is that this doesn't look like a bell curve because there's multiple bell curves here. There's two of them, right? And really, this is the theory I would have went with. I was not a very studious person, but I knew how to program. I mean, I struggled

with the pointer math, but yeah, I did get in to program. I mean, I struggled with the pointer math, but yeah, I did get in the class. I knew what I was doing. Others didn't. Others really didn't and really struggled. I had two friends, Matt and Joel. They're on my floor in residence, and they were both in computer science first year. And both didn't end up in computer science second year. Both ended up transferring to the School of Business. Matt never got past calculus class. There was a prereq for so much of second year that he pretty much had to switch programs. And this happened for a lot of people, which meant that come second year, the classes were much smaller. Some of those people

on that graph, they didn't make it. So that's what the paper was about. The Campbell has two humps instead of university comp sci classes having a normal curve. They had two curves and those are Campbell's two humps. And one of those humps is a dud, right? They should not be there. They do not have what it takes to become programmers. It was very reassuring for first year student university me to hear this professor say like, listen, this is the graph. Some of you don't have what it takes and others do because it's nice to be one of the chosen ones. And think of my professor, right? John had been teaching for nearly two decades. He had been trying his best to instill the intricacies of coding into his students. And some, they catch on quickly, while others, they just don't. And picture John late one night,

and he's staring at these disappointing midterm exam results. And he's questioning his teaching methods and his patience and his career choices, right? And then somebody distributes this paper to him. The camel has two humps. And it says this, we have found a test for programming aptitude of which we give details. Remarkably, we can predict success or failure even before students have had any contact with the programming language. And with total accuracy, we present statistical analyses to prove the latter point. We speculate that programming teaching is therefore ineffective for those who are bound to fail and pointless for those who are bound to succeed. In this theory, of course, John can find solace. It's not his fault. He can tell himself these

students, the ones failing his class, they simply can't code. It's not a matter of efforts or of teaching methods or of patience, right? It's just nature drawing a line between those who can and those who can't. They were born that way. For John, right, and countless other educators, this paper was life-affirming. It validated their struggles and their frustrations, and it gave them an out, a chance to wash their hands of the responsibility and this allure of a simple explanation. It made this paper a hit. It made this paper famous or infamous. So this test, this test that can decide if you're a programmer or not, what's in it? Well, you can find the test on Richard Barnett's website. And you know, taking it gave me pause. What if I failed, right? What if

it's all the pointer math that I couldn't handle in that C class? What if I should have washed out of comp sci like 23 years ago, and I should have transferred with math to be in business school and be a business consultant somewhere. But I took the test anyways. The test is like 12 pages long. It's designed to be printed out in landscape mode. Imagine a bunch of A4 papers like turned the long way and stapled together and handed out to students at their desk. And the first question goes like this. Read the following statements and tick the box next to the correct statement. A equals 10. B equals 20. A equals B. The new values of A and B are. Then you have a whole bunch of answers, right? Including A equals 20, B equals 20, which is what I would go with, right? It's assigning the value of B to A, which is not hard, right? There are 12 questions. And here's the weird thing. They're all like this. The 12th

one is A, B, and C. But all they seem to test is that you understand how variable assignment works in a programming language that's like C. So I passed the test. I got all 12 answers right. But here's the thing. What an absurd test, right? Like, are they saying that some people are born naturally understanding C-based variable assignment from birth? Like, that can't be right. Someone has to explain to somebody that equals equals assignment, right? That's not something you know from birth. It seems like there's a lot of assumptions embedded in this quiz. But then it's time to grade. And the grading is a little bit different than I thought it would be. It turns out that there are not right answers per se. The test was looking for consistency. If you thought assignment A equals B caused the values

to swap, and you use that logic throughout all 12 answers, you would pass the test. The pass fail was based on whether or not you applied the same rule across all of the test. The pass-fail was based on whether or not you applied the same rule across all of the test answers. Which is a bit better, right? So it's not actually C assignment, it's consistency. The whole thing is testing whether you have a theory for how a computer program might work, that the computer would have some specific rule that would execute repeatedly question after question. Of course, if you change your mind halfway because it's a test and you're nervous, then I guess you lose. But I guess what they're saying here is if you don't have a model for how computers work, even if you just make it up, then computer science is not for you. That was the test that they claimed separated students

into these two groups, those who are naturally born and will be programmers, and those who can just never cut it. But the story doesn't end there. The paper circulated and its conclusions came under scrutiny. Researchers tried to replicate the results and they came up short. The sample size was kind of small. The methodology is a little unclear, you know, determining whether they implied a consistent rule. It also just doesn't match how we think about learning a skill, right?

With effort and practice, people get better at things, including programming. There's no like impossible bar that nobody can get beyond, especially as something as simple as variable assignment, right? That can't be what's happening here. But then there's a twist. Richard Barnett came forward and he said the paper was a mistake. He wanted to retract it. Though it's embarrassing, I feel it's necessary to explain how and why I came to write The Camel Has Two Humps. It's in part a mental health story.

In autumn 2005, I became clinically depressed. My physician put me on a then standard treatment for depression, an SSRI. She wasn't aware, for some people, an SSRI doesn't gently treat depression.

It puts them on the ceiling. I think what he means is the depression caused him to have mania. Perhaps his depression was bipolar depression. I took the SSRI for three months, by which time I was grandiose, extremely self-righteous, and very combative. Myself turned up to 111. I did a number of very silly things while on the SSRI, and some in the immediate aftermath,

amongst them writing, the camel has two hubs. I'm fairly sure that I believed at the time that there are people who couldn't learn to program and that we had proved it. I also claimed in an email that Danad had discovered a 100% accurate aptitude test. Perhaps I wanted to believe it because it would explain why I had so often failed to teach students. It was an absurd claim because I didn't have extraordinary evidence. I no longer believe it's true. It turns out Barnett had been struggling. Struggling to teach students had been something that weighed on him. And just like the people who grabbed onto the result, he thought this finding had been a savior because it showed him that he didn't have to worry because these people were unteachable, right?

Speaking of those people, by the way, this test had some slight overtones as well. In the early days of this paper, Barnett may have made some comments about gender being a factor. Basically, women were in the dud hub. You see, the paper had a cost, right? A cost that was paid by the students labeled as non-programmers, the students who were written off before they even had a fair shot. It was paid by the underrepresented groups, the women, the people of color, the non-traditional backgrounds who were already fighting uphill battles to carve out spaces for themselves in the tech field. And now here's a paper that says like, oh, you don't make it. Barnett, of course, wishes the paper was never published, but I think it's valuable

because it serves as a reminder, right, that science is a messy process and there's missteps along the way and not everything is rigorous or peer-reviewed and that we should question bold claims. But most importantly and why I wanted to cover this paper is that we should resist easy explanations when thinking about human abilities and learning. It's easy to dismiss someone to dismiss yourself as not being capable of learning something, and that is by far the least likely explanation. More likely there might be some basic grounding knowledge that's missing, steps that haven't been explained well, problems in pedagogy, we need to have empathy for the challenges that people face when learning. There's another thing about the CamelS2 Humps paper that bothers me that seems less mentioned.

If you accept the claim that students can be divided into those who code and those who can't, that might be immediately reassuring, right? If you're struggling to teach a class or something. But the next thing that follows from that is there's no way to teach people computer programming, right? They either can or they can't. And why is this, if not true, the most tragic thing for a computer science educator to learn? To learn that your vocation has no point, right? All the time you've devoted to it has not been useful. How tragic would that be? It's the perspective of somebody who doesn't want to be teaching, right? What happens if we consider teaching computer programming from a different perspective, from the perspective of someone who loves and is obsessed with learning?

That's the next expert, one who would change not just computer science education, but attempt to change education in general. Part two, Seymour Papert. Seymour Papert had a passion for learning from a very young age. He didn't discover this passion in school though. Instead, he started with his love of gears. Before I was two years old, I had developed an intense involvement in automobiles. The names of car parts made up a very substantial portion of my vocabulary. I was particularly proud of knowing about the parts of the transmission system, the gearbox, and most especially the differential. It was many years later before I understood how gears work, but once I did, playing with gears became a favorite pastime. I love rotating circular

objects against one another, gear-like motions, and naturally my first director set was made from a crude gear system. I became adept at turning wheels in my head and making chains of cause and effect. This one turns this way, so this one turns that way. This one moves this many gears, this one moves that many. Gears serving as models in my head carried many otherwise abstract ideas into my understanding. I clearly remember seeing multiplication tables as gears, and my first brush with equations immediately invoked the car differentials. So even from a young age, Seymour was passionate about learning, but this passion did not extend to math class. I was lucky to have been born a mathematician, but I went to school like other

children and hated every minute of math. In particular, I loathed and feared mathematics class. The subject as it was taught in school seemed to have no relation at all to the gears that interest me. I could not understand why the teacher would stand at the blackboard and scribble strange marks and talk in a weird language. You see, Pappard could do math in his head using gears. How many teeth were turned here, this gear multiplies the effect of this movement, and so on. What he loved about math was its concrete hands-on form, math that he could play with and take apart and understand intuitively. But math class was all abstract symbols and rote memorization. It was disconnected from the math and gears and machines that he had played with that lit up his young mind.

This early experience, though, had planted an idea in Seymour's head that learning should be active and engaging and connected to real world interests. You see, years later, Seymour became a pioneer in artificial intelligence, and he was working at the artificial intelligence lab at MIT. He wanted to create a new way for kids to learn math and programming. This was the 1960s, and most of his colleagues saw computers as these giant calculators, perfect for crunching numbers and data, but not so relevant to more creative pursuits. But Pepper believed that commanding computers to draw shapes and patterns, kids could learn geometry and problem-solving skills in an intuitive and playful way. So he puts together this scrappy team of idealistic young researchers, and they get to work

thinking about new ways that computers can teach kids. First thing that he wanted to change about education was math class. The way they introduced probability is some ridiculous calculating of fractions. It's not useful for anybody. You'd never suspect from that that probabilistic thinking was one of the most powerful and dramatic far-reaching change agents in the history of science. So instead, his idea was maybe we could teach probability by having kids build things with randomness built into them. We can have five-year-old kids making art on the computer, introduce randomness and

probability into that to produce wonderful effects. We're going to have seven or eight-year-old kids making robotic devices that have probabilistic elements built into them so they can get around obstacles. This gives you a flavor of Papert's thinking, right? To learn probability, you need to actively construct a probabilistic system. Wrestle with core principles by building robots or building art that incorporate chance. He wanted probability to be hard fun. His term for, you know, immersing kids in big ideas and letting them playfully build systems around those ideas. Not passively absorbing, but actively creating. That's where he believed the deepest learning lived.

And this all was because he remembered his own childhood frustrations with the boring abstract math class. That really got to him. So in 1967, Pepper and his team at MIT created Logo, the programming language for children. Logo was among the first programming languages with graphic capabilities. But the key was its simplicity. And to make the programming even more concrete,

they also built a little robot called Turtle. The Turtle robot has three key attributes. It has a position and a heading, so children can map its movements to their own body. And it can be controlled with commands, like forward, back, left, and right. And it leaves a trace of its path with a pen, so kids can see the shapes they tell it to make.

The Turtle builds on a child's knowledge of space and movement. By playing turtle and acting out the movements themselves, kids can learn geometric concepts intuitively, and by programming the turtle, they actively build knowledge structures. The turtle allowed free, yet systematic exploration of mathematical ideas, right? It was a Cartesian plane, but it was also a turtle you could play with. In 1980, Pepper published a book, Mindstorms, Children, Computer, and Powerful Ideas, and it shared his vision for learning via making things and tinkering. He called his method of learning constructionism. It stood in stark contrast to the instructionist model used in both classrooms. Constructionism meant learning by building new knowledge with concrete

objects and experiences. Yes, it was built on his idea of gears, but it was also built on time he spent observing children learning at schools. He illustrated his theory through one such observance at a junior high school. I would pass an art class every day. For a while, I dropped in periodically to watch students working on soap sculptures. This was not like a math class. In math class, students are given little problems to solve on the fly. But in this art class, they were all carving soap over many weeks. It allowed them time to think, to dream, to get to know a new idea and try it out, to talk, to see each other's work. Not unlike mathematics, as it is for the mathematician, but quite unlike mathematics, as it is for junior high school but quite unlike mathematics as it is for junior

high school. Pepper saw that his students were learning art in a constructionist way, right? They were iterating on long-term projects that embodied their interests and ideas. They could touch and feel their work. And Pepper was at MIT and in the MIT lab, he knew the work he and his colleagues did was much closer to the process of these soap sculptures, right? They were sitting around thinking and playing with ideas. They weren't sitting around drilling math equations. They were dreaming and thinking and building. So what he wanted, what he believed in was the math could be just as hands-on and personally meaningful. Students should be able to construct geometric forms and see how equations works with gears and robots and whatever else. This type of

hard, gritty play with mathematical concepts was active learning at its best. He wanted children to experience the beauty and power of mathematics for themselves, not just to be handed down instruction on it. Constructionism opens up a new way of thinking about learning and knowledge. It tries to make a play, right? One where students build up their own learning rather than receiving it, rather than having it handed down. The idea of the Logo programming language, it wasn't there to teach computer programming. In a way, Papert cared little

about actual computer programming. What he cared about was using it to find a way to make learning fun. I have learned many new skills in the spirit of hard fun, including flying airplanes, cooking, juggling, and living with distorted spectacles that alter my vision. When I learned to cook chicken curry from my friend Sanjay, at first I had to carefully follow the recipe, but after making it a few times,

I could improvise and adapt the recipe as I wanted. It was the same when I was learning to juggle. At first I was dropping the balls constantly, but then I started getting the rhythm, and I had my first exhilarating moment of keeping them up in the air. So Seymour was a computer science educator, right? But only because computers and robots I started getting the rhythm and I had my first exhilarating moments of keeping them up in the air. So Seymour was a computer science educator, right? But only because computers and robots could be learning tools. In fact, side note, Hal Abelson, the structure and interpretation of computing programs author, right? He has a book that teaches advanced geometrical and mathematical concepts, all using logo. The whole thing using an exploratory constructionivist, you know, Pepper approach. That was Seymour's vision, right? All classes should become art class or auto class or woodworking class where you explore and make things and touch things.

At its core, this constructionism is about joy and the power of learning by making. Seymour Pepper never lost his sense of wonder and discovery, either for himself nor for the many children he was trying to inspire. His vision was that a graphical computer environment or even a robotic device being controlled by a computer could transform the student to a magical place that he called Mathland. Mathland sounds fanciful and magical and maybe challenging, I guess. But what it was to him and his team was a place where kids could understand and learn mathematical concepts the same way that a child in Paris might pick up French. A place where they could learn geometry and algebra and everything else just by interacting

with the world. They would just absorb it because it would be part of the background. It would be natural and it would be fun. There were a lot of constraints on building this idea of Mathland. Consider computers at the time were just teletype terminals, right? The computers didn't even have screens. Even with those constraints, Seymour and his team made it work, right? You can imagine them going to a school, a school that has a teletype terminal, and bringing the Logo Robot, the Logo Turtle, which was quite large at the time, phoning in to the MIT computer with the teletype machine and hooking up the Logo Robot. The kids gather around, right? They set up a wood barrier with paper underneath it, and then into the teletype machine, somebody types forward 100,

and it moves. It leaves a mark on the paper behind it with a pen. And then, you know, somebody puts, write 90, forward 100, repeat 4. And the kids gasp as the robot slowly draws out a square on the paper. This made learning geometry and Cartesian coordinates exciting. Now, this was all in the late 60s, but I had my own experience with Mathland. When I was in grade 3, far before Turing and Mr. Omar, we had these two Commodore 64 computers in the classroom. And, you know, when it was raining, we stayed inside and we'd play on the computer. Sometimes we played Carmen Sandiego.

But Logo was on there. And my friend Ben showed me how it worked. And we figured out, or his older brother had told him how to do a triangle. You could draw a triangle by going forward and then turning, going forward, like you had to get the degrees right so that the triangle would end up catching back up with itself. Once we figured that out, how the angles of a triangle had to add up, we figured that we could repeat it. We could draw a triangle, you go back to start, you turn a couple degrees, draw a triangle again. And if you repeated that enough times, now you had a spiral slowly being built of triangles going all around like a spirograph thing. And that was, it was so amazing

to us, but it took so long. We were slowly watching it draw. So we do it where, you know, you draw the triangle and you turn 90 degrees and you do it again and you get kind of like four triangles in a spiral. And then if you do less than 90, you know, the spiral gets tighter. And so we thought, well, what, what is the, you know, the spiral gets tighter. And so we thought, well, what is the, you know, the biggest one we can do? So we tried, you know, draw a triangle, just turn one degree, draw a triangle, turn one degree. But it was so slow, right? It was cool to watch as this triangle shape slowly morphed, but recess was over and we had to go back to work, you know, to working on whatever was going on in class. So we turned off the screen on the Commodore, I'm pretty sure, and just left it running with the idea that at the end of the

school day, we could go see and see what was drawn. And we were so excited about what this creation would be. But when we got back at the end of the day and looked, it was just a circle, right? If you draw a triangle and turn one degree and keep doing it, like we basically filled in every pixel on the screen very slowly by this turtle drawing a triangle. But it was fun, right? Like I still feel like I have a good understanding for why the degrees of a triangle have to add up to 180 degrees.

Because I felt it, you know, exploring with Ben and it was just a game we were playing at recess. That's the thing, right? The thing about Logo was that it had what Timymour called a low floor, but a high ceiling. Me and Ben could mess around with it, but it was also rich enough that, you know, Hal Abelson could teach an MIT geometry class using it. Seymour wanted a method to extend that concept. And so they started using Lego blocks to build things.

It turned out that the Lego company had very similar goals. Lego company cares a lot about children learning. And they wanted people to build things as well, right? So they sponsored Seymour at MIT. They started collaborating together. This was decades later after Mindstorm book, but out of this collaboration came Lego Mindstorms. I never had one, but they always looked so cool.

They were like a robot construction kit that you could program and made out of Legos. And the name Mindstorm was, of course, in honor of Seymour's book. The thing that happened is the Lego Mindstorms, instead of taking off with kids, actually found a lot of popularity with hobbyist adult tinkerers and hackers. According to Wikipedia, Lego wasn't quite sure to do about that. Maybe this was too advanced of a toy for kids, but adults used it and loved using it. But because it didn't quite meet, I guess, Lego's focus, in 2022, they canceled Lego Mindstorms. Which is seriously tragic. But when we think about technology in schools today, you know, we think about like Chromebooks and iPads and educational apps, devices and

content delivered from big companies. It was very different than the Commodore 64 that started up into a basic terminal that you could launch logo from. Very different from what from what Pepper imagined. For him, computers were not about content delivery or standardized curriculum. They were toys, right? You could take them apart. You could play with them. You could use them to design and create things. You experiment. You take risks, like playing with gears as a child or taking a car apart, turning the

wheels and imagining how they connect. You work hard to figure things out because you're absorbed in your own creative process. This was Papert's vision for how he could transform education not with these top-down chromebook instruction devices but with creative toys this is why i think this is all relevant some of papert's ideas have been put into question but i think that one thing that is very true is that if you want somebody you're teaching somebody to code they should have a project they should have something that they want to build that's fun and exciting for them, that makes it feel like play. You know, something that drives

their energy forward. I think that's the important lesson he gave us is that the way that you enjoy learning the most is with a self-directed project. Here's why this matters for learning, right? If somebody wants to learn to program, there's no better way than having, as part of it, a self-directed project that they want to build. Nothing will be as fun and provide as much motivation. And when you're learning to code on your own or taking on a learning goal that's challenging of any sort, motivation is important. So that was Papper. He is very famous. But our next stop on this learning tour is the mythical man himself, Fred Brooks. Okay, it's the 1950s. America and the world is captivated by the rise of computers, these giant hulking machines that promise to transform everything. But software is still a

novel concept. Nobody really knows systematically how to build it. And that question perplexed a bright graduate student named Fred Brooks. He was working on his PhD at Harvard, and he took a summer job at IBM. And they gave him a job, write the software for the IBM 704 mainframe. There you go, summer job. So Fred's alone in a room with this hulking computer. I don't know what a 704 mainframe. There you go. Summer job. So Fred's alone in a room with this hulking computer. I don't know what a 704 mainframe looks like, but I assume it's huge. And he struggled. The work was slow and painstaking. And after just a few weeks, he had only produced 200 lines of working code. And he knew that this wasn't fast enough, that he would never get his summer project done. I don't know what writing assembly for a mainframe is like,

but I think cognitive load is probably very high. Research today will show that one of the biggest challenges in learning to program, or learning in general, is managing cognitive load. There's just a lot to hold in your head at one time, especially if you're new to it. And if you don't have previous experience, you don't have chunks of knowledge and long-term memory

that you can hold onto. You have to try to shove it all in your working memory. This was Fred's problem, but he had an idea. Get help. Why not just recruit another programmer to work at his side? So Fred convinced his friend Henrik to join forces. So they sat together at a terminal, sharing ideas back and forth, and they began to build out the software for the mainframe. And the software, according to Fred, it took shape rapidly, as if their creativity was amplified. And in just 10 weeks, they got the summer project finish, and it was free of defects. Which sounds remarkable to me. I don't know if I buy it. But here's what I buy. Fred realized that two minds are greater than one. When they collaborated, sharing knowledge and catching each other's mistake, their potential blossomed. They went from something impossible to something that

could be done. And Fred knew he had experienced something special. A new way to write software was born. Fred recognized the power of teamwork, even in those early days, spread the cognitive load out across two people, and you can raise the bar on what's possible. This was pair programming, although I'm not sure it really had a's possible. This was pair programming, although I'm not sure it really had a name then. It was more just like getting help from a buddy, right? If I'm stuck on something, I can go talk it out with someone else. And then if that doesn't help, then odds are the two of us will gather around my machine as I walk them through the problem. But in the 1990s, some people had an idea to extend this pair program concept to its logical conclusion.

Always work in pairs. They were touting benefits like higher code quality and knowledge sharing, but they couldn't convince everybody. Most programmers were still working solo, alone in their cubicles, headphones on, trying to stay in flow, you know, totally focused, cranking out line after line of code, maybe rocking out to some metal or some EDM. Who knows? But yeah, now advocates of this newfangled pair programming appear and they tell them, you know, break your flow, take your headphones off, stop listening to Metallica and instead constantly talk out loud to a partner,

tell them what you're doing, you know, share a screen and a keyboard with them and work through the problem that way. It sounded nuts, right? It sounded counterintuitive to a lot of seasoned developers. It seemed to question the very nature of programming as an inherently individual activity. Because a heads down coding is like a personal, introvertive, you know, meditative idea who wants a constant partner. And that's not why people got into it. And if you're me, there's also a whole realm of self

doubt. I've had to debug things before with some people watching over my shoulder, who I thought were judging me, who I didn't totally trust. And I found it quite the opposite of increasing my brainpower. I found it like a coding interview, right? The cognitive load was higher because I was worried about what they were thinking. I was worried about their eyes on me. So reactions to pair programming were skeptical. There was audible groaning and eye rolling at every place I've worked whenever somebody brought up pair programming as being, you know, a magical solution. All this talk of knowledge sharing and pair flow, it sounds a bit vague and a bit touchy-feely. Where's all the data to back it up? By the way, this is all going to come together about learning. But software

pioneers exploring this practice, they could feel just from doing it that they were on to something. And so they pushed on this all throughout the 90s. At pioneering companies like Chrysler, they reported the pairs got more done in less time. They produced fewer bugs and programmers actually enjoyed their work more. The energy and pace when two developers worked in sync was palpable, they said. The pleasure in creating something neither could quite do on their own, it was amazing. It drew them in. Still, there was many reasonable questions and doubts in these early days. Productivity and quality improvements were unproven. So in 1999, researchers at the University of Utah designed an experiment to settle the debate.

I'm pretty sure they were on a team pair programming to begin with, but the experiment setup was pretty solid. They divided the student programmers into two groups, solo developers and pair programmers, and they observed them complete real-world coding assignments. The results of the experiment were clear. The pairs completed their programs faster and with higher quality. Now, the pair programming advocates could go to industry and say, look, we proved it, this works. But, you know, there's some caveats. First of all, these are students, not professionals. And they were working on toy problems, you know, not real work necessarily.

They were self-selected for which groups they got to choose if they wanted to be pair or alone. I would have picked alone. But it's also clear that they got the problems done almost twice as fast. So it took two hours for someone to solve a problem on their own. The group might get it done in a little bit over an hour. Slightly more people time, but far less wall clock time. And the programming things were, they were not just hello world. These were real projects. From there, in the early 2000s, in the aughts, I guess as they call it, pair programming finds some uptake in industry. At NASA, people claim pairing reduces defects in their complex software, which is mission critical, but they have to get it right.

Some outsourcing firms in India come forward bragging about how pair programming allows them to deliver very high quality code in short time frames. And Sabre, a major player in the travel industry, sees increases in both productivity and quality after adopting pair programming company-wide. This is what they say. So I have some strong suspicions about this always pair programming in industry idea. The pair programming advocates sometimes make it sound like this is a panacea that it fixes all problems. And, you know, I question that. The existing research shows that two devs in front of the computer get work done almost twice as fast. And that's astounding, right? That breaks Fred Brooks' famous law that you can't speed up a project by adding more people to it.

There's sort of an efficient market hypothesis argument against pair programming working, if it were true that you could nearly linearly improve the wall clock time of development by just adding more people, but keeping them in pairs, you'd expect industries such as startups where I work, where such a huge premium is put on execution speed, you'd expect pair programming to be pervasive. Anyways, that doesn't matter because today's topic is learning, right? And so far we've talked about how it's not a natural vulnerability. Everybody can learn to program. And we've talked about making an experience fun and exploratory, right? But also pair programming is an amazing way to learn. There's no question. Imagine that you were trying to ramp up on a new system at work.

Maybe it's been around forever and you've never had to touch it. And there's just so much tribal knowledge around it. All those tricks of the trade that nobody bothered writing down. They're out of date in some wiki somewhere. The experts on the team never seem to have the time to properly document things. They're two heads down on their own tasks. But if you can get one of those experts and you can pair program with them, it's like having your own personal mentor right there at your side.

Those unwritten rules, they'll explain them to you as you go. The shortcuts and the tools that took them years to build up, you'll master them quickly or quicker just by watching. When you hit some gnarly bug or some design problem, you get the benefit of their experience and working through it. It's not just having someone point you to the right area or throw an outdated wiki at you. This is learning in action in context. It's exactly where you need to learn and where you will retain so much more of the knowledge because it's directly relevant to the problem you're trying to solve. And you might be

thinking, won't I slow them down with all my questions. Don't they have things to do? But here's the thing. By explaining out loud what they're working through, they'll actually gain new insights into their own expertise and strengthen their own knowledge. Teaching someone else sharpens your own mastery. So everybody wins. Pair programming accelerates the learning curve and it closes knowledge gaps. There's actual research on pair mentoring that backs this up, which is really wild. But before we get to that, I probably should have done this earlier. Let's connect the dots here.

So let's say you want to teach someone to code. First thing is, it's totally possible. Never mind the camel humps, right? Second, the environment for play is very important. In the early stages of programming, cognitive load is very high. And it's mainly because of all the stuff surrounding programming, right? Second, the environment for play is very important. In the early stages of programming, cognitive load is very high. And it's mainly because of all the stuff surrounding programming, right? How do I install Python? What IDE or text editor do I use? How do I install some package? What's the terminal? How do I run something? I think learning calculus is probably harder than learning to code. Even if you're trying to learn something unusual like Lisp or APL or Zigg,

there's much harder subjects to learn. But what makes learning coding hard isn't the inherent challenges, but all the struggles of just getting an environment set up right and learning the tools. So probably if you're teaching someone to program, one of the big wins is just getting them past all of that nonsense. Just saying like, okay, you're learning Python or JavaScript or whatever, and you're using VS Code or this online REPL or whatever. Prescribe the environment and help them use it. Getting them there gets you to that logo-like place where they can play, where they can type something and run it. Same with when you're trying to learn something yourself, right? If you're trying to learn a new skill or get familiar with a new area, getting everything

set up is a great time to pair. You're not going to want to, because you won't even be able to compile a project or have the right version of something installed. You'll have a bunch of setup stuff to figure out, but that's the best time to get input from someone who knows the area. It's the best time to get the lay of the land. It's like Seymour going to some school

and setting up the logo turtle on the floor and the paper underneath it and some wood blockers around it. He's setting up the environment in which that learning can take place. You get all that out of the way and programming seems less hard and less impossibly far away. Okay, but let's stay focused on this one case, teaching somebody to program. I'm going to extend this later. So next thing is, let's follow Piper again. What does the person you're teaching want to build? What motivates them to play and create? That can center the learning so they don't run off in a million directions trying to learn a million things or get lost in some corridor of knowledge. Building a project is fun and motivation is important to keep them going.

But next though, right, as we learned, project-based learning, purely discovery-based, is slow. And learning Python or JavaScript or whatever pedagogical path is chosen and relates to the project is well-developed. Wherever there's like a smooth, well-trodden learning path, it makes sense to follow that, even if it doesn't totally track with the learning project. This is hard advice for me to give, right? Find a Python tutorial and have them do that, is basically what I'm saying. But I love lots of weird technology. I'd love to say like, oh, if you're building a web app, you should learn Kotlin or Rust or something like that. And of course, you need to learn my Vim,

you know, key bindings and whatever. But that's a mistake. If you want to build a web app project, learning JavaScript, or maybe python is the way to go any given beginning learning path using a standard editor and some online tools is the way to go this is the lesson of instructive teaching research right a well laid out learning plan with explained examples is the fastest way to learn if you think of learning as exploring a new territory then picking a path that's well trodden, like Python or JavaScript beginner tutorials, is like taking a highway. Whereas choosing your own path that hasn't been done before is like bushwhacking through the

undergrowth. It's much harder. So that's my overall learning advice so far. You need a project, you need a pedagogical path, and you need to pair with the person and make sure that they get their environment set up. But we still have to discuss another piece of learning research, maybe the most important, and that's mastery learning. So there's this guy, Benjamin Bloom. He's a famous educational psychologist, not a computer programmer at all, but he did an experiment that shocked the world. Shocked the world of education, that is. I'm not sure how much anyone else cared. But it became known as the Two Sigma Problem. So picture it.

It's Chicago in the 1980s, and Bloom and his team of grad students have set up an experiment with students at different Chicago public schools. They took a group of average students, randomly selected, and they had them learn a curriculum through conventional teaching methods, which is like lecturing, testing, some group work, etc. Standard classroom stuff. Another randomly selected group from the same pool of students

learned the exact same curriculum, but with one-on-one tutoring. Each student worked through problems on their own, but with a tutor who gave them immediate feedback and then advanced them to the next problem set when they had demonstrated that they had mastered that concept. The results? The students with tutoring vastly outperformed the others by two standard deviations, hence two sigma. It was like taking an average class and transforming them from the 50th percentile to the 98th percentile, making every kid in the class the best kid in the class.

This is, as far as I can tell, the most important result from education research. It's the biggest effect size found. Practically, it's like making everybody the very best student in the class. And it caused quite a stir, as you can imagine. The notion that personalized tutoring could boost grades so dramatically, it seems too good to be true, but also hard because you can't give everybody a tutor. It's the complete opposite of the camel has two humps paper, right? It says that you can get anyone to the very top level if you sit them with a mentor who helps them master every process

step-by-step. The study design came under a lot of scrutiny. Follow-up studies have been somewhat mixed. Some showed similar major two-sigma gains from one-on-one tutoring and mastery learning. Some found to get the two-sigmas, sometimes students and tutors had to spend more time really slowing down and working through difficult areas. So yes, students became the absolute top of the curve, but it took a lot more time investment than a standard learning approach. Other studies showed more modest improvements, only one standard deviation. But one sigma, one standard deviation is still huge. And the core idea has held up. Guided practice with a tutor working you through works so well. The camel has

zero humps, or the hump is really compressed to one side of the graph. I don't really know the, I need a better term. The metaphor is breaking down here. We see this play out every day in the world of coding education. We see when successful boot camps pair students with instructor mentors, right,, you know, a coach who intensively provides them feedback and gets them up to an astounding level of coding proficiency. And I've seen it most often when a senior team member spends a lot of time with somebody advanced stuff and bring in somebody junior, work with them directly, assisting them, working them through things and catapult them up to a level that took people decades to get to. And so that's your answer for how to teach someone to code. All the stuff I mentioned, right? A project that excites them, a tutorial series they can work through, but most

importantly, you pair with them through the hard parts, work it through. The mentors in Bloom Studies knew the material and made sure the students understood it step by step, but they weren't the most amazing mentors in the world. You could do this. You could teach someone better than the best instructor class-led program out there because you'd be a personal mentor. This isn't available for a teacher teaching a class.

This is personalized learning. Think about that. If somebody wants to learn, you can teach them to a level higher than they could get in a class if the two of you can take the time. That's my big lesson today. I don't know how to underline that. It's taken me a long time to get here, but that's what I wanted to say, right? If somebody has something they want to build, right, you can find learning materials, you can help them set up their environment, and you can pair with them and help them work through the hard problems. And they'll get there. That's it. And here's the trick. It's taken me a while to

get here. But this doesn't just apply to teaching someone something you know, it doesn't just apply to teaching someone how to learn to code Python or JavaScript. The same process applies to learning in general, for helping others, but also for helping yourself. The thing I said about the Campbell study is that it's wrong, right? That people can learn things that they want to learn. And that's something you need to tell yourself when you want to learn something and you get stuck. You can do it. It might just mean slowing down on the hard parts or backtracking, finding the piece of knowledge that you're missing. You can do all this on your own. The hardest part to do on your own is the mentoring,

obviously. You could try to find someone who knows what you want to do and maybe ask them for help, ask them for environment setup. You can seek out someone who knows the area you're learning, ask them to pair with you when you get stuck. But there's one more way, right? You don't need to necessarily find an expert, but if you can, that's amazing. But Bloom's two sigma approach was extended to peer tutoring and peer tutoring. Instead of a mentor, the learners each taught each other back and forth. You pair up with a peer. Basically, if you want to learn something hard, you find somebody else who also wants to learn it. You guys work through it together.

You put together a combination study group and pair programming group. One of you learns a topic and then teaches it to the other, and then back and forth, and you pair with each other on it. Education research says if you do that, you won't get a two sigma increase, but you'll get one standard deviation better than traditional learning instruction. Still an amazingly effective research result, and you don't need an instructor. The two of you can hill climb through the toughest material given time. Not to say that learning is not hard. I just want to say that it's possible, and the best way to do it is like that.

Be motivated, have a project, but have a peer that can pull you up and that you can pull up. You each learn by teaching each other. So this is what I found looking into the research on how to learn, how to learn coding, how to learn skills in general. And it's wild how fast you can learn when the conditions are right. Learning's hard, but when you're doing it, the progress you make is astounding. When the conditions aren't right, many people stagnate, right? If you're good enough to do your job,

you'll just stay at that level for decades. If I think back to that class, my grade 10 class on Turing, it's hard for me to know whether I loved it so much because of the programming or because of the learning structure, right? Me and Jason were peered up, right? We were teaching each other how to build back and forth. We had Mr. Omar there to help us set up our environment, and we had other kids in the class that we could learn from. We had a project that we were working

on, and we had a learning curriculum, you know, and we had a learning curriculum you know if we needed to learn sorting or something like that strong wire might jump in and explain bubble sort but mainly we were learning from each other and it was exhilarating and hard did i get into programming because of how much i enjoyed that learning method in that class yeah probably if there's one thing all this research has taught me it's that that learning is fun, frustrating and hard, but just an exhilarating experience. So that was the show. Thank you to Bob and Brandon and the supporters

who helped me with feedbacks on parts of this episode. And thank you if you made it listening this far. I know it is a bit of a journey to get to where I wanted to get. But I hope you found this interesting. I hope it can inspire you to tackle some learning challenges or to teach some others what you know. If you want to get more co-recursive content, including occasional sneak peeks of what I'm working on,

join the supporters group. Link in the show notes, but it's co-recursive.com slash supporters. Also check out my newsletter because in this month's newsletter, I cover a related question. When should you start a learning project? And when should you stop one? These are tricky questions that I often get stuck on. And if you want to form a learning group,

the supporters group might have people like you who might be able to pair up and work on something or just join the podcast Slack channel. I know there's at least one learning group that's happening there. Maybe others will form. And until next time, thank you so much for listening.