A developer argues that beginners should prioritize learning over shipping finished features. Build isolated mini-projects focused on one hard subsystem, master it, then defer integration later. Treat learning itself as the product to ship.
So as we continue our journey through the State Change Mental Model, the next major item we need to talk about here within the context of our first principle, which is the beginner's mind, is the idea of what to ship. And I think the key idea here is to ship knowledge. A common drive that we have is we're trying to build a thing, right? We're trying to ship an app, we're trying to ship an extension, we're trying to ship whatever the tool is that we're trying to build. But usually we're doing this from a position where we don't know How to do all those things. I often get the question, what's the best way of doing something? The best way is the way that's going to help you learn more and help you learn more faster. So the, the thing you will build again is going to be the thing that taught you this time through. So you want to focus on that, which is going to help you for the next time. A lot of mental models, how to do things that are beyond that, which we know how to do already. And that's where I focus the attention on shipping knowledge. When you don't know quite what to do, the question is not how do you build something, but how do you ship more knowledge about it? What does that really mean? One thing I find is really helpful is to take the white room approach. The idea behind a white room is to say that you've built probably a bunch of stuff, you know, doing the table stakes, et cetera. And you're now trying to stack on some other more complicated piece that's going to sit on top of everything else that you've been doing. This part is a little bit more complicated. Let's build it separately. Let's build it in like a separate application, separate project, just to focus on this one hard thing that we're focused on. Uh, the, um, and that make it so that you— that hard thing becomes something you now understand. Then after you understand it, you're integrating it back into the rest of your system. This feels not very linear, right? Well, I gotta be making progress on my app, but what you need to do is make progress on the knowledge that allows you to be building the app. And, and I find that making a little mini app or mini tool or whatever that focuses just on that one thing can help you a great deal. The second idea when we talk about shipping knowledge is permission to learn. So this is kind of related to the previous one where you think, I've got to go build the next thing and I'm trying to figure out the best way to do it, an efficient way to do it. Be effective, not efficient, in, in your learning. And that is a process of having, you know, deeper knowledge and being willing to take a minute to do that. So you might find that like shipping knowledge and like shipping improvements to the app are very, very well aligned early, and then they become a little bit less well aligned as you're spending more time just trying to make something work on the app. Deferring integration is probably the last big idea that I want to be leaving you with here today. Uh, so like, if I started with the idea of the white room, the white room is you're going to go build something completely on your own, right? And giving yourself permission to be spending time learning how a subsystem works. And then once you understand that subsystem, you're in a much better position to actually integrate it. But you want to be able to defer that integration because integration is going to be its own source of complexity until later in the process. Now, the reason I bring all this up is that's very tempting to think, well, I'm going to work on feature A and I'm going to integrate feature A, and then we're going to work on feature B, and then we're going to integrate feature B, and we'll work on feature C, and then integrate feature C. And you'll find that for, for a lot of those, that works. And then you're going to find there's like feature D, something complicated about it. It's like really hard for you to integrate it. Slow it down. Allow yourself to say, I now understand feature D, right, through this white room approach, through this more researchy I don't quite understand how I'm going to integrate it yet, right? Cause that is going to be another level of complexity, but I'm not going to slow down the pace at which I'm shipping knowledge. I'm going to move on to feature C and I'm going to say that integrating feature D is something I'm going to defer. If you give yourself permission to say that my future brain is bigger than my present brain, then the big goal is just making your brain bigger. On a date that is really not very far in the future, you're going to be much better suited to be able to take care of the complexities of integrating these new ideas into the applications and other applications that you will be building as a new budding Dello coder. I'll see you next time.
