Back to Index

What Does Deliberate Practice Look Like for Computer Programming?


Chapters

0:0 Cal's Intro
0:25 Cal reads a question about deliberate practice
0:54 Activities designed to stretch your comfort point
1:40 Write real code
3:52 How to get the stretch

Transcript

All right, let's do some questions. Let's do some questions. We will start here, as always, with some questions about Deep Work. Coffee up. All right. So our first question comes from Alessandro. Alessandro asks, what does deliberate practice look like for computer programming? And he goes on to clarify that he finished a master's in applied math.

He has a junior software developer job, and he wants to get better fast. All right. So we talk about deliberate practice all the time. Quick primer, it's the best framework we have for understanding how people get better at complex skills, be them physical or intellectual. It requires stretch. So activity is designed to stretch you past your current comfort point.

If you're not stretching, you're not going to improve. And then two, it requires feedback, feedback so that you know that whatever you're doing here, the stretch activity you're doing, that you're doing it right, that you're doing it right and you're doing it well. Because underneath the hood that is our skull, you're really trying to isolate the relevant neural circuit and fire it as cleanly as possible.

Because what fires together wires together. So you're going to get more myelination on those circuit connections if you isolate it. So what you want to be doing is really focusing on doing the thing you want to do better. So you need feedback to make sure that you're doing it right.

All right. So how do you get that in computer programming? Write real code. Right. Be doing the thing you want to get better at. So you want to be writing real code. The feedback is really clear in computer programming. A, does it compile and B, if it compiles, does it do the thing it's supposed to do?

You're constantly getting that feedback. Rookie mistake we see in the computer science curriculum all the time. I don't really teach programming courses because I'm a theoretician. But I hear this from the professors that do teach the skill of programming to computer scientists is that rookie computer programmers often do too much before they test.

Like in some sense, they say, OK, I'm going to just try to make this whole thing work and see if it works. More adept programmers, what they're going to do is test at the level of their uncertainty. So at the very smallest granularity at which I'm not quite sure, I'm not 100% sure that what I did is actually going to do this, then you need to be testing.

And testing could be as simple as you have print lines in there. But if you're doing, let's say, some assignment, like I'm going to use a linked list as part of a program to add polynomials. Don't just write the whole program. Does this work? I gave it a polynomial and another one did it add it properly.

You should be with little print statements in there testing everything along the way, especially if you're new. Does my linked list work? Let me just make sure and do a little test there. OK. Is it properly storing all the parts of the polynomial? Let me print everything there. OK.

Is this add routine being called properly? So you want to be getting feedback from, does the code compile first of all, and two, does it do what I want to do? But that means you have to have this very small granularity, especially if you're new. Just a little bit at a time, make sure it works, do the next thing.

If you're compiling and praying, like I wrote a bunch of code, it doesn't compile. I'm just going to randomly change a bunch of stuff and try again and see if it compiles. You're not learning. Incremental. Does it compile? Did it work? All right. Let me add one more little thing to what I'm doing here.

Some new print statements to test it. Does it compile? Does it work? That's how you get the feedback. And then finally, to get the stretch, whatever you're programming should be hard. There's something you're trying to learn how to do. So you're actually stretching yourself to do that in the program that you're writing.

If it's too hard, then you're out of luck. If you're new to programming and you say, OK, here's my challenge. I want to write my own Minecraft style voxel engine. That's too big of a stretch. But if you're kind of new to programming and you say, I'm going to look up in a textbook a sorting algorithm and I'm going to actually implement that sorting algorithm to see if I can sort this array, I'm not quite comfortable with looking up algorithms and implementing them.

That's like a very good healthy stretch. All right. So I'm getting a little nerd. I'm getting the nerd weeds here. But Alessandro hopes that helps. Write real code, compile and test as your feedback. Make sure that code is hard. You're doing something you didn't know how to do before, but not too hard.

There's actually-- some of my kids like Minecraft. Jesse, you probably don't know Minecraft because you're not a 12-year-old boy. But it has a very complicated graphics engine. It's a voxel engine, blah, blah, blah. There's these YouTube videos my son was showing me where people see how fast they can build it from scratch.

So it's like a screenshot of their computer and they cut through time a lot, but they basically build the game from scratch in a day. Yeah. Which brings me to my other point. I can't help but think, what societal good could they be doing instead with that brain? You see somebody could do that, you're like, I don't know, man, couldn't you be working on vaccines or coding up a system to help people find new jobs?

That's often my thought when I see YouTube, is that's a smart person with a lot of time on their hands. And maybe they should be organizing a food drive at their church or something. And yet, we're on YouTube. So rocks, glass houses, things are shattering. (upbeat music)