No matter what problem you are trying to solve, if you can create a structure in the way that you're thinking, that you apply to multiple problems, then sometimes you can have new insights to how to solve that problem. I'm going to give you two particularly structured ways of thinking when you're solving problems both with code but also even business level problems. My name is Jonathan, you're listening to Developer Tea. My goal in this show is to help you become a better developer. That's kind of the quick way of explaining it. We help you become a better developer by helping you uncover a more purposeful path in your career. And you will ultimately end up becoming better at what you do because this is kind of a key ingredient to good work, to motivated work, is to help you uncover that purpose. And one of the things that we do on this show is we talk about the other side of the coin. We talk about what happens after you've uncovered your purpose. And really, this is kind of a constant discussion because when you are doing good work, right, when you are actually practicing what it means to be a great developer, when you are actually walking the developer career roadmap, the path, in front of you, very often that is how you uncover your purpose. Rather than taking time and going on a sabbatical or some kind of long trip to figure out what it is that you want. And not saying that those things are useless but certainly very often we find what really kind of engages us the most, what we believe to be our purpose as we are working, as we are actually dealing with this stuff. So that's why we focus on this kind of right thinking, configuring the way that you approach your problems, configuring the way that you think about yourself and about others and about the work that you do. And even configuring the way that you think about tooling. Essentially taking the time to correct your perspective. Now of course, we're not saying that we have the kind of silver bullet perspective and that I'm going to share with you all of these secrets. But what we are saying is the conversation starts with thinking. It starts with asking questions like what we ask here on Developer Tea. So I encourage you to engage this content not because we have some secret sauce, right? Not because what we're doing on the show is going to suddenly give you a leg up against your neighbor but rather because it's going to start your brain thinking about what will give you a leg up. What will ultimately lead to you becoming better. And that's something that only you can do for yourself. Okay, so let's talk about these particular ways of thinking, structured ways of thinking. And this is really problem solving techniques that we're going to talk about in today's episode. We're going to talk about two. We're going to talk about the first one. Then we're going to talk about the sponsor for today's episode, which is a little inode. And then we're going to talk about the second structured, structured problem solving technique. The first one is quite simply to break things down into the most simple language possible. Here's what happens. We often talk with abstract terms. And this happens even when we're discussing something very simple. We talk in terms that are perhaps meaningful in different ways to different people. This is especially true in work that we consider to be creative. We talk in terms that are even technically abstract. So talking about systems or we'll talk about solutions with a lot of assumptions that are built into the abstracted words that we're using. So for example, we may say we need a digital solution. And actually, removing that kind of qualifier, removing the word digital allows for you to consider more things. And really, this comes down to creating a more clear picture of your problem solving. If you can't break something down any further, if it's in the most simple language possible, now you have a much clearer way of viewing that. And what you're likely to find is that you're going to have to write more. You're going to have to use more language to explain your problem because you're going to compose multiple parts of that problem. You're going to unpack the abstraction. If you think about this kind of like a tree, a tree structure where the most abstract version of your problem may be represented by a single relatively complex term, not necessarily a long term, not necessarily a difficult to pronounce word, but rather a loaded word. If you ask yourself what each word means as you're describing your problem, then you're much more likely to have a clear articulation of what that problem is. And you can go about this in two different ways. First, you can start with the more abstract language and move more towards less abstract language. Or you can try to describe the problem from the ground up using the most simple terms. And as you describe the problem, you can discard versions that have those abstract terms that you don't want to use. The benefit of doing it this way is that you're not passing those assumptions down from the original abstractions. In other words, when you start from ground zero, you don't have to make the decision of what to remove from that original kind of assumption-based abstract definition of your problem. And this can have a profound effect on your perspective of the problem. In general, I would say that either one of these is effective, but when you're solving something brand new, perhaps you're creating a business, when you're solving something from the ground up, when there's no constraints, then I would recommend taking the ground up approach, defining the language that describes your problem from nothing. Rather than using that easy within reach abstraction, go ahead and start with the most simple language possible. The structured way of thinking comes along with some obvious tasks. To take some language that you're using and to break it down, or to rewrite new language over and over until it is simple, those are the action points that you want to take when you're practicing this. And it doesn't have to be a problem that you're solving. This can be something as simple as writing an email. The most simple language that you can use very often is going to be, perhaps the best understood language. Avoiding language that is somehow culturally imbued with a lot of meaning can increase clarity. If clarity is part of your goal, which for developers very often clarity is a strategically important aspect of what we do, then simplifying your language should be a constant priority. This isn't easy. Simple language is actually sometimes even harder than abstract language. Capturing what you want to say with a lot of nuance is easier when you have a wider range of vocabulary to use, but simplifying that language requires you to recognize the fundamental aspects of what is happening as a function of the language that you're using. So that is the structured problem solving method number one, simplify your language. Let's talk about today's sponsor, Linode. What is Linode? What is Linode provide? Well, they provide cloud servers that run Linux, but it's not that simple because there's a bunch of those out there. What makes Linode different? Linode has 24-7 customer support. They have top of the line equipment that the servers are running on, the physical equipment. They're all on SSDs. They run Intel E5 processors. They have 10 data centers that you can choose from when you spin up your Linode. To choose a distribution, you choose a data center and you choose your resources. Now what is the resources part of that? Well, Linode provides you plans that have RAM starting at one gigabyte and go all the way up to Linode's top level machine. What is Linode's top level machine? 200 gigabytes of RAM, 16 cores, 340 gigabytes of SSD storage, nine terabytes of transfer, and all of that for $960 a month. That's only $1.44 per hour. That's a pretty low hourly rate, if you ask me for such a hard worker. It's pretty cool. Linode provides this stuff to developers because they are Developer Themselves and they know what developers need. That's what sets Linode apart. They're going to provide you service as a developer. They are part of this community and that's why they invest in Developer Tea. It's also why they're giving you $20 worth of credit, which is worth, by the way, four months on that introductory one gigabyte server plan, $20 worth of credit just for using the code Developer Teaat checkout. Go and check out Linode. Spekt. Femme slash Linode today and you'll get that $20 worth of credit at checkout. Thank you again to Linode for continuing to sponsor Developer Tea. So we're talking about structured ways of thinking, structured ways of problem solving, kind of a framework for how you're going to go about attacking problems. Our second way of structured thinking is something that you're probably familiar with in particular when it comes to actual code and that is to think in terms of small interconnected pieces. Now this is something that we're familiar with in the term of microservices. This is a very popular way to structure your architecture in today's software development world. We want to take this and go beyond just thinking how can you structure software and instead think how can you structure your ideas around this, your problem solving. How can you even structure businesses around this concept? As it turns out, this is kind of a direction for business today anyway. Having everything as a service, a kind of on-demand service that instead of bringing all of these things under one roof, we can get that service as we need it. Plug into various services for even the smallest of things. What does it look like to think in terms of modular systems or what does it look like to think in terms of microservices beyond just code? Well, first you have to recognize that for a microservice to exist, it needs to have something that it does well. It needs to have one area that it is kind of in charge of doing. The second thing you need to recognize about having good microservices is that they can't rely on external stuff. The whole point of a microservice, the whole point of modularity is the ability to move these pieces and parts around. If it relies on something else, then it's only a microservice and name. You're going to need to bundle the things that it relies on, the dependencies that it has. When you're thinking about creating microservices both in code but also in business, you need to consider what structure, what information does this thing need in order to work well on its own as a standalone unit? This concept can be applied and has been applied successfully to organizations of people with small teams kind of convening around a singular topic. Having the structure they need and the kind of the roles on the team that they need to get the work done but being so small that they can move around very easily, this increases your flexibility as an organization. The same concept can be applied to almost any business that you can imagine. For example, take a restaurant. What kinds of microservices could a restaurant have? You can first think in terms of the activities that a restaurant undertakes. For example, making food. This is the most obvious and core of a given restaurant. There's also a hundred other things a restaurant could do that they could create microservice architectures out of. Washing dishes, sourcing ingredients, bringing in people to the restaurant, bringing people into the front door, scheduling the tables, scheduling workers, attracting workers, cleaning the facilities of the restaurant, delivering food perhaps. These are all activities that a restaurant may undertake. And as it turns out, many of these activities have been turned into their own business. Many restaurants hire for these activities on their own. For example, services like open table allow for reservations to be something that the restaurant doesn't necessarily have to handle directly anymore. So if you think along these lines, what you'll very often find is that new opportunities that you may not have seen before start to present themselves as viable opportunities that can be pursued in isolation. Once you have multiple units that may be combined together, what you'll realize is as you move on to other projects, those units that you had created previously that stand on their own may be easily reused in new projects. The concepts that you proved in Project A very well may directly translate in Project B. Thank you so much for listening to today's episode of Developer Tea. I hope this has sparked some thought for you. And I hope that you have your own structured way of solving problems and making progress. Thank you so much for listening. Thank you again to Linode for sponsoring today's episode of Developer Tea. You can get $20 worth of credit. If you had overdispbacked out of M-slash, Linode, you can use the code Developer Tea and check out. Thank you so much for listening and until next time, enjoy your tea.