Breaking big problems down into smaller, easier to tackle problems and in today's episode we talk about exactly why breaking down problems into small forms is effective.
Command Line Heroes is an original podcast from Red Hat about the people who transform technology from the command line up.
A new season releases on July 14th, in which Author Clive Thompson joins host Saron Yitbarek to share his insights from over 200 interviews with coders for his latest book.
This 3-episode mini-season will cover: the many paths to a coding career, where coders work, and what coders expect from each other.
Head on over to the podcast platform of your choice to listen and subscribe for free to Command Line Heroes.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
We've talked a lot about breaking your problems down into their smallest form on this show. And this is something I recommend you do not only when you're stuck or as a way of getting out of a difficult place, but in general this is probably a good plan as a default. In today's episode we're going to discuss exactly why that is. My name is Jonathan Cutrell. You're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. So what is it about small problems that make them good as a default measure? Why should we always be thinking about our problems in their smallest, most atomic form? I want you to think back to a project, a software project. If you have one in mind, or really any kind of project at all, that had a lot of moving pieces, a lot of complexity, maybe a lot of people dynamics involved with project. Maybe it's a school project where you had a lot of participants, a group project, and let's say that there was some conflict on that team. Or if it was a professional project, a software project, there's a lot going on. Maybe there's multiple stakeholders, maybe there's some weird APIs that you have to kind of integrate with. Maybe you're on a constrained timeline or certain parts of the project have better funding than other parts. And all of this asymmetry, all of this heterogeneity in the project. This is the hallmark of a complex system, a complex project. The truth is, most projects that we engage in, particularly if they grow to a sufficient size, they will eventually become complex. And if you were to zoom out and look at them at some level, the complexity is overwhelming. We can't really calculate the complexity with our own brains. In other words, we can't imagine what is the next most perfect decision to make. And this is kind of a good heuristic for deciding whether a project at a particular vantage point is to complex to think about as a whole. But there's an interesting thing that happens when you zoom in. Once you zoom in a little bit, things get a little less complex. And that zooming can happen on multiple different types of axes. For example, you might zoom in on the time aspect. Maybe you don't know what the most important thing is to do if you were to look at the next year. But perhaps you do know the most important thing to do in the next hour. Or vice versa. Maybe the zooming in actually looks a little bit more like zooming out. Maybe you do know what the best thing is to do over the next year. But it's hard to determine what the best thing is to do in the next hour. If you zoom in to a particular part of the project that has a homogenous structure, maybe it has homogenous funding, for example. Or that particular part of the project only works with one, you know, fairly straightforward API. And if that one piece of the project works with that old weird API, it's some vantage point at some zoom level. Once you go in deep enough, things become simpler. And if you continue to zoom in, things become nearly elementary. And it's at this zoom level that I want you to focus your energy and your efforts. And not because it's easy either. We're going to take a quick sponsor break and then we're going to come back and talk about how those atomic simple elements are the best ground for experts to be playing on. Today's episode is sponsored by Command Line Heroes. Command Line Heroes is an original podcast from Red Hat about the people who transform technology from the command line up. Command Line Heroes returns for an all new season today, on July 14th to explore the job of being a coder. Author Clive Thompson joins host, Serrani Barak, to share his insights from over 200 interviews with coders for his latest book. This three episode mini-season will cover the mini-paths to a coding career, where coders work and what coders expect from each other. Past seasons have ranged from the history of open source to the origins of popular programming languages and most recently, the creation of revolutionary hardware. Head on over to the podcast platform of your choice to listen and subscribe to Command Line Heroes today. So at some vantage point, at some zoom level, if you want to think about it like that, things become very simple. And when we say simple, we're going to use that same heuristic that we used before, the heuristic of knowing how to make the next step, knowing what the next step would be based on some goal. You might have a goal of making your program more readable, or perhaps it's a simple business goal. When you break problems down into their smallest component parts, you end up with something that doesn't have a lot of interactions with other parts. Now, here's why this is important. He said before the sponsor break that this is the best place for experts to be. You would think that the reason that you want to make something simpler is because simpler things are easier to do for people who are earlier in their experience levels. But the truth is, this is the best place for experts to work as well. And the reason for this is because at the simplest level, we can follow principles more directly. Think about this for a minute. The simplest form of your software. You can follow the principled rules or the best practices that you've learned, whether it's through this podcast or other sources of best practices. It's easier to apply those in really simple scenarios than it is to try to apply them in that very complex scenario. This principled thinking can only happen at this very small level. Most of the time, you can hear conversations about the principled thinking in those more complex environments, talked about as only theoretical. The translation of that is, well, we're never going to take a principled approach because things are too complex. It's too hard to apply principles to big, complex problems with lots of interacting parts and pieces, but it's much simpler to apply those principles at the smallest level. If we can think about applying principles at the smallest level and then composing those small levels together and using those best practices for the composing as well. In other words, you can apply these principles to the parts and then you can apply the same principles to how you fit those parts together. These kinds of problems become much easier to solve, but more importantly, we can actually follow the best practices that we care about following. We don't have to talk about code from two vantage points, one being the realistic and the other being the idealistic. Instead, we can talk about how we can view this problem from the right zoom level so that we can merge those realistic and idealistic goals together. When you hear experts in any field talking about getting back to the basics, this is what they're talking about. Thanks so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Command Line Heroes. Go and check it out on whatever podcasting app you're currently using. The new mini season is releasing today, go and subscribe and listen to those excellent conversations. And while you're at it, go ahead and subscribe and whatever podcasting app you're currently using to this show. Developer Tea comes out twice a week. We have a lot of episodes in the backlog and you don't have to listen to every episode, but if there is a topic that you think is relevant to you, the best way to be informed about those episodes is to stay subscribed. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.