Jonathan Cutrell

← Back to All Episodes

Solve Specific Problems by Composing General Solutions

Almost every complex problem can be broken down and solved. Thinking from the other side - learning general solutions and how to compose those will give you the ability to build against the broken down complex problem.

📮 Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at:

📮 Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community by visiting today!

🧡 Leave a Review

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.

Transcript (Generated by OpenAI Whisper)
I want you to reflect on a complicated problem that you've solved. Recently or sometime in the distant past, it doesn't really matter. The principles in this episode will remain the same. We're talking about solving complex problems in today's episode of Developer Tea. And if you think back to a complex problem, it might get overwhelming to think about how complex that thing is. But if you're like most people, you aren't thinking about the total complexity of the problem that you solved. Maybe you're thinking about the value that a generated once it was solved, or maybe you're thinking about a specific part of that problem. And that speaks to the underlying principle that we want to talk about here, which is the simple fact that, especially in software engineering, and in most other fields as well, complex problems are solved by composing general solutions. We'll say this again, complex problems are solved by composing general solutions. And well-architected and maintainable software, every individual piece is understandable. Now, there may be some underlying mechanism that you don't understand. For example, if there's some complicated math that relies on, let's say, regression analysis, you may not know exactly what those formulas are by heart. But if you were to break down each of the individual operations in that formula, you probably do know what those things are. You probably know what it means to divide one number by another. And by composing these individual operations, whether they're mathematical or otherwise, you can create complex solutions. Once again, the composition of these generalized tools, generalized solutions, creates the opportunity to solve a complex specific problem. This principle is what tooling like AWS or Azure are built on. So as you reflect on that complex problem, point out in your mind, what kind of generalized simple solutions, what kind of general solutions did you compose? And how did they compose? The job of the software engineer is rarely to make general solutions, but instead to think about what general solutions apply and how they're composed together. You are more often a composer than you are a computer scientist for the average software engineer. One of the kind of hidden skills or difficult to quantify skills of a good engineer is recognizing what kinds of general solutions are applicable in a given scenario. And perhaps just as important, which ones must be ruled out. And as you progress in your career, you'll begin to gain intuition for which ones are not only available or possible to use, but also which ones are most appropriate. Which ones are optimized for any given use case. Perhaps the most often forgotten skill in this particular subset of skills is which of the tools, which of the general solutions provides you the best future flexibility, the ability to change more most easily in the future. But for now, if this is your first time encountering this subject, I encourage you to look at any problem you face and the way you kind of understand or kind of mechanically work through this is to try to break the problem down into its most understandable chunks. This kind of work breakdown is the opposite side of this principle. We know that we're supposed to break work down into the smallest version, smallest pieces. But the reason we're supposed to do this is so we can apply and understand how to compose these general solutions. If your work breakdown is not providing you something that can be solved with the general solution, it's likely that it either wasn't broken down properly or it needs to be broken down further. Thanks so much for listening to today's episode of Developer Tea. If you enjoyed this quick discussion on this principle of solving problems through decomposition and then recomposing general solutions to solve specific problems. If you enjoyed this discussion, please join the Developer Tea Discord community. This is the kind of thing we want to talk about in that community. This and of course all of your career questions are welcome there as well. Head over to slash discord that's totally free. There's no entry fee. We're not trying to sell you anything there. That is just a community that's intended to be a support, a place of support for engineers who are looking to grow in their careers. Thanks so much for listening and until next time, enjoy your tea.