Keynote: A speedrunning guide to software development

Yeah, all right. Hey. Um welcome everybody. I'm super glad to be here. Thank you for the introduction, Mark, such as it was. Um and I'm really happy and glad to be one of the first to welcome you here to DjangoCon Europe this year. Um I uh I need one more setup thing. Okay. Um I hope everybody's ready um because we're going to be talking about speed running. today. Oh I am going to be talking anyway. Um that is after a short introduction because it is a bit awkward to just stand here and assume the authority of keynote speaker, such as it is. So yeah, hi, I am Tobias. I am the author and main developer of Pre-Talks. Pre-Talks

is The tool that you're using when you're looking at this conference's schedule, um, or if you're up on the stage at some point, you used it to submit your talk. Um Pre -Talks also has a lot of other capabilities, uh such as I sense a certain lack of enthusiasm for uh this block of product placement. So um Let's let's try that without the ad. Um right. Uh so yeah, thank you thank you, Mark, thank you for the introduction. Welcome everybody to DjangoCon Europe. Um I am Tobias, I will be your keynote speaker today. I am the author of pre-talks on open source conference software. I also ran DjangoCon Europe in Heidelberg

back in 2018, I think, with some other lovely people, some of who you'll see on stage here in the coming days. And uh come come to think of it, that's probably something you don't care about either. Okay, one last, one last. Give me one last Try at this. So right. Hi, welcome. I am Toby. I built pre-talks. I ran DjangoCon Europe in the past. I have a website and I want to talk about speedrunning today. That's that's not like it, I think. That's better. Um so what is speedrunning and how does it apply to software development? Uh you might wonder, I hope you wonder.

Um so first off, who here has heard of speed running at all before? That's that's nice. I I can give you kind of a speed run of the definition then. Uh so speedrunning is basically just playing video games really fast with the intent to reach a certain goal or objective um within special rules. Oops Um yeah, that's that's the short of it. You play games, you play them fast, it's a lot of fun. It's also kind of dorky, um, come to think of it. And when you first see a speedrun, you're probably hanging out on YouTube and stumble into it. It's usually one of a game that you've played in the past or at least seen in the past, possibly a childhood game even

And it's it's kind of weird. Um it's it's really rather jarring because you see a game that you possibly know or that you know how it should look And then it turns out to be weird and glitchy and the runner running the game is is doing things that you never thought of. And there are two very common, rather negative reactions to that. The first one is to call the speedrunner a cheater, because you know how the game is supposed to be played. You played it after all, and they're doing something different, and clearly you are right, they are wrong, they're a cheater. Um and the second reaction is a bit more interesting. It's that you think that you spend hours, not just hours, you spend days or maybe months on a game, um, especially childhood games.

Um And it feels like somebody just rushing through the game and completing it in maybe 20 minutes devalues the game in a way. It kind of ignores what's really cool and really good about the game. Um and kind of misses the point of this work of possibly even art. And that's a misconception that I find really interesting because most people start out that way and think, well, they're just rushing through the game. That's kind of rude. But it turns out that in in truth, in reality, speedrunners spend more time on a game than pretty much anybody else. They start out spending hundreds of hours and the the top-level runners, the world record holders, usually have thousands of hours in their game

because they just have to try again and again and they have to practice Um another interesting thing about speedrunning is that it's super varied, kind of like um Programming, I I will come back with more metaphors like that, don't worry. Um not only are there speedruns of thousands of games, but even within a single game there are a lot of different kinds of speedruns. Um I'll my my prime example will be Super Mario 64, um SM64, which is a 3D platformer game. Very very fun, very nice, looks very antiquated by now because it's from 1990. six, so probably older than half the people in this room. Uh only five years younger than Python. Uh Python is terribly old when you think about it.

So normally in Super Mario 64 you need to collect seventy stars uh to collect the game. There are 120 all in all, so you have some choice, but you need to collect them in order to finish the game And so naturally there's a speedrun doing that. Choosing the fastest 70 stars, then going to the end of the game. However After a couple of years, it turned out that with some tricks, with some glitches, you can get away with just getting 16 stars. These aren't 16, don't Count. Um and even later tricks were found to finish the game with just one or even zero stars And those runs are super different from each other and it doesn't make a lot of sense to compare them. Getting 70 stars takes around 45 minutes. Getting just six stars, uh uh

getting just zero stars takes six minutes. Um and you can't compare the runs, so they're separate leaderboards. Um keep keep that in mind. So that's that's the short of what is speedrunning and how does it work. Um and by first appearances, speedrunning It doesn't have a lot of common uh in common with software development. It's kind of just a weird dorky way to play a game. It's nothing like our serious and time-honored profession of software development. Um Speed running requires a lot of practice, twitch reflexes, it has leaderboards, it has competitions. Um And those are kind of the boring differences that I'm not going to talk about anymore because I think that there are a lot of very informative and cool similarities that kind of jumped out to me when I first stumbled

into speedrunning. And there are also some less obvious differences that I think are really cool. Um and so the first one that people don't tend to expect is that speedrunning is a lot like open source. In that everybody shares. Um which is often surprising because you go in and you think it's competitive, people are trying to get the best times, they're going to hate each other or you know, at least be very competitive about it. And they are competitive, but they share all their tricks and strategies and and practice tricks. Uh and it's really frowned upon to hide things that make you faster uh in order to maybe get a world record. Uh it's called strat hiding and it's

kind of unthinkable. It's just not done. Um it's kind of like if if we as as people who built Django were going, yeah, Django is able to interface with Postgres, but we're not going to tell anybody how to do that. We're the only ones who can do that. That's our competitive advantage. It's it doesn't even come to mind. It it took me a lock time long time to think of an example just because it's so not done. And a cool extension of this openness is that is that there are experts around who are readily available to help newcomers. Um for us that's often on the Django forum or at conferences at sprints here. Um in speedrunning, it's usually a Discord server. Um

and there are experts with years of experience who are just very happy to help people out who get started That's with a small caveat. If you come into the Django forum and you say, Hey, I'm gonna build a website, tell me how. You will get a very tired link to the Django Girls tutorial and a request to please come back with a better question once you've finished that And it's similar when you come to a speedrunning Discord and say, Hey, I want to learn the 70-star run, teach me. But if you come in there and say, look, I want to run 70 stars Super Mario 64 And I need this one trick to get a specific star. And I looked up how to get it and I tried and I practiced and I just

Can't do it. And ideally, here's a video of me failing to do that. Can you help me? People will be so so incredibly enthusiastic to help you and to show you how to get better at that. And in my experience at least that's also how how Django works. When when you have actual questions and can show that you try to figure something out, people b will fall all over themselves to just help you out. And the forum kind of illustrates another thing. It's that we have a lot of non-obvious roles, both in speedrunning and in software development. Uh because people from the outside see the heroes and the lone stars, they see the world record holders, they see the heroic developers who in their parents' basement

hacked up an entire operating system and are clearly Lone heroes, nobody else helped out at all. And we know that that's not how it works. We know that there's so much more. It's not just that there are um many other developers who have not coded up their own operating system It's also that there are more roles than just developing the software. In speedrunning, there's a pretty cool one, which is the labbers, the people in their laboratories. uh who are the ones who figure out the new time saves and the glitches and the tricks. Um they're super clever and very cool and like experimenting a lot on one end of the big spectrum of of ladding Are people who just improve existing tricks or not just

who improve existing tricks because usually tricks are very finicky Like some speedrunners will practice with a metronome in order to get their frame perfect inputs in order to perform these tricks. It's absolutely wild. And getting easier ways to set up those tricks and make them more accessible is very important to get. Faster times. Um and there's a whole spectrum and at the other end of that spectrum there are people who will sit down with like memory inspectors and look at what the game code actually does in order to find exploits that are more alike to a remote code execution, and is actually called arbitrary code execution, in order to glitch the game. You will maybe have to kill one enemy at a specific position

so that the coordinates get written to memory and then die in another position. and then glitch the game in a way that it starts reading those positions back as code rather than as information. Um in one really extreme and super cool case, uh you spend most of the time speedrunning uh Paper Mario or specific speedrun of Paper Mario playing another game entirely You spend most of your time playing Ocarina of Time, uh, which is a bit more broken, so it's easier to set up these variables in your memory. And then you go physically, you as a person go to your console and swap out the cartridges really fast. Because if you do it right , won't re erase the memory. Those values stick around. And then in Paper

Mario you just have to glitch out the game. It will reach the uh read those values and jump you through the ca to the credits scene immediately. It's absolutely wild Uh and there's a great explanation of that up on YouTube. I can really encourage you to watch that. It's it's so incredible Uh but we have similar things going on. Um speedrunners usually have a vague understanding of how these tricks work, but not a super in-depth one. They can explain how it works But they couldn't find it and they couldn't usually reproduce it without a lot of time. And I f this is exactly how I feel about, for example, Python's global interpreter log. I know it exists. I can explain to people who are new to the Python community that it exists and what

its results are and uh the many ways we deal with it or fail to deal with it. I can even vaguely follow discussions about how it might be changed, may not be changed, how other people are working around it. But I can't work on it. I don't have the knowledge. I don't have the experience. I would have to spend probably a year or several months to just get into the Python internals and understand what exactly is going on. And again, this is something that you don't see from the outside. Even if from the outside looking in, you know that Python exists. You don't see the people who spend their time working on the internals of Python, of Django. Um there are other even more important or as important rules that are even more on the shadows.

In speedrunning, um where there's competition, there are Actual competitions, not just competition. In speedrunning, that's often tournaments. And tournaments are a lot of work in the background. You have organizers who set up the whole thing, who select the runners. who commission artwork possibly, who organize the fact that there are commentators, because it's really boring to just watch a race, uh, who make sure that there's people who restream the whole thing. It's a lot that you don't see Tournament organizers often spend months just working in the shadows unseen in order to make sure an event much like this can take place. And that's why we're all very grateful to our conference organizers.

And coming back again to the forum because I think that's where a lot of community actually happens. Any group of people, and particularly of people working on something, or a larger group of people, needs some sort of governance. There's an obvious kind of social governance that you run into as soon as you have a forum, a mailing list, a server, whatever. uh you will have trolls or just people being clueless and misbehaving. So you need moderation, moderators need guidelines or a code of conduct. So you need people who are able to write that instead of just copying a code of conduct from somewhere without looking into it. Then the moderation team needs to be able to take confidential reports, act on them, act on them appropriately. If they make a mistake, they need to be able to reverse that mistake and so on.

Um in Django we have all of that. We have it at conferences, we also have it within the DSF. But both speedrunners and you know us have not just the social kind of governance, we also have Some kind of technical governance. Technical governance is a bit tricky and has to be redefined frequently when the tech underlying the thing changes. The technical governance in speedrunning is, for example, uh figuring out what is a glitch. Because that's not as clear as you think. Sometimes it's obvious you do something that breaks the game and jumps through the But sometimes you can walk through a wall. Is that a glitch? Do we allow that everywhere? Is that fine? Is that not fine? Walking through a wall may be a glitch, but what is uh Taking a very, very, very long jump across a pool of water that you're not meant to cross is that a glitch?

Um so there are people who decide that and have to update that frequently. Um and then check that nobody is actually cheat cheating, so they have to verify incoming runs. Whereas we we don't have the cheating problem as much, but we have to decide the direction that Django is taking. And to some to to some degree everybody here can participate in that, but we will also sometimes run into conflict. And then you need some sort of tie break It can be elected, it can be handed down from the old generation. And we have to figure out what kind of governance we need and we need to make that decision over and over again. And just like speedrunners, we also look to other communities, for example

Python, to see how they do it and how we can do it. And again, this is something that goes unnoticed often And is a crucial part to the community. We couldn't do this without the sort of governance. And I would like to encourage you all to participate as much as you can because the DSF is there the forum is there. The sprints are perfect place for that. Please do if you think you can. And of course, uh one other thing we all have to do, speedrunners and programmers alike, is we have to deal with new technology coming in. As speedrunners, that can be really frustrating. You may have played a game for a year and have had some really good runs, really good times, you're up maybe to the top twenty on the leaderboard. And then suddenly a new glitch comes in, is discovered, is allowed, and then people are just jumping over your times because now they can use the glitch there

much much faster than you are. That sucks Because now either you get to sit down with your suddenly much worse time or you have to learn this new glitch. As web developers, we I don't think I have to explain how much we have to deal with new technology coming up. And there's two traps at the ends of the spectrum, right? There's the trap to think that everything that's new is automatically better Some speedrunning tricks are new and faster, but are so hard to get that they're not worth the effort to learn for a long time. Um there are some frameworks that look really cool and hot. just because you haven't run into the problems yet that you have already experienced with all the other frameworks. And at the other end of the spectrum, there is becoming the proverbial old man yelling at a cloud and saying like

we don't need that. We we have gotten by without that. Um And it's not just the actual things we do that get better tech that we have to adjust to. It's also our helpers, our tooling. Tooling gets better all the time. In speedrunning you can s really see how times get faster when new tools become available. Because at first people just play the game and kind of get better at it. But that's not very efficient because you will have to start from the beginning again or maybe from a save file in order to practice something and it takes ages. And over time usually some really clever people set up mods and then you can load into a specific place with enemies placed just so you can make sure to practice exactly the trick you may need to practice. And suddenly people get much faster because they have less friction and can practice more.

Similarly, we have things like IDEs, better tooling, we have auto formatting, all things that make our life easier I should know. Um uh when I went to uni and we had a s uh one semester of Java, um it was said that it's possible to write Java just in a plain text editor. Um and And to prove the point, I did that. And I highly regretted that decision. And it it was not a fun time. And that's pretty much it for similarities between speedrunning and software development. Um which which is a lie. There's a lot more. Uh tool assistant speedruns, which is kind of the overlap

between programming and speedrunning. There's we all sit in front of uh computers or screens at least all the time, so we have terrible posture And I hope I sit you all up s see you all sit up straight now. Um we also have hand pain, uh if we're not careful. Like you you sit like that in front of your PC, sorry, a lot of time. Um your your hands will suffer and Speedrunners are actually pretty good about that because they put even more tension on their hands than we do. So they take kind of uh the lessons that musicians can teach us in because they also sit, you know. in front of keyboards, uh the other kind, uh, for a long time and they are also really screwed if they if they lose use of their hands. Um but

we don't have time to go into all that, so uh we'll switch to the differences. The differences are a lot easier to define and I pointed out some n no leaderboards for fastest PR merge or uh most lines of code deleted. Um we we don't play a game here most of the time. Um but arguably the most important difference I think is about what we actually do And I'll illustrate that with going back to Super Mario 64, which is as I said a really old game. It's also one of the, if not the most famous and most ac and one of the most active speed games that exist Uh and despite its really long and active history, earlier this year something surprising happened. Uh

the runner Green Suigi, or just Suiji, um was the already the world record holder for the sixteen star category. Um but at the end of March he improved his world record to a somewhat ridiculous degree. And I have to explain that because he's now fifteen seconds ahead of the second place. That doesn't sound like much if you're not a speedrunner, but fifteen seconds in a fifteen minute run is unprecedented at the top level. It's absolutely wild. It made kind of speedrunning news. Everybody talked about it. It was The perfect run, nearly. In speedrunning there's a concept called the sum of best, where you just put your ideal run together from the best times you ever had in any segment. And only the second place can even reach this world record time with their sum of best.

It's out of this world. And that was really enough to be astounding. But then two weeks later he also set a new one star record, um which is wild because usually you don't just switch categories like that. You specialize in one, maybe two. And again he's ten seconds ahead. Uh he broke a minute barrier which like in in athlete uh uh in in sports it's a psychological thing that people often get hung up on and he brought the one star world record below seven minutes And then one week later, again a super short time window, uh, he also got the zero star world record, again by a huge margin. It it's out of this world. And whenever something like this happens, and it doesn't happen that much, people

start wondering what's it about this guy? What makes him special? What what is it? And there's a very tempting answer that you can read all over the YouTube comments and so on. And it's it's talent. This dude is super talented. It's I could not do that. He has reflexes and and skill that I can't even dream of. It's wild. But it's not talent. It's it's practice. I'm I'm sorry. It's it's not a very fun answer, but it's true. Um there's a very famous trick in Super Mario sixty four speedrunning. It's called the backwards long jump. Basically you jump backwards in a specific way, uh which makes you go faster and faster and faster. Uh and in the end you're going so fast that you can pass by some barriers that you're not meant to pass

because In one frame you're in front of the barrier, in the next frame you're behind the barrier. The game doesn't get a chance to tell you to shove off, you're just through. Um Suiji has hundreds of hours of practice in this one trick to make sure it's consistent and it works. More than some runners have time in the game. And this level of practice Is what I think sets speedrunners apart from software developers in a fundamental level because their skill is so repetition and practice focused that it makes sense for them to practice this in this much detail. Whereas we, our work is more closely related to creative work. So we don't do that. And I think we can talk more about how practice works.

I just suckered you in with the speedrunning and now we're going to talk about practicing things. The past decades have brought us a lot of research on how practice works and what you can achieve with practice It has shown that practice is vastly more important than talent or intelligence or IQ, which is the thing we measure. And uh there's a quote by the late and great Terry Pretchett that I want to bring. It's um, if you trust in yourself and believe in your dreams. And follow your star. You'll still get beaten by people who spend their time working hard and learning things and weren't so lazy. I'm not going to talk about the laziness bit, um, but I want to talk about practicing

And it's not that intelligence and talent are useless. Um a lot of the research about this whole topic is about chess and about music, so my examples will come from that. because those have been around for a very long time. So they have established practices and habits. And also it's rather easy to tell if somebody is among the top ten in the world. It's much harder to pick out the top ten developers in the world than the top ten chess players. Um hopefully. Um so in chess you can see that intelligence isn't useless. When people start g getting into chess, practicing chess. uh their skill is correlated with their IQ for about one or two years. It's not a super strong correlation, but it is there and it is there for one or two years, which is

uh nothing to sneeze at and also it makes it easier to get started of course if you have uh the talent IQ whatever um you will be less frustrated and you will continue on maybe more than other people However, at that mark, something really interesting happens and this correlation vanishes, or rather, for a short time it even becomes a negative correlation. So people who have a higher IQ for a short time do slightly worse at chess And what happens there is that how much and crucially how well they practice becomes the important factor And this negative correlation is usually attributed to the fact that people who haven't had to practice so far or as much suddenly have to figure out how to actually practice rather than relying on their intelligence to carry them through

And from that point on, practice is the important thing. And there are many other things who were thought to be just talent or g genetics who turn out to be doable just by practice The music example is perfect pitch. Perfect pitch, knowing what tone, what note is played, can be taught to children, not not to us, I'm afraid, but to children between two and six You can absolutely reliably teach the skill. Um, and it doesn't even take grueling hours of practice. I think they did two 15 minutes practice sessions a week for a while. Um and even adults can learn an adequate replacement, which is kind of mind-boggling when you come from a tradition and belief that this is something that people are born with or they're out of luck.

Um and because it's about practice, it's not just about the time you spend practicing, it's really about the quality of practice. And there have been a lot of papers written and studies uh about this in the dec past decades and they have identified three big components that go into becoming an expert in any given field, pretty much. Um a big big topic is motivation, which I won't be getting into at all because it's It's not just about having motivation initially, it's also about sustained motivation, keeping an interest for years and years, uh, about not burning out as a recovering conference organizer. There's nothing I can add to that. Um The the second part is called deliberate practice, uh which comes back to the fact that it's not just how much you practice, it's how well you practice and what methods you use.

And the final aspect um is the one that is underrated or least talked about at least I think uh and is absolutely crucial. It's a concept called mental representations, which really set experts apart. And I'll do The practice first, the representation second. So kinds of practice and quality of practice matters if we assume that your your skill of being a brilliant Django developer hasn't just fallen from the sky at your birth, then uh you have had some learning and some practice. The four aspects of deliberate practice all sound really tried because they're really true and get repeated a lot. And they're all really easy to say and kind of hard to do. So uh I'll go through them regardless and if you think they sound easy and boring.

Yeah, I think so too. But they're hard to do and it's worth repeating. The first one is that practice needs to focus on actually doing things Uh which runs counter to a lot of the schooling system we have to le live with. There's a lot of just learning facts and then uh people are like, Yeah, you learned the thing, you will surely be able to do it now. which has no relationship with reality at all. Um it's this part is kind of easier for us because it's not very tempting to just, you know, read about writing code instead of doing it generally But even so, when somebody links you, for example, the excellent Django Girls tutorial, it's still kind of tempting, despite all the warnings. at every step of the way to just, you know, scroll through it

and um think you have absorbed all that there is to it rather than you know actually doing the exercises and coming out the other end feeling very accomplished um despite having learned very little comparatively. So actually doing the things is important. The second part is that practice needs to be focused. And not just, you know, the general you should have goals, um, which is important too. It's also having actually a laser focus on the thing you're doing. Again, I think that's A bit easier for us than for many other things. But if you think, for example, athletes, uh a swimmer will have to build their stamina and have to uh practice and so on. So they will maybe swim for an hour a day Or more. And it's really easy to just zone out and do the thing.

And it turns out that the top athletes are the ones who don't zone out. who keep this laser focus on what they're doing, who question every movement they make, is my shoulder in the right place? What are my legs even doing? Um and if you do that, you get better and Especially the reverse is too true too. If you don't do that, you get worse because if you zone out, you start by necessity, because we're all stupid humans, you start making mistakes. And you start practicing those mistakes because you just We'll repeat them for an hour and suddenly this mistake is part of what you will always do. So right, doing things, actually focusing on the things. Um The third one is the one I kind of hate most because it's so easy to wave off. Good practice needs to be outside your comfort zone. Yeah, yeah, we know

Toby. Outside your comfort zone is where the magic happens. But it's it's again, it's so easy to say and it's so hard to do. It took me um I think four attempts to actually really start to learn Rust. Because Rust is so different from Python. And there's a very specific sense of mental discomfort when you try to learn that thing and it turns out to be weird and odd and now you have to do the tutorial and read the book and write the code and then the Compiler is yelling at you and it's all weird and odd and why am I doing advent of code in Rust when I could do it in half the time in Python So again, easy to say, a bit harder to do. Maybe that's just me. And finally, the the load-bearing part of any

practice is that you need feedback loops Feedback loops are the thing that tells you if you're doing it right or wrong. If you don't have that, you can practice your mistakes forever. If you don't have that, even going outside your comfort zone doesn't help. Because you might do it wrong, learn it wrong, do it wrong forever. Deliberate practice, as I said, comes from this traditional area where you usually have teachers or coaches who you meet maybe once or twice a week and who will correct you uh from a perspective of knowing what the coming decades will bring. Uh in in music it's very easy to start playing an instrument incorrectly and good luck correcting that five years later when it finally bites you. Um we don't have that as much. We don't have, you know, weekly uh coachings.

We have peer programming goes a bit in that direction when you sit down together and have an immediate corrective of oh I'm doing that differently. But I think in many ways we're just a very young profession and so we're we're just not there yet. We do, however, have an immediate feedback loop if we choose to use it in does it compile? Or does the Python interpreter break? Um which again having short feedback loops is important there. If you sit down for an hour and write code and then are surprised when it doesn't run, you have a lot of work to do. If you test in small intervals, either by just running the code or looking at the website or Doing actual test-driven development as we all know we should. Um that's your feedback loop right there, and it will make your practice or your your activity

better. Um mental representations are the part that I'm really excited about. They're kind of just what it says on the tin again. They are how you think about a subject matter and how efficiently you think about it. How how well you can have a view of reality in your brain and then contrast it with reality again and again and figure out where they differ, which sounds very abstract, which is why I have a chess example and a music example. Again. So with chess there's this really interesting thing that expert chess players, I think Grandmaster level Can take one glance at a chessboard and remember the position exactly.

And The interesting part is they can do this only when the position on the board is actually something that could occur in a game. If you just take the pieces and distribute them randomly on the board, they're no better than me, or possibly you, but definitely me, at remembering something like that. Um and another interesting thing occurs when they tell the sport position back to you. Because they won't go, oh yeah, there's a knight at A4 and then there's a queen there. What they will do is they will talk about structures, power blocks, lines of attack, defense, threat, and so on. And that shows off what their internal mental representation of this chessboard is. And the term that gets you gets used a lot surrounding that is chunk size.

What they have is really large chunks in memory. They don't see individual pieces, they see blocks They see not just rows, they see contiguous things that belong together. And that's really, really important. And I have um My favorite illustration of chunk size and mental representations comes from music. It's when children start to learn an instrument After some time, ideally, they start to hit the notes they are meant to hit. And when that happens, you you will get to listen them play. Um and you will be hopefully very polite about it, but what it will sound like is something like do do do to

do do so uh it's You will be polite about it, but it it it maybe doesn't sound like much at first. Um and you can you kind of hear their chunk size of one node. They think about one note at a time and that's it. That's all there is because they have to focus so hard. Um and then They keep practicing, uh hopefully of their own will. Um and after some time oh I'm seeing people who did not practice of their own will here. Um After some time they will improve and the next time you you listen to them, uh it will sound more like doo doo doo doo doo doo doo and you you can hear the

look ahead, the chunk size increasing. Suddenly they can play one note and think about the next one. It suddenly pairs. And it does sound better. And so you see where this is going, right? Uh with some time and practice they will maybe think about entire bars and you will have do do do do do do do do and say, oh music is happening. When did that happen And it's just this chunk size improving I I won't continue embarrassing myself up here, but um by the time they they improve further they will ideally have this entire piece of music in the back of their mind and think about whole phrases within that. So you can suddenly not think about the note you're playing, but you think about tension and arcs and getting louder here in order to get to a finale

there And that's kind of what, as the young ones say, lives in my head rent-free when I think about chunk sizes. This is kind of the skill you want to have if you're good at something It's like when you start programming, you have to question every variable and you have to figure out what a loop is, and every time, especially in more traditional languages you see a loop, you have to figure out what this I is and why why there's a plus plus there and what's happening. And then over time you start seeing the entire loop as a block and maybe you start thinking about and considering whole methods, whole functions, whole classes. And I find it really striking when you talk to people who have been working with one project for a longer time. that they

will similarly to musicians to chess players they won't talk about the code immediately, they will talk about abstract concepts When you talk to one of the Django fellows about making a change in the code, they will know, and you can basically see them think it, uh, where this code interacts with other code and where it intersects and where maybe external code relies on it And that's something that is really good to strive for. The main thing that we're aiming for with these large mental representations is fluency. If you think of a good great mental representations with large chunk sizes, with efficient uh recall as the kind of invisible reason behind expertise, behind being an expert

Then fluency is the visible symptom. When you see somebody be fluent at their job, you immediately get an impression of competence. And it's vice versa too. If you if you're struggling to be fluent at something that's frustrating and takes you out of flow and makes you realize that there's a lot to learn and it kind of actually is very useful as a pointer for what we should learn. Um so wherever you're not effortlessly fluent, there is a very clear room for improvement. Um and this is the part where I start talking about actionable things that we as developers can do. Um and like I said initially, we're not speedrunners. We don't do the same thing for thousands of hours. We we can't just practice

writing the specific thing. We we can get better at it, we can learn how to do it, but if you practice for hundreds of hours how to write a simple simple Django app, then you're wasting your time clearly But what we're doing repetitively every day is using the tools that we're using. And that's something that we can and arguably, as I'm arguing here at least, should practice Um because you spend a lot of time. For example, best example, writing on your keyboard or your input method of choice, but I think it's usually a keyboard. And that means that if If writing for you as a developer is not fluent, then anything that's downstream of typing

will suffer for it. It won't be impossible. You can be a software developer and not type well. uh it's it's harder and it's more frustrating. And it's frustrating to watch people who write worse than you do and it's impressive to watch people who write better than you do. It's it's a very narrow I am right Some people are great, some people are just how can you live like that? And exactly like that, the better people look at you and are like, how can you live like that? No, really Um I I should know I for several years running I held what must have been the regional championship in misspelling Django. If if there were leaderboards, I'd be at the very top. I had, I think, roughly a fifty percent of spelling uh fifty percent chance of spelling Django correctly

There are many ways of misspelling Django. It's it's it's great. Uh you can spell it Jagno or Dadjgno. It there's a lot there. I explored it all and I come back to tell you it's not ideal. It's it's really not And and what I did eventually, because you can go through your life, even as a Django developer, with that, no problem, right? You don't import that often. And if you make a typo, then you go back. It takes a second. What does it even matter It matters that it's not fluent, it's frustrating. It takes you out of the flow. It makes every import just a tiny bit harder potentially. Um and in the end I sat down and I know how absolutely silly that sounds, but I practiced. I just figured out what my fingers were doing and where they were placed incorrectly and what I should be doing instead. And I did that

A couple of evenings, one week and suddenly it was fixed and now I'm fine, thank you. Um And the next thing that we use every day and that is worth practicing using is your language and your libraries Which is kind of, you know, in in the awkward zone between repetitive and creative use, but I do think that it's worth worth uh worth actually learning uh the tools that we use as language and as libraries to a certain degree. And again, if you thought I was impressive for not being able to spell Django, I am here to surprise you because it gets better. Um for years my most looked up function uh was uh JavaScript set timeout. Uh which is doubly impressive because

it has all of two arguments. It it's it's really simple. It sets a timeout. It's set Takes a function and executes it after a timeout. So you pass it a function and a timeout. But I could never remember the order of the two and if the timeout is in seconds or milliseconds. Never And the thing is, I was set up with offline documentation on my laptop, so it took me all of five seconds to look it up. And I'm not a front-end developer by trade for the most part, so I didn't use it that frequently. And I think I would just about need the function a day after I had forgotten how to use it. And that's clearly not ideal. And again, it doesn't take a lot of time. You can look it up on the docs. You can look it up on Stack Overflow.

You can do whatever. It's fine. But it's not ideal, it's not fluent, it's a stumbling block. Every time I had to think about using set timeout, something in the back of my mind, nothing important, but it was there, I went, oh that again. You'll have to look it up again, man Um so w what I did eventually um I realize I'm not putting myself in a great light here. Um Eventually I I um made a flashcard with just this function signature. Um I used the flashcard tool, uh the thing The the thing that most flashcard tools use is called spaced repetition. So sick and tired of seeing them.

It's a great system. It's um generally I'm tempted to say you do you, however you learn things, works, but spaced repetition is really shown to work well with how our brains work. And once that worked, I started actually occasionally when I had some downtime or was on a plane or something, just reading Django docs, I know I'm weird, um, or Python docs, and if there was anything in there that sounded interesting and cool and useful, for example, the entire ETA tools Uh module in Python is hugely useful and underrated because you usually can write the same thing on your own in 20 minutes and why not do that? And so I started reading that um and put those things on flashcards too, just to have easy access. I don't even have to remember the entire signatures, just knowing that something is in your toolbox.

Django has a huge toolbox which is really easy to forget if all you do is write a view and not know about all the cool utils that are around. So that's what the the easy things or the things that immediately come to mind about improving how you work with practice, even in our rather creative uh profession. I wish I had a similarly good way to tell you how to improve mental representations. I don't really. I think that just knowing about them and reasoning about them is super useful and part of that is just becoming better over time. Part of that is noticing when you're clearly lacking a mental representation of something, when you're trying to fix something and you see this whole of But I don't know what this interface is with.

I I have nothing. Um and thinking about that and recognizing that and trying to fix that does a lot. Uh I think the single thing that has helped my mentor representations of Python and code the most was um actively using an interactive debugger, which is uh I don't try to do things like IDE wars or editor wars, Vim versus Emacs, and kind of interactive debuggers versus print statements or something like that. But at this point Um I'm on the side of interactive debuggers just because it gives you a chance to step through code and first come up with your theory of what is supposed to happen and then contrast it by going further one line of one function and contrasting that with what you're seeing.

And that kind of forces you or encourages you to build those mental representations. Um which is what I have to offer on that topic. And finally you w want to try to always build feedback loops. Not not that kind of feedback loop, but um You want to notice when you don't have them, when you're just working in the dark. Sometimes that's really rough. Sometimes you're working on a project And you don't get any feedback for weeks on if what you're doing is right. And it's really worth just going up to people and saying I think my time would be better spent for all of our sakes if I had more feedback, earlier feedback, if I could show you this rough draft. or just draw something on a whiteboard and have you tell me

is that actually what you wanted or will we sit down in a month and you will be terrified uh at what I have spent and wasted my time on. Uh that's the kind of social feedback loop that you can build. I mentioned the technical ones, test-driven development, and so on. I think there's one more kind that is uh less obvious, and it's Um again comparing what you think with what already exists. A really fun exercise, and I say that knowing that it doesn't sound fun, but it is fun, I promise. is to look at code that already exists and blank out parts or just see what's imported in terms of utility methods and try to build part of that yourself. So you look at some Django code, for example. Django is great for that.

You want to use a code base where you're reasonably confident that it's of high quality. And you just take away parts of it and implement them yourselves and afterwards look at it and contrast What did I do differently? Why did I do that differently? Is there something I missed or failed to do? If you're more of a video person, by now there's a lot of people who stream. uh coding on YouTube on Twitch, so you can do the same there. Watch it stream, see some thought process, but then crucially pause Come up with your own response, then go on and compare. It's the same like doing the Django tutorial or just reading it. It's important to do the work yourself. And I have one uh final and uh bit rough suggestion. You can also be your own feedback loop.

For just one day of work you can record your screen and afterwards play it back at a higher speed And you will immediately see what you're spending or possibly wasting your time on. And it's uh a fair warning, it's it can be very uncomfortable, uh, but highly useful because you will definitely surprise yourself. Um With that. At this point, I wish I had time to talk about more things. I wish I had time, for example, to talk about AI and Copilot and how they make this kind of deep learning, deep practice harder for us by offering a very easy access to a shallow kind of learning. I have no time for that. If you want to talk about that, I I'll be around. Just talk to me.

And I have one final note. I have talked a lot about being an expert, expertise, being great at what you do. I don't mean by that to imply that you have a duty to be excellent, especially not a duty to be excellent at your job. I wanted to make the point that you can be, that you're not limited by your talent, your innate eunus that is not infinitely compatible with Django, maybe. You you don't have a divine star spark for building great websites. It's it's not like that. So what you can do is you can consciously pick what to be good at Um because we can't be good at everything anyways. Uh so you might as well pick consciously rather than just being shoved into roles at work, for example.

And also that if you really want to be good at something and you find that frustrating and you're stuck and you're starting to think that maybe it's not not for you, maybe you're not good enough. It's it's really not that. It's absolutely not that. It's just that your practice methods might need some work And finally, practice is often not fun. I I know, everybody knows. Practicing things is not fun. Even using the things you've practiced is not always fun. I can't promise that. However, what is definitely and absolutely fun is hanging out with wonderful people here at DjangoCon Europe. And I hope you all have a wonderful conference Thank you.