Vox

Leitura de 16 min

2 Structured Thinking Methods For Problem Solving

Summary

This episode explores two structured thinking methods for problem-solving that can be applied to both coding and business challenges. The host emphasizes that developing structured thinking patterns helps uncover new insights and approaches to problems.

The first method involves breaking down problems into the simplest language possible. This means avoiding abstract terms and qualifiers, and instead describing problems using clear, fundamental language. The host explains that this process requires rewriting and simplifying language until it becomes unambiguous, which increases clarity and helps identify the core aspects of a problem. This approach is particularly valuable when starting new projects or businesses where there are fewer constraints.

The second structured thinking method involves thinking in terms of small, interconnected pieces similar to microservices architecture. This modular approach can be applied beyond software to business organization and problem decomposition. The key principles include ensuring each module has a clear responsibility and minimal dependencies, allowing for flexibility and reusability across different projects. The host illustrates this concept with examples from restaurant operations, showing how various business functions can be treated as independent services.

Throughout the episode, the host connects these thinking techniques to the broader goal of becoming a better developer through purposeful work and continuous improvement in perspective. The structured approaches provide frameworks that can lead to clearer problem definition and more innovative solutions across different domains.

Recommendations

Tools

  • Linode — Cloud hosting provider with SSD-based servers, Intel E5 processors, 10 global data centers, and scalable plans from 1GB RAM to enterprise configurations. Offers $20 credit with code DEVELOPERTEA.

Topic Timeline

  • 00:00:00 — Introduction to structured thinking for problem solving — The episode opens by explaining how creating structured thinking patterns can lead to new insights when solving problems. The host introduces the concept of applying structured thinking methods to both code and business-level problems, setting the stage for the two techniques to be discussed.
  • 00:03:15 — First method: Simplifying language — The host introduces the first structured thinking method: breaking problems down into the simplest language possible. This involves avoiding abstract terms and qualifiers, and instead using clear, fundamental language to describe problems. The approach helps create a clearer picture of problem-solving by removing assumptions embedded in abstract terminology.
  • 00:08:43 — Sponsor segment: Linode — The host discusses today’s sponsor, Linode, a cloud hosting provider. Details include their 24/7 customer support, SSD-based servers with Intel E5 processors, 10 global data centers, and scalable plans from 1GB RAM to enterprise-level configurations. Linode offers $20 credit using code DEVELOPERTEA, equivalent to four months of their basic plan.
  • 00:10:38 — Second method: Modular thinking like microservices — The second structured thinking method involves thinking in terms of small, interconnected pieces similar to microservices architecture. This approach extends beyond software to business organization and problem decomposition. Key principles include each module having clear responsibilities and minimal dependencies, allowing for flexibility and reusability across projects.
  • 00:13:50 — Applying modular thinking to business examples — The host illustrates modular thinking using a restaurant as an example, breaking down operations into potential microservices: food preparation, dish washing, ingredient sourcing, customer attraction, table scheduling, worker management, facility cleaning, and food delivery. This demonstrates how various business functions can be treated as independent, reusable services.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2018-03-26T09:00:00Z
  • Duration: 00:16:07

References

Podcast Info

Transcript

[00:00:00] No matter what problem you are trying to solve, if you can create a structure in the way that

[00:00:11] you’re thinking that you apply to multiple problems, then sometimes you can have new

[00:00:18] insights to how to solve that problem.

[00:00:21] I’m going to give you two particularly structured ways of thinking when you’re solving problems,

[00:00:27] both with code, but also even business level problems.

[00:00:32] My name is Jonathan.

[00:00:33] You are listening to Developer Tea.

[00:00:35] My goal on this show is to help you become a better developer.

[00:00:38] That’s kind of the quick way of explaining it.

[00:00:41] We help you become a better developer by helping you uncover a more purposeful path in your

[00:00:48] career, and you will ultimately end up becoming better at what you do because this is kind

[00:00:54] of a key ingredient to good work.

[00:00:57] The key ingredient to motivated work is to help you uncover that purpose.

[00:01:02] One of the things that we do on this show is we talk about the other side of the coin.

[00:01:07] We talk about what happens after you’ve uncovered your purpose.

[00:01:10] Really, this is kind of a constant discussion because when you are doing good work, when

[00:01:18] you are actually practicing what it means to be a great developer, when you are actually

[00:01:23] walking the developer career roadmap, the path.

[00:01:27] In front of you, very often that is how you uncover your purpose.

[00:01:33] Rather than taking time and going on a sabbatical or some kind of long trip to figure out what

[00:01:41] it is that you want, and not saying that those things are useless, but certainly very often

[00:01:47] we find what really kind of engages us the most, what we believe to be our purpose as

[00:01:55] we are working.

[00:01:56] As we are working.

[00:01:57] As we are actually dealing with this stuff.

[00:01:58] So that’s why we focus on this kind of right thinking, configuring the way that you approach

[00:02:07] your problems, configuring the way that you think about yourself and about others and

[00:02:13] about the work that you do, and even configuring the way that you think about tooling.

[00:02:18] Essentially, taking the time to correct your perspective.

[00:02:24] Now, of course, we’re not saying that we have to do that.

[00:02:27] We’re not saying that we have to do that.

[00:02:27] We have the kind of silver bullet perspective, and that I’m going to share with you all of

[00:02:32] these secrets, but what we are saying is the conversation starts with thinking.

[00:02:38] It starts with asking questions like what we ask here on Developer Tea.

[00:02:43] So I encourage you to engage this content, not because we have some secret sauce, right?

[00:02:50] Not because what we’re doing on the show is going to, you know, suddenly give you a leg up.

[00:02:56] Again,

[00:02:57] it’s not going to be against your neighbor, but rather because it’s going to start your

[00:03:02] brain thinking about what will give you a leg up, what will ultimately lead to you becoming

[00:03:10] better.

[00:03:10] And that’s something that only you can do for yourself.

[00:03:15] Okay, so let’s talk about these particular ways of thinking, structured ways of thinking.

[00:03:21] And this is really problem-solving techniques that we’re going to talk about.

[00:03:27] In today’s episode, we’re going to talk about two.

[00:03:29] We’re going to talk about the first one, then we’re going to talk about the sponsor for today’s

[00:03:32] episode, which is Linode, and then we’re going to talk about the second structured problem-solving

[00:03:38] technique.

[00:03:39] The first one is quite simply to break things down into the most simple language possible.

[00:03:47] Here’s what happens.

[00:03:48] We often talk with abstract terms, and this happens even when we’re discussing something

[00:03:56] very simple.

[00:03:58] We talk in terms that are perhaps meaningful in different ways to different people.

[00:04:03] This is especially true in work that we consider to be creative.

[00:04:08] We talk in terms that are even technically abstract.

[00:04:12] So talking about systems, or we’ll talk about solutions with a lot of assumptions that are

[00:04:18] built into the abstracted words that we’re using.

[00:04:22] So for example, we may say we need a digital solution.

[00:04:26] And actually, removing that kind of qualifier, removing the word digital, allows for you

[00:04:33] to consider more things.

[00:04:36] And really, this comes down to creating a more clear picture of your problem-solving.

[00:04:44] If you can’t break something down any further, if it’s in the most simple language possible,

[00:04:50] now you have a much clearer way of viewing that.

[00:04:55] And what you’re likely to find is that…

[00:04:56] You’re going to have to write more, right?

[00:04:59] You’re going to have to use more language to explain your problem, because you’re going

[00:05:05] to compose multiple parts of that problem.

[00:05:09] You’re going to unpack the abstraction.

[00:05:12] If you think about this kind of like a tree, a tree structure, where the most abstract

[00:05:16] version of your problem may be represented by a single, relatively complex term.

[00:05:24] Not necessarily a long term.

[00:05:26] Not necessarily a difficult-to-pronounce word, but rather a loaded word.

[00:05:35] If you ask yourself what each word means as you’re describing your problem, then you’re

[00:05:41] much more likely to have a clear articulation of what that problem is.

[00:05:45] And you can go about this in two different ways.

[00:05:48] First, you can start with the more abstract language and move more towards less abstract

[00:05:55] language.

[00:05:55] Or, you can try to describe the problem from the ground up, using the most simple terms.

[00:06:04] And as you describe the problem, you can discard versions that have those abstract terms that

[00:06:10] you don’t want to use.

[00:06:12] The benefit of doing it this way is that you’re not passing those assumptions down from the

[00:06:18] original abstractions.

[00:06:20] In other words, when you start from ground zero, you don’t have to make the decision

[00:06:25] of what to remove from that original kind of assumption-based abstract definition of

[00:06:33] your problem.

[00:06:34] And this can have a profound effect on your perspective of the problem.

[00:06:40] In general, I would say that either one of these is effective, but when you’re solving

[00:06:45] something brand new, perhaps you’re creating a business, when you’re solving something

[00:06:51] from the ground up, when there’s no constraints.

[00:06:53] Then, I would recommend taking the ground up approach, defining the language that describes

[00:07:01] your problem from nothing, rather than using that easy kind of within reach abstraction,

[00:07:08] go ahead and start with the most simple language possible.

[00:07:12] This structured way of thinking comes along with some obvious tasks.

[00:07:17] To take some language that you’re using and to break it down.

[00:07:21] Or, to rewrite new ones.

[00:07:22] Or, to rewrite new ones.

[00:07:23] Or, to rewrite a new language over and over.

[00:07:25] Until it is simple.

[00:07:27] Those are the action points that you want to take when you’re practicing this.

[00:07:31] And it doesn’t have to be a problem that you’re solving.

[00:07:34] This can be something as simple as writing an email.

[00:07:39] The most simple language that you can use very often is going to be, perhaps, the best

[00:07:45] understood language.

[00:07:48] Avoiding language that is somehow culturally imbued with a lot of meaning.

[00:07:52] a lot of meaning can increase clarity. If clarity is kind of part of your goal, which for developers

[00:08:01] very often clarity is a strategically important aspect of what we do, then simplifying your

[00:08:08] language should be a constant priority. Now this isn’t easy. Simple language is actually sometimes

[00:08:13] even harder than abstract language. Capturing what you want to say with a lot of nuance is easier

[00:08:22] when you have a wider range of vocabulary to use, but simplifying that language requires you to

[00:08:29] recognize kind of the fundamental aspects of what is happening as a function of the language

[00:08:36] that you’re using. So that is the structured problem-solving method number one, simplify your

[00:08:43] language. Let’s talk about today’s sponsor, Linode. What is Linode? What does Linode provide?

[00:08:48] Well, they provide cloud servers that

[00:08:52] run Linux, but it’s not that simple because there’s a bunch of those out there. What makes

[00:08:56] Linode different? Linode has 24-7 customer support. They have top-of-the-line equipment

[00:09:04] that these servers are running on, the physical equipment. They’re all on SSDs. They run Intel

[00:09:09] E5 processors. They have 10 data centers that you can choose from when you spin up your Linode.

[00:09:16] You choose a distribution, you choose a data center, and you choose your resources. Now what

[00:09:22] is the resources part of that? Well, Linode provides you plans that have RAM starting at

[00:09:28] one gigabyte and go all the way up to Linode’s top-level machine. What is Linode’s top-level

[00:09:35] machine? 200 gigabytes of RAM, 16 cores, 340 gigabytes of SSD storage, nine terabytes of

[00:09:43] transfer, and all of that for 1.44 per hour.

[00:09:52] That’s a pretty low hourly rate, if you ask me, for such a hard worker. It’s pretty cool.

[00:09:57] Linode provides this stuff to developers because they are developers themselves and they know

[00:10:02] what developers need. And that’s what sets Linode apart. They’re going to provide you service

[00:10:08] as a developer. They are part of this community, and that’s why they invest in Developer Tea.

[00:10:15] It’s also why they’re giving you $20 worth of credit, which is worth, by the way, four months

[00:10:19] on that introductory one gigabyte. That’s why they’re giving you $20 worth of credit, which is

[00:10:22] a gigabyte server plan. $20 worth of credit just for using the code DEVELOPERTEA at checkout.

[00:10:27] Go and check out Linode, spec.fm slash Linode today, and you’ll get that $20 worth of credit

[00:10:33] at checkout. Thank you again to Linode for continuing to sponsor Developer Tea.

[00:10:38] So we’re talking about structured ways of thinking, structured ways of problem solving,

[00:10:43] having kind of a framework for how you’re going to go about attacking problems.

[00:10:48] Our second way of structured thinking,

[00:10:52] something that you’re probably familiar with in particular when it comes to actual code,

[00:10:57] and that is to think in terms of small interconnected pieces. Now, this is something

[00:11:05] that we’re familiar with in the term of microservices. This is a very popular way

[00:11:12] to structure your architecture in today’s software development world. And we want to take this and go

[00:11:19] beyond just thinking, how can you structure your architecture in today’s software development world?

[00:11:22] How can you structure your software and instead think, how can you structure your ideas around

[00:11:27] this, your problem solving? How can you even structure businesses around this concept?

[00:11:33] As it turns out, this is kind of a direction for business today anyway, viewing everything as a

[00:11:40] service, a kind of on-demand service that instead of bringing all of these things under one roof,

[00:11:50] we can get them to work. And that’s what we’re going to do. So we’re going to take this and go

[00:11:52] that service as we need it, kind of plug into various services for even the smallest of things.

[00:12:00] So what does it look like to think in terms of modular systems? Or what does it look like to

[00:12:06] think in terms of microservices beyond just code? Well, first, you have to recognize that for a

[00:12:13] microservice to exist, it needs to have something that it does well. It needs to have one area that

[00:12:21] it is kind of in charge of doing. The second thing you need to recognize about having good

[00:12:26] microservices is that they can’t rely on external stuff. The whole point of a microservice, the whole

[00:12:34] point of modularity is the ability to move these pieces and parts around. If it relies on something

[00:12:42] else, then it’s only a microservice in name. You’re going to need to bundle the things that it relies

[00:12:48] on, the dependencies that it has.

[00:12:51] So when you’re thinking about creating microservices, both in code, but also

[00:12:55] in business, you need to consider what structure, what information does this thing need in order to

[00:13:03] work well on its own as a standalone unit. This concept can be applied and has been applied

[00:13:11] successfully to organizations of people with small teams, kind of convening around a singular topic,

[00:13:18] having the structure they need and the

[00:13:21] roles on the team that they need to get the work done, but being so small that they can move around very easily.

[00:13:29] This increases your flexibility as an organization. The same concept can be applied to almost any business that you can

[00:13:36] imagine. For example, take a restaurant. What kinds of microservices could a restaurant have? You can

[00:13:45] first think in terms of the activities that a restaurant undertakes.

[00:13:50] For example,

[00:13:50] example making food this is the most obvious and kind of core of a given restaurant but there’s

[00:13:58] also a hundred other things that a restaurant could do that they could create microservice

[00:14:04] architectures out of washing dishes sourcing ingredients bringing in people to the restaurant

[00:14:13] bringing people into the front door scheduling the tables scheduling workers attracting workers

[00:14:20] cleaning the facilities of the restaurant delivering food perhaps these are all activities

[00:14:28] that a restaurant may undertake and as it turns out many of these activities have been turned into

[00:14:34] their own business many restaurants hire for these activities on their own for example

[00:14:41] services like open table allow for reservations to be something that the restaurant doesn’t

[00:14:48] necessarily have to handle directly

[00:14:50] anyway

[00:14:50] so if you think along these lines what you’ll very often find is that new opportunities that

[00:14:57] you may not have seen before start to present themselves as viable opportunities that can be

[00:15:06] pursued in isolation once you have multiple units that may be combined together what you’ll realize

[00:15:14] is as you move on to other projects those units that you had created previously that stand on

[00:15:19] their own

[00:15:20] may be easily reused in new projects the concepts that you proved in project a very well may directly

[00:15:31] translate in project b thank you so much for listening to today’s episode of developer t i

[00:15:37] hope this has sparked some thought for you and i hope that you have your own structured way

[00:15:41] of solving problems and making progress thank you so much for listening thank you again to

[00:15:47] linode for sponsoring today’s episode of developer t you can go to linode.com and subscribe to linode.com

[00:15:50] to get twenty dollars worth of credit if you head over to spec.fm slash linode and use the code

[00:15:55] developer t at checkout thank you so much for listening and until next time enjoy your tea

Visão de gráfico