[00:00:00] Hello, this is Mark. And welcome back to the Code and Bootstrapping Podcast. The title for today is Rise to the Level of Confusion.
[00:00:09] And what I'm talking about is there's a feeling that a lot of new developers or students or people just learning how to code feel—that it's really confusing and they're stuck and they're just bashing their head on problems for hours and hours, sometimes days, that other people could just solve in 20 minutes. And not only that, but they wouldn't even be that confused. Or, the feeling of when you might have a fairly small program, but the logic is a bit tangled and there's a bug in it and it could just take you forever to find where the bug is and fix it. But someone else who's more experienced could just quickly, through a process of divide and conquer, narrow in on it and fix it without too much trouble.
[00:00:56] And I think there is some truth to it, especially if there's limited domain and you know it very, very well, then maybe you really won't be confused about much of anything with it. But, it's also a bit of an illusion. And the reason for that is because the domain of programming, that most people work on now, is vast. Nobody understands everything that they're working with. And just because of that earlier phenomenon that I mentioned, where someone who understands how something works can solve a problem very quickly, but someone who doesn't understand how it works might spend a great deal of time trying things, experimenting and thinking about it in order to get to a solution... There is such a big difference in how quickly you move when you're not confused versus when you are confused that even if only a tiny portion of a given project is confusing to you, almost all the time you spend will be on the confusing part.
[00:01:59] However much you know you're likely to blow through the things that require that knowledge very quickly and then spend a lot of time bashing your head against whatever parts of your project you don't understand. And in fact, if you find this isn't the case for you, that may be a bad sign. If you understand exactly what you're doing and everything makes sense to you and you know how to do it, but it takes you a long time because there's just a lot of typing... Well, maybe that means that you needed to do more automation. After all, computers are a lot better at automating something that's tedious, and repetitive, and well understood, than people are.
[00:02:43] It's also possible that you're just working at too low of a level of abstraction. If you've ever done the excellent course called Nand to Tetris, you'll see how at the beginning, you're just working with individual logic gates, and then you're working with chips, and then an entire CPU, and you're building an operating system on it and an assembly language, and then you make a C-like language, and you make a Tetris game. If you had tried to build that Tetris game out of logic gates, it definitely would have taken a long, long time and it would have been pretty tedious. So, what I think is probably a good way to go about development is, if you are pushing through the things that you understand well, making sure that you actually do have a solid handle on how it works before you try to move up and abstraction. But once you do get to that point, automate what you can, at least in the bounds of your project, because what you can do to increase the level of abstraction for a well understood project, a well understood domain, is a lot more than what you could do for a general domain.
[00:03:55] And that's why we have domain specific languages. That's why we have editor macro expansions to create common blocks of code that we use for every function or every module that we make... and other useful tools like that, that we can use to move more quickly, so that hopefully each of us can rise to the level of our own confusion without wasting a lot of time on ceremony and tedious tasks. And then, really spend our time where it matters the most, which is figuring out the more difficult parts. That's it for this thought. Thanks for listening to Code and Bootstrapping.