 As Tom mentioned, I'm Allison Captor. This is places you can find me on the internet, Twitter and GitHub and so forth. I work for Dropbox on the desktop client team. The desktop client is written almost entirely in Python. There's some C and C++ in performance sensitive areas, but it's really more Python than you might expect. The server for that matter has also got a lot of Python in it. I'm not gonna talk too much about my work at Dropbox in this talk, but if you're curious about that, please come find me later on in the day. I would love to talk to you about that more. So before I joined Dropbox last year, I spent two years working in a company in New York City called the Recurse Center, which you may know by its former name, Hacker School. And the Recurse Center is sort of like a writer's retreat for programmers. The idea is that people like you and me, who already know at least some programming, go and spend three months working on whatever is interesting to them. So very often we'd see people who had spent 10 years writing Java, come spend three months learning Haskell, or who had just finished computer science degrees, but felt like their programming wasn't quite where they wanted to be, come and spend three months learning Haskell. I'm kidding, there was more than Haskell to it, but that was particularly tempting to people. There's almost no structure to the Recurse Center program. There's no deadlines, there's no teaching, there's no assignments. There's basically nothing to enforce that anyone makes the most out of it. So it was an experiment in unstructured education for adults. And my role as a facilitator was to make sure that people could make the most of that disorienting level of freedom. People who came out of traditional educational backgrounds and traditional jobs very often didn't quite know what to do with that. So I would work with people on goal setting and help them make the most of the experience. So one of the things that we thought a lot about at the Recurse Center was how to get the most effective learning experience possible for adults as well, for adults and for programmers. And so today I wanna talk about some of the research into effective learning and how all of us in this room can apply that in our daily lives as programmers. So there's kind of two pieces to this talk. The first set is about research around mindset. Some of this may be familiar to you, but there's some that I think definitely won't be. And then the second part is about particular strategies that you can use. So I'd like to ask everyone to take just a minute and think about what you want to get out of this talk. Here are a couple of possibilities. You could want to learn something new about how you could be as efficient and effective in your job as possible. You might wanna hear about how you can be a better teacher or a better mentor to junior engineers. And you might wanna hear about how you can make institutional change in your organizations to sort of set up a better environment for these kinds of things. All of those are useful goals for this talk and I'll touch on all of them. However, I do wanna challenge you a little bit to consider these strategies mostly for yourself. Because I think when I hear about these very often, it seems obvious to me that other people should be following these strategies, but it's not necessarily obvious that I myself should. And I'll come back to that tension a little bit later on. So let's talk about the first key to effective learning. The sociologist Carol Dweck has done a ton of really interesting research into how people think about intelligence. And what she's found is there's sort of two frameworks for conceptualizing intelligence. One of them is the fixed mindset, which holds that intelligence is a trait that people have in some fixed amount and they can't really affect how much of it they have. And the other mindset is a growth mindset, which says that intelligence is something that you can work on and something you can develop with effort. And Dweck found that a person's theory of intelligence has a huge impact on how they respond to challenges, what sorts of choices they make, their cognitive performance and even their honesty. So I'm gonna run through a couple of the most interesting results from her work here. The first interesting result is that this framing impacts how people view effort. If you have a fixed mindset where, and so you think that people are either smart or they're not and they can't really change that, people also tend to believe that if you are good at something then it should be easy. And conversely, if something is not easy then you're probably not good at it. That is a fixed mindset view. People with a growth mindset tend to believe that you need to exert effort and work hard in something to become better at it. So there are studies that show that people with a fixed or a growth mindset will choose to either exert effort or not exert effort, depending on the mindset that they have. The second interesting result, and this is probably the most famous, so you might be familiar with some of this. So Dweck and her collaborators showed that giving students different kinds of praise significantly impacted their performance. So in this study, Dweck and her collaborators gave students a series of problems. And after the first set of problems, all of them did pretty well. And half of the students were told, wow, you did really well on those problems. You must be very smart. And the other half of the students were told, wow, you did really well on those problems. You must have worked very hard. Then they got a second set of problems where everyone did badly because they were much harder. And then they got a third set of problems that was more like the first set, back to the easier level. So they found a bunch of really interesting things from this. The first aspect of the experiment is that in between the first and the second set of problems, right after the praise, they asked students what kind of a challenge they would like to do next. And in practice, everyone got the same harder problem set, but this was a sort of hypothetical exercise. And they found that the students who were praised for being smart were much less likely to choose a challenging set of problems next. And among the students who were praised for working hard, almost all of them chose the harder challenge next. So that was the first part. The second thing that they looked at was how students performed on the third set of problems, which was about the same as the first. And they found that students who were praised for being smart did significantly worse on that problem set. And students who were praised for working hard did slightly better on that one than they had on the first. So for the students that had this smart's praise, when they hit the wall in the second problem set, they weren't able to recover for the third. And after this, they had all of these students write letters to pen pals in another school, saying, oh, we did this cool study in school and here was the score that I got. And they found that almost half of the students who were praised for intelligence lied about their score. And almost none of the students who were praised for working hard were dishonest in that way. So what's fascinating about this is how subtle this difference in praise is. I think I almost wouldn't hear the difference before reading this research, that saying, oh, this is great, you must be so smart, or, oh, this is great, you must have worked so hard. Like, they sound really similar, something that I would say to another person or that people would say to me. But instead, when you're told that you're smart, you work really hard to preserve the appearance of being smart. And when you're told that you work hard, you preserve the appearance of working hard, and the most effective way to do that is to actually work hard. So another study looked at what happens when students faced a temporary period of confusion. So in designing this study, Dweck and Her collaborators wrote up a short course on psychology, a booklet, and then a series of questions to following it. And some of the booklets had a really confusing passage in there that just didn't make any sense. The confusing part wasn't on the quiz, so students could master the material if they just totally ignored that confusing point. And so the researchers wanted to see whether students would be able to recover from that confusion. And they found that students with a growth mindset mastered the material about 70% of the time, whether or not the confusing passage was in the booklet. For students who had a fixed mindset, if the confusing passage was not there, again, it was about 70% mastery. But if there was a confusing passage in the booklet, then the mastery fell to 30%. So those students were not able to recover from this period of being totally bewildered if they had a fixed mindset. And I wanted to put a section of this confusing passage up there, because this really resonated with me. So here's the passage in this booklet about psychology. How can one best describe the nature of people who will most of all be that way, which will make the imitating of others happen most often? Is it that these are the people we want to be like because they are fine, or is it that these are the people we want to be liked by? Raise your hand if you've ever read documentation that sounds like this. Yeah, absolutely. You're sitting down in the new project, and you're like, but what is it? What are you talking about, right? So this happens all the time when your docs are written by experts for beginners or it's out of date or something like that. So it is a critical skill for programmers to be able to push past things that sound like this. So programmers need a growth mindset. The things that a growth mindset helps you with, like response to confusion, recovery from errors, picking new challenges are all things that are much easier when you have a growth mindset and much, much harder when you have a fixed mindset. Now, sometimes when people hear this research, I think the fixed mindset almost sounds like a straw man. Like, does anyone really believe that intelligence is a totally fixed trait and can't be changed? But I think it actually is fairly pervasive in the tech industry and in programming, and I'll have a couple of examples to show that. How many of you have heard of the idea of the 10x engineer? Right, so this is the idea that some engineers are just an order of magnitude more effective than others for some definition of effective. And there's lots of critiques of this framing, but sort of setting that aside for a moment. If you believe in the 10x engineer, do you think that that person was born as a super effective engineer or did they get to be 10x, 1x at a time? And I think very often in kind of the popular framing of this, the 10x engineer is set up on a pedestal as someone that other people cannot become and very often is approached from a fixed mindset perspective. Another case where we see this is with hero worship. So Julie Pagano gave a great talk at Picon 2014 on imposter syndrome and one of her suggestions for how to combat imposter syndrome is kill your heroes, not literally. So don't put other programmers on a pedestal, don't say that person is so different from me, right? And fixed and growth mindset is really useful for this framing as well. So if you have a programming hero, do you think that that person is totally different from you or do you think that you could become more like them? And if you don't think that you could become more like them, then that's some evidence of a fixed mindset. So I would argue that yes, this mindset is in fact, quite prevalent in the tech industry. So hopefully by now you're convinced that a growth mindset is much more useful and effective for programmers than a fixed mindset. So the next question is, is this actually malleable? Can it be changed? If you have a fixed mindset, are you stuck there? And the answer is, heck yes, you absolutely can change a fixed mindset into a growth one. And in fact, in lots of Dweck studies, the way that they experimentally induce a fixed or growth mindset in really simple ways. So the praise study is one example, like this one sentence changes the student's behavior. And other ways that they induce a fixed or growth mindset is they have students read a paragraph about Einstein or something and at the end of the paragraph it says because he worked very hard because it was in his DNA, that sort of thing. And so it's absolutely malleable. So how do you change a fixed mindset? And I think some of the time, the challenge is just in identifying the fixed mindset. And once you hear yourself say the words, oh, I could never learn physics, it's pretty obvious that maybe that's not actually true. But other times it's a little bit harder to root out. So here's a couple of flags that I use to identify fixed mindsets. Now if you're on the lookout for places where your mindset might be fixed or you might have a fixed mindset with certain aspects, listen for sentences that start with I am or contain the word just. So I'm not good at CSS, I'm not a people person, some programmers are just faster than others, these are all fixed mindset types of words. And obviously you can start sentences with I am that are not indicators of a fixed mindset, right? But if you're on the lookout for this, you can kind of use these as a yellow flag to indicate that it's something you could examine more closely. I just as an aside, the I'm not a people person example is in fact supported by the research. The Duak and her colleagues also did a study on making friends and social aspects that show that it does hold there too. Okay, so once you've identified a fixed mindset, how can you go about changing it? And here are four strategies. The first one is you can reframe praise and success. So if someone says to you, wow, great job on that project, you're so smart. You can turn it around for yourself and say, yes, I did do a great job on that project. I worked very hard and used an effective strategy. And you don't necessarily have to do this out loud, right? You can just do it yourself. And you can use the same techniques for successes and accomplishments. So if you had a project that went really well, you can say, okay, yeah, that project went really well. Here was the strategy that I used and I should do that more instead of saying, yeah, that project went well because I'm awesome. So of course, the flip side of this is also the case. You can also reframe failures that you have. And a huge part of fixed or growth mindset is how you respond to failures and setbacks. So what's your self-talk when you face a setback or you don't get something that you wanted? If you're saying maybe I'm not cut out for this job after all, you're spending a lot of energy and that's definitely a red flag. So instead, you can ask yourself what you learned from those unsuccessful attempts and what strategies you could have used instead. And it sounds really cheesy, but this does in fact work. The third way that you can change a fixed mindset is to celebrate challenges. So how do you react when you're forced to struggle when you're really stuck on something? And this was something that I was really consistent about as a facilitator at the RecurCenter. So someone would sit down next to me and they would say, I have this weird Python bug. And I would say, awesome, I love weird Python bugs because first of all, that's definitely true. And if you have weird Python bugs, let's talk about them. But more importantly for this context, it was emphasizing to the participant that finding something where they struggled was an accomplishment and that was intentional and that was a good thing for them to have done that day. So as I mentioned at the RecurCenter, there's no deadlines and there's no assignments. So this attitude is pretty much free. And we say, oh great, you get to spend a day chasing down this weird bug and flask, how exciting. And now at Dropbox where we have deadlines and the product to ship and users, I'm not always uniformly delighted about spending a day on a weird bug. So I am sympathetic to the sort of reality of the world where there are deadlines. However, if I have a bug to fix, I'm gonna have to fix it anyway. And so sort of being very grumbly about the existence of that bug isn't gonna help me solve it any faster. So I think even in a world where deadlines loom, you can still apply this attitude. So the last strategy for changing a fixed mindset is to ask about processes. So like many of you, I work with some great engineers and sometimes I will try to fix it, solve a bug and will not be able to and then one of them will get the answer right away. And one of the things that I'm trying to be really disciplined about is to say, oh cool, how did you do that? And especially when I was new in my company, the answers were really illuminating and sometimes it was something like, oh I looked in this source of logging that I didn't know existed and that's where the answer was. Like oh, that's good to know. And now that I've been there for a little longer, that happens less often. But I still very often learn techniques that I wasn't using as much or strategies or like here's some detail and why my strategy had not succeeded. And this is a much more useful strategy in the long term than saying, oh of course that person got the bug, they are a wizard, full stop. So I wanna spend just a minute talking about imposter syndrome. I think Dweck's research is really interesting in that context and really doesn't come up often enough in the discussion of imposter syndrome. If you're not familiar with it, I haven't heard this before, imposter syndrome is the feeling that a lot of people have that you are secretly a fraud who will be discovered at any moment. Hands up in the room if anyone has ever felt imposter syndrome in their career. Yeah, okay that's like 80% of you, that's great. And I definitely have as well and it sucks, it's so painful and it's also really bad for your career because you're much less likely to take chances and to look for new opportunities to grow and that sort of thing if you're worried about getting fired from the job you already have. And the proposed solutions for imposter syndrome very often seem to center around confidence. Where it's like, oh, well, if you feel like you're not qualified for the job you already have, maybe you should be more confident and then that would be fine. Which sometimes it's like, well, don't feel that way. It's not very helpful as advice goes. But even when it's more nuanced than that, there's often this focus on confidence and past accomplishments. But so here's the catch. Dweck's research shows that confidence does not predict how you respond in the face of failure. So in this study, Henderson and Dweck studied students who were moving from elementary school to junior high in the United States. So that's like a significant transition around age like 11 to 12. I'm not sure what the Kiwi equivalent is. And they asked the students to assess their confidence when they were still in the younger grade. And then they tracked their confidence and their academic performance as well as their mindset about their intelligence in their junior high years. And what they found was that confident students with a fixed mindset suffered academically. And students with a growth mindset tended to thrive academically regardless of their confidence. And this is in contrast with a lot of research that shows that there is in fact a correlation between confidence and success in some endeavor. And the angle that Dweck is looking at here that changes that, is she's saying that if you were doing something new, then confidence and doing something old doesn't help you with your new task. And in particular, confidence doesn't help you respond to setbacks or failures. So if you hold a fixed mindset, basically any moment is a chance to prove that in fact you can't hack it. So running into challenges is really stressful in that context. And by contrast, if you have a growth mindset, then struggling or having a challenge is the way that you grow. And that's much less scary. And the second related point that Dweck found is confidence, so not only does confidence not predict resilience in the face of failure, but a history of successes also doesn't predict resilience in the face of failure. So this is really exciting to me actually. Because I think this is a much better framework for how to think about imposter syndrome. And basically if you're holding a fixed mindset, you're going to be really stressed and afraid at any moment that you have to struggle. And we're programmers, so it's mostly struggle, right? It's not a struggle all the time. And with a growth mindset, you can sort of enjoy struggling and enjoy working on something that's really hard. And when your identity isn't being threatened by a particularly tricky bug, it is much easier to focus on the bug when you're not worried about also getting fired and being a fraud. So you free up those cognitive resources to actually work on the task at hand. So again, if you believe, for example, that some people are not cut out for programming, you can spend a ton of time and energy looking for validation and evidence and all sorts of reasons why you are in fact one of the ones who can make it. So instead of doing that, just dismiss the idea that some people can't do it and move to an idea where everyone can increase their skill by exerting effort. Right, so having a growth mindset makes you more resilient to failure, makes it easier to exert effort, makes you more likely to sign up for new challenges, all things that are super useful for programmers. If you'd like to dig more into the details of this research and also see some of the findings that I didn't have time to cover today, I highly recommend the book that Dweck wrote, which I have here called Self Theories. Self Theories is a collection of essays that summarize many of the major points of her research. She also has a book called Mindset, which is written for more of a pop science audience. So if you're looking for detail in sort of a technical level, I recommend this book instead of Mindset. Mindset I think is a little bit of a higher level, sorry. Okay, so one of the themes that comes up again and again in Dweck's research is that mastery-oriented people, those with a growth mindset, are really focused on strategies and not just on outcomes. So in the second half of this talk, I wanna spend a few minutes talking about strategies for effective learning and these again are all supported by research and many of them are counterintuitive or pretty different from predominant strategies, at least that I was taught in school and perhaps that you were taught as well. Okay. Much of what I'm about to discuss is drawn from this great book, Make It Stick, by Peter C. Brown and others. And they aggregated a ton of research on effective learning strategies. Most of this research is done on students and in classrooms, but I think there's a lot that we can apply to our lives as programmers as well. So the premise for this book that you have to accept for any of it to be worthwhile is that learning is an acquired skill and you can get better at it with practice. This probably sounds familiar to you at this point in the hour, so I won't belabor this point, but I do think it's worth noting explicitly. So the question here is, okay, what are the most effective strategies for learning new things? And there are three findings in particular that I find pretty counterintuitive and surprising. The first finding is that engaging in what the authors call effortful retrieval is much more effective than just passively reviewing the material. So effortful retrieval is anything that makes you work to think of the answer. So flashcards are a really easy example or anything where you have to draw the answer out of your brain, not fill in the blanks, sorts of tests, that sort of thing. And that's much more effective as a learning strategy than just rereading your notes or rereading the material that you drew from. And this is pretty surprising because rereading notes or rereading the textbook is a really common way for students to study. And certainly it was a way that I studied when I was taking courses and is still a way that I try to learn things now if I like some man pages I just reread almost every day. What is the order of the arguments to LN? I always forget. And other thing that was really interesting from this study is that rereading gives you the feeling that you know the material without actually teaching you the material. So you end up with what the authors call the fluency illusion where you're kind of reading through and you're like, yeah, yeah, yeah, I got this, I got this, I got this. And then as soon as you close the book, you're like, wait, I don't actually have any of this. So effortful retrieval, something that requires you to do some work is a much better strategy. The second finding is that spaced practice is more effective for learning short-term and long-term than mass practice. And there are three different ways of spacing out a practice that authors cover. The first is spacing it out in time. So there's a study here that having four one-hour sessions over the course of a month was more effective for medical residents learning a new skill than having one four-hour workshop. The second way is varied. So doing different kinds of the same sort of style of exercise. And this one, they had two groups of eight-year-olds tossing beanbags into a bucket. And half of them were throwing the beanbags from three feet away. And half of them went back and forth between four feet and two feet. And then after a couple of weeks of that, all the kids got tested on their ability to toss a beanbag into a bucket from exactly three feet away. And they found that the students who'd been doing the four-foot and two-foot exercise did better than the three-foot exercise. So varying up the practice was better than even when the test was on the single thing that the students who did not vary their practice did. And the third form is interleaving different kinds of exercises. So in this study, they had students calculating the volumes of geometric solids, the spheres and cylinders and so on. And they found that students who did sort of a shuffled exercise of all the different kinds of volumes performed better on later tests than students who did 10 cones and then 10 spheres and then 10 cylinders and so on. And in interleaving, part of what you're training there is the skill of identifying what kind of a problem this is rather than being given the kind of problem that it is and just applying the formula or what have you. The third really interesting finding is the difficulty is usually desirable. And so the authors found that things that were hard to learn were more likely to be retained. And they found that this was true even when the difficulty was something really dumb. Like in one of the studies, the reason why the thing was difficult to learn was because it was in a really blurry font. They found that after struggling to read this blurry thing, people retain the underlying material later. The related point for this is that making errors is usually desirable. So for a long time in the US educational system, there was this idea that you can't let a student make an error because then they will remember the error instead of the right answer. So don't let them guess wrong. And it turns out that this is not in fact the case. And if you struggle on your own to come up with an answer and then are corrected, you're much more likely to remember the correct thing. Not all difficulties are desirable, despite the fact that a really wide array of difficulties are. And in particular, a difficulty that is not desirable is anxiety about performance. So this is really consistent when we saw out of Dweck. People who are anxious on a test do much worse in part because you're spending all that cognitive load worrying about other things. So here's the challenge with all of this, all these strategies. It feels really hard. You constantly feel like you're struggling because you constantly are struggling. You don't feel like you're being efficient. You don't feel like you're being effective. And you're making things harder on yourself. And so the consequence of how bad all of this feels is that people don't do it and they fall back to less effective learning strategies even after they've been specifically instructed in how these strategies are more effective. So you have to expect some amount of struggle with this. That is in fact the intention and like the goal. The other consequence is when you do like mass practice, so lots of problems in a row cramming for the test, you can feel the rapid gains but then you can't feel the rapid forgetting. So this brings us back to the growth mindset. If we don't fear struggle, if we're not seeking to avoid it, then it frees us up to be using these more effective strategies. Okay, so for us and our daily lives as programmers, how can we implement these? So one bit of low-hanging fruit and effortful retrieval is like literally flashcards. And I'm seeing a lot of skeptical faces and I'm so sympathetic to that. This was one where I was like, yeah, of course everyone else should use flashcards but not me, no. And I studied physics in college or in university, I should say. And I came out of that with the view that like, anything that can be learned from flashcards is like probably not worth learning, right? Like let me derive it from first principles, otherwise it's not worth my time. And in fairness in like my physics courses, not much that could be learned from a flashcard was super worthwhile. Like that wouldn't get you very far. But it would get you like the very lowest foundation. And so currently in my experience programming, there are not a ton of cases where like, rote memorization helps you that much. You need like this towering edifice of understanding and conceptualization. But if you don't have the underlying facts, you cannot build your tower of understanding. So particularly for certain kinds of new things where it's like I need to be remembering them to learn the implications, I think having a flashcard-like system is actually pretty useful. Other ways to do effortful retrieval. Take guesses. So I joked earlier that I can never remember the order of arguments to make a sim link. One thing that I can do differently here is I can actually guess what it is and then go look it up. And I can also tell you from experience that if you reverse the order of arguments making a sim link, nothing bad happens. This is obviously not the case for all of your shell commands, so know what situation you're in. But if you're in a situation where the cost of making an error is basically free, go ahead and take a guess. The other thing to do here is to debug systematically. So if you're trying to find out a bug in your program, make sure that you always have a working hypothesis for what the bug is. And you're constantly either validating or invalidating that hypothesis based on your experiments. If you work on an infrastructure team, you can conduct war games or mock outages, that sort of thing. And finally, you can do this in conversation, like here at this conference. So I was talking to someone the other day, and he said, are you familiar with graph isomorphism? And internally I was like, yeah, I know those words. Yeah, okay. And it's really, really tempting there to go, oh yeah, yeah, definitely sure. And instead I tried to actually check my understanding and I was like, yeah, sort of. It's like the research into how graphs are like each other, right? And he was like, yeah. And in fact, here's all this nuance, that was his PhD topic, so lots of nuance there. But it was really tempting in that moment to be like, oh yeah, sure. And you lose the chance to first of all do effortful retrieval and second of all to actually get feedback. So I encourage you to do that as well. Implementing space practice is also pretty straightforward. So you work on different kinds of problems. You work on the same problem over time and you interleave different kinds of problems together. And this is really good news for anyone who's got a side project. How many of you either don't program for a living and work on something on weekends or just do program for a living and have something you do not in your day job? Yeah, a couple of hands. Some of you would like to do more of not in your day job. So very often people say that it's hard to make progress on their side projects because they only get to work on them for like two hours on a Saturday, right? And this is definitely true. But what's interesting about this is in the context of this research, all of the energy that you spend reloading all that context and trying to remember what the heck it was you were doing last Saturday is good for your long-term learning. So you're more likely to retain later on the thing you really had to work to retrieve. So one thing that's really interesting to me here is how deeply this conflicts with sort of the conventional wisdom around engineering time. And at Dropbox, like a lot of places, we try to be really thoughtful about maker time and giving engineers uninterrupted blocks of time to work on things. There are social conventions around interrupting people who are wearing headphones. There's a lot of thought given to context switches and that sort of thing. And what this research shows is that the context switch is not completely wasted. It definitely does slow down your immediate progress. And so for any context where what you're most interested in is getting the product at the door, getting the thing finished, there's a real cost there. But for your long-term learning, the context switch can be really productive. So there's a little bit of a balance here that I didn't really appreciate before hearing about this. So it's not just a dead weight loss to have to context switch and then have to pick something back up later. Implementing difficulty. Put all your documentation in a really unreadable font. No, I'm kidding, don't do that. Right, so this is sort of funny to me because I think there's plenty of difficulty already in programming. We don't really have to work too hard to seek it out. Implementing the sort of space to make errors is much more interesting. For one thing, making an error sort of implies that somewhere in the line, there's a feedback loop. And so if you take a guess and never find out if it's right or not, that's not very useful to you. So then you can sort of get into ways to get feedback, ways to create feedback loops for yourself. And that depends a lot on the context and on your job and that sort of thing. There's some evidence that reflection on how the week went serves as a useful feedback loop in this context. Also, of course, things like post-mortems, like formal feedback, like code review and so on. The other thing that is really interesting here is that it's much easier to be willing to make mistakes if you're in a context where people aren't going to be jerks to you because you made one. So you see this a little bit in like blameless post-mortems. You're gonna admit to a mistake if you're not gonna lose your job about it over it. And the other thing that is sort of interesting in this context, so at the recurse center, there's a set of social rules. And the social rules are mostly around not accidentally being a jerk to each other. And it's much lighter weight than a code of conduct. If you break a social rule, someone's like, hey, you broke that social rule and that's the end of consequences, right? There's never any punishment for it. And one of the social rules is no feigning surprise. So if someone says, oh, who's Richard Stallman? You're not allowed to say, you don't know who Richard Stallman is? He's the only thing that you're doing is celebrating your knowledge to the expense of this other person. So having an environment where small and unimportant mistakes are welcomed can also go really far on this. Okay, so as programmers, can have a growth mindset to be more effective. We can engage in effortful retrieval as much as possible. We can space out our practice in time and in type of projects and by interleaving different sorts of projects. And know that most difficulties are desirable. All right. Some thanks to folks who gave me early feedback on this talk and to the KiwiPyCon organizers for inviting me. I'm gonna take some questions now, but while I do that, I'm gonna put a pop quiz up here and you're free to totally ignore it. But if you thought that this research was interesting and you wanna remember it later, I encourage you to engage in some effortful retrieval by answering these questions to yourself right now. Thank you. I'll be running around taking questions. I've got one of these stupid things now so at least make me work for it, okay? Someone had a hand up at some point. I have a half formed question about, is there any research about whether teams of people who could be in a growth or a fixed mindset whether the growth of fixed mindset might work in the matter, thinking of them as a team and how that team approaches its problems. Are they always doing things the same way or is the team who maybe growth people always and centered to use the same technologies rather than finding new solutions? Yeah, that's a really interesting question. I'm not aware of any research that operates at a level other than individuals, but I would love to see that, yeah. Thanks for your talk. I also read this book by Keraldoic and I'm a father to twin girls and once I start using these strategies in my parenting, I just wanna reiterate that it really changed my guilt confidence in how they were tackling the problems in day to day life's it was really good, that's the point of the site. Yeah, the research is actually kind of terrifying, right? Because you're like, oh, do you tell your children that you're smart and you're ruining them? Like, oh no. But yeah, it's interesting how much you could drive this and there is some, I didn't have a chance to talk about this, but there is some research in this book that's covered about gender discrepancies in particular and the way that high achieving girls are more likely to have a fixed mindset and less likely to be willing to risk failure when they hit something hard. I mean, I think that probably resonates with a lot of the women in the room that probably had that experience. I have two questions. Firstly, I'm guessing that a fixed mindset and a growth mindset is not binary, so it's more of a grayscale, so that's my first question, is it grayscale? And my second question is, is it possible to have a fixed mindset in certain areas but have a growth mindset in a completely different area? Yeah, so your first question is this, in fact, a spectrum? I think it probably is, that would be sensible. For purposes of this research, there's classification into a binary model. I'm not precisely sure where the line gets drawn. And for some of these cases where there's experimental induction of a fixed or growth mindset, if someone has a strong growth mindset going in and then you tell them that they're going to be, you know, that this test assesses how smart they are forever, you'll end up in like a little bit of a moderate place. Yeah. And your second question, is it possible to have a fixed mindset in some areas and a growth mindset in others? Absolutely, yeah. And I think one that is most common for programmers is to say, sure, I can learn and grow a lot in my programming skill and also I'm never gonna have, I'm never gonna be socially smooth. This resonates with a lot of people, I think. And then there's all sorts of areas completely divorced from that. So, you know, like your hobbies or your sports or whatever those things are. Yeah, definitely. Hey, thanks very much for your talk. I found it really interesting because I'm very aware of the fact that through my first years of my computer science degree, I had a very fixed mindset. And again, I think it's that kind of like, there was that gendered nature to it, like the high achieving girls in the class, we all kind of went through this, which we'll plead with other people too as well. And I was wondering, for our kind of first year's programming courses, would you have any advice on a scale getting kind of encouraging a whole, an entire course full of first year students to have more of that growth mindset? Because a lot of people come in from school with a fixed one and it can be really damaging in those first year courses, but you can't really chat to them about this stuff quite easily. Yeah, are you a TA in this context or are you a professor? Very sometimes teaching assistants, sometimes lecturers, sometimes. Sure, so if you're a lecturer or you have a chance to get up in front of the auditorium, I think you can just say this, right? So like, programming is a skill that you can get better at with effort. And even though that it doesn't sound like it would convince people, the study shows that in fact that does make a difference. The other one that's really interesting is there's a study on a values exercise that shows having women in particular write down their values before they enter a context where they experience stereotype threat can significantly improve their performance. And the basic theory here is that if you are not having your, if you're saying, oh, I'm a programmer and then your programmer identity is threatened, that's really painful and difficult. But if you have this, if you've done this values exercise to be like, oh, I'm a programmer and also hear these other things that I value about myself, then the stereotype threat is not so strong. So yeah, if you look up values exercise and the results are really dramatic, particularly for women and for other people who are marginalized in that context. It doesn't hurt the men. Hi, really great talk. I'd just like to say that we, I did a performance music degree in Trombone and the same thing happens in music. There's this really fixed idea that people are just born musicians or they're not, you know, oh wow, they're so talented, they must be amazing, you know, they must be in the genes. It's just, it's not, it's really that 10,000 hour thing that Malcolm Gladwell was talking about. I forgot my question. Yeah, thanks for sharing your experience in music. I think there absolutely is a lot of that attitude there. Like, oh, some people are musical geniuses and you can't become that if you're not already. And there's also that interesting aspect of the response to hard work. Like how do you feel about exerting a lot of effort? If you have this growth mindset, you feel really good about it. If you have a fixed mindset, you maybe think that you should be able to play the Trombone without working very hard, which is my understanding that that doesn't actually work out that well. So this is really the nature versus nurture argument all over again, is it? I wouldn't characterize it that way, in part because I think that the mindset is mostly driven from the individual and less from, you know, parents or environment. Which is part of why I think it's so important to think about this research from the context of ourselves and our own lives and challenges and less from the context of our students or children and that sort of thing. So there certainly is an aspect of rejection of the nature argument that people are changeable, that you can increase your skill. But I think this pulls a lot of the ability to change onto the individual and less onto the environment or context. So you said before that it was more effective to have a lot of small sessions rather than one big session, which I find when I teach my kids that they want small sessions and not enough to keep forgetting this next day. So sometimes maybe two hours is better than one hour. But how do you find a balance? Yeah, that's your question. So the cost here certainly is it takes time to reload the context. I think the most important thing here is to have a view of their learning and forgetting other than when you're teaching them. And so I'm not sure what the best way for you to do that is maybe you can have like, you know, take them quizzes or something like that or just play with the session length until you find something that, or they like walk in the door still knowing what they're doing. It's gotta be more time. I really love the idea of if you don't know guess because I think that ties to quite a lot of the other keynotes about education. I think the best thing about Python is that because it's a scripting language and you can pull up the ripple, you can guess if you can't remember how to do that and the barrier to getting that wrong compared to say Java or C where you gotta go through quite a lot of work before your guess results comes out. So thank you very much for validating my guessing techniques. Yeah, there's science. Right, I think there's a lot of areas that just for me is a programmer feel much better to work and like, please, can I have a ripple? You know, that sort of thing. And it's the same thing with like having a quick feedback loop, having the ability to guess really quickly. And this also came up a little bit in Katie's talk yesterday about auto-completion and like, should there be auto-completion? She said basically, no, we don't want to hand the answers to students until they have a high facility and like getting them out of their own heads. And I think that's the same thing here. Like you actually have to take the guess. Awkward silence. Someone put it in their hand. Tricked you. It's not actually a question. Um... I just think, well, in my experience, one of the things I do is I turn auto-completion off at the shell so that I actually have to try and remember what commands and stuff I'm typing in and all that stuff in the ID, you know, auto-complete function names and all that kind of stuff. Oh, is that what you were talking about? Yeah, absolutely. Yeah, yeah, yeah. So you turn all that off and then it's forcing you to try and remember what you're doing. This is stupid. Yeah, and again, it depends slightly what your goal is. If your goal is to write the thing as fast as possible, auto-completion, sure. Yeah, great. If your goal is to learn it as deeply as possible, then always keep auto-completion off. And of course, in practice, most of us have those two goals simultaneously to one extent or another. And so it depends where you fall and balance on that particular day. Yeah. It seems quite easy to think of ways of applying this in programming, but can you, or do you have, or can you think of any particular ways of applying what you've been talking about in the social situation? Yeah, so the study that was covered in this book, Dweck had the children write letters applying to the pen pal club, which turned out to be a real pen pal club. They did eventually match people up. And then they got rejected from the pen pal club. And before writing the letter, they had told half of them, this is to see how good you are at making friends. And they told the other half, I forget exactly what the frame was, but something more towards a growth mindset. I was socially like, see if you can learn how to interact with the people. And so they rejected them from the pen pal club and then had them write another letter. And the kids who were primed with a fixed mindset sometimes wrote exactly the same letter, sometimes wrote a much shorter and less detailed letter. And then the kids who were primed with a growth framework were much more likely to write longer things, to be more inviting, to say, oh, I really love talking to you, even though it's the first letter to a pen pal. Yeah, and throughout this book, throughout this work, Dweck and her collaborators were pretty careful to not ruin any students, not to leave them thinking that they're bad at making friends. And so there's some really interesting twists that they have to do. I'm sorry? Great question. This was like the 19, this study I think was in the 1990s, so probably. Yeah, so there's some pretty interesting twists in terms to not break children's spirits. Yeah. So I found it interesting that you said there's value in context switching. Do you have any opinions on in the workplace, open office, open plan office versus individual offices and how does your workplace depend on that? Yeah, so I work in an open office. I sometimes hate it when there are things going on that I don't care about. Sometimes there's things going on that I do care about and I'm happy to pop up from what I'm working on as I'm in the conversation. I think this isn't a terribly strong argument for an open office, because you can apply context switches in a more deliberate way if you're going back and forth between related things that you're doing or stopping your reasonable break points and that sort of thing and like raw interruptions are still pretty expensive. So it's interesting to me that they are not completely wasteful, but I still think that there is a pretty significant cost. Talking about the context switches in a work environment, it seems to me that when I have a problem with it, I'm mainly trying to remember, like you said, what I was doing and it's not actually something that's useful to learn particularly. So would it be more useful to maybe have two jobs that involve different skills and switch between those rather than just say both jobs are programming in Python. So the switch is literally just the structure of your project and what it was you were supposed to be doing with it rather than a different skill which maybe would then be learned better. Yeah, I mean definitely interleaving different projects and Python has some value as well as just like waiting a week in between picking it off different things. Yeah, there are varying degrees that you can pick this one up, yeah. Anyone else? Oh, I realize I didn't fully answer the question about how you do this in a social setting. So if you are interested in this, I highly recommend the blog, Captain Awkward. If anyone reads Captain Awkward, you guys all go start. And she's got a couple of constructions of like social challenges, like I'm gonna go to a party and like talk to three people and I will award myself 10 points for each person that I talk to and learn a fact about. So there's a lot of interesting stuff in kind of the internet of social anxiety coping that has interesting strategies around this that I think you can apply regardless of sort of where you fall in that. Excellent, please join me in thanking Alison for her time and for traveling all this way.