What words are you using to describe a problem you're working on? Today, we're talking about framing and how to effectively communicate what you're trying to solve.
In today's episode we're talking about the words we use to describe a problem we're working on. We'll discuss how our words frame problems faced and how we can broaden our ability to effectively communicate a problem to find a solution more quickly.
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.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Supercharge your career with interactive, text-based software courses. Visit Educative.io/DeveloperTea to get 10% off.
What words are you using to describe a problem? In today's episode, we're talking about the concept of framing and more importantly, reframing to understand your problems more effectively and perhaps help you approach your job, your life, your career from a different frame than usual. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. What words do you use to describe your problems? This is such an important question because most of the time our words limit a problem to a much smaller frame. And when we limit the problem to the smaller frame, we necessarily are cutting out possible answers to a slightly different frame of the same problem. Let's think about that for a second. When you use words to describe a problem and you limit your description of that problem to those specific words, it's very likely that you are compressing the problem and therefore the possible solutions to the problem in unexpected or perhaps subversive ways. So what does this mean in practice? Well, most of the time when we think about a given problem, we think about it in a way that it has been presented to us or in a way that we have written it down, a way that we've talked about it to other people, and language can shape our perception of a problem drastically. We know this as engineers, especially if you've worked on a product team or another similar kind of engineering team where you have a given problem that is brought to the table and then the team brainstorms around it and then outputs some kind of specification. That specification might be a card in JIRA. And what's interesting is that we've framed the problem in terms of tasks after we've consumed the problem in more ambiguous terms. Part of the job of a product team is to understand problems thoroughly and then come up with practical solutions to those problems. And so in some ways, it's necessary to create a specific frame and to break a problem down as far as possible into action steps. This is a good pattern to have and it makes sense from kind of an evolutionary standpoint as well that we would create a quick frame, a useful frame as soon as possible. We don't try to consider every possible option that we use various heuristics to materialize that frame as well. Some of our frame will be implicit, some of it will be explicit. Some of our frame is based on our shared values. The values that we're executing on inside of that frame, those are kind of the implicit parts of the frame. And so when we create these frames, especially when we do it in a collaborative atmosphere, we're creating the frame in order to reduce the number of options, reduce the number of pathways that we might choose to go down. But sometimes we do this intentionally, but most of the time we're creating frames naturally. This is a part of our everyday lives. We have to have a frame of reference and we're kind of biologically limited to a literal frame of reference, but we also create frames in order to be productive. We can't spend all of our time imagining every problem from every angle that would be debilitating. If you'd like a lighthearted look at what it looks like to have too many frames of reference, there's a classic scene from the movie The Princess Bride, The Death of Vizini. I won't ruin the dialogue, but this is a perfect example of this. So the idea here is that we can create these frames and that we must create the frames to be productive, but that the frames can be limiting. We've talked about how heuristics can be limiting and frames are another kind of conglomeration of heuristics. And it's one of the easiest ways to practically escape your heuristics, to create intentionally create a different frame for your problems. And we're going to talk about ways that you might do that with particular types of frames right after we talk about today's brand new sponsor, Educative.io. For developers, the learning never stops. There are always new languages, frameworks, and technologies. Educative helps you learn faster and more efficiently. Instead of video-based courses, which require you to kind of scrub back and forth, their courses are all tech space, so you can skim and double back easily, almost like a book. Each course also contains pre-configured developer environments, so you can practice as you learn. Courses cover all kinds of in-demand topics like machine learning, Kubernetes, AWS, system architecture, and more. They just launch subscriptions, it's almost 50% off, so this is a great time to go check it out. You can get an additional 10% off everything by visiting educative.io slash Developer Tea. That's educative.io slash Developer Tea, all one word. Thanks so much to Educative for sponsoring today's episode of Developer Tea. Framing starts with words, words that you choose to describe a problem, a situation, to describe your perspective even. And so it makes sense that in order to practice reframing, we should try using different words for the same concept. And this is exactly what I would like for you to try. The next time you come up against a particularly interesting or worthwhile problem to reframe, just try to say it a different way. Try to look at the problem with new words. Don't just do this with the Soares and Substitute Synonyms. Try to explain the problem with a different vocabulary. Try to use different nouns and different verbs entirely to explain the core of the problem. And when you see differences between your original explanation and your new explanation or your new frame, that's where you can start to ask questions. Why is there a gap between the first one and the second one? And which one is the frame that is more productive or more useful for you? So this reframing is directly about language that you're using to describe a problem. But imagine if you could reframe your assumptions as well. So for example, let's say that you are describing a problem that you're having in your business today. And this problem is critical. It's critical to your success as an organization, maybe critical to survival as a start-up. One thing you can try in these kinds of scenarios is to reframe that problem as if it was someone else. Reframing it as if you were giving advice to another person, another organization, what would you tell them? And why? Once again, look at the differences between the kind of advice that you're trying to give yourself versus the kind of advice that you would give someone else. Another thing you can do to reframe your own assumptions is to imagine that this problem was not critical, that your survival didn't rely on this problem being solved. The same can be said about the opposite direction. And in fact, it's probably a little bit easier to look at it from the opposite direction, where your survival does not necessarily depend on this particular problem. But imagining that it does might clarify away forward. You can even try to imagine reframing as if you had already solved the problem. This idea is commonly called a post-mortem. In this case, it's a post-mortem in the successful direction. So you're looking back and you're realizing that you had succeeded. Well, what were the critical steps? What critical things had to occur for that to happen? Of course, you've probably also heard about the pre-mortem, which is holding a post-mortem just in advance. So you're imagining that you have failed already at this problem. You're looking from a different temporal frame at the same issue. You can also manipulate the severity or the particulars, the magnitudes in your problem. So imagine that you are trying to increase the speed of your application. So you're trying to reduce the response time on your web server and cut it in half. It's taking a second to load. You want it to take 500 milliseconds. Well, what happens if you try to only cut it by, let's say, 100 milliseconds? What kind of strategy might you use to solve that problem? Or on the opposite end of that kind of magnitude change? What if you were trying to get it to load in 100 milliseconds? This is much more of a drastic cut in that load time. It's likely that your strategy in each of these scenarios is a little bit different. Changing the magnitudes might help you find the edges of your problem a little bit better. These examples are why framing is so important. When we choose a specific frame, it gives us better boundaries for what we're trying to accomplish. And sometimes when we choose a frame, we choose the wrong frame. Or we could choose a slightly different frame and achieve most of the value, or even greater value than our initial frame with the same amount of energy. One final note about framing, it's not always valuable to consider another frame. Sometimes, our problems are very simple. And reframing them takes just as much energy as solving the problem in the first place. And so it makes sense to reserve reframing for either consequential problems or for the sake of learning. If you're using reframing on an inconsequential problem, then do so with the intent of learning how reframing works. Thanks so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Educative. You can supercharge your career with interactive text-based software courses by visiting educative.io slash Developer Tea. That's going to get you an additional 10% off. They're already doing 50% off on their subscriptions, nearly 50% off. You're going to get an additional 10% off just for being a listener of this show as educative.io slash Developer Tea. Before we close out the episode, I want to ask you a very simple question. What kind of developer listens to this show? What kind of developer listens to Developer Tea? My hope is that the people who listen to this show are committed. They're committed to becoming better developers. They're committed to making their teams better. They're committed to building positive relationships with other developers and supporting each other. They're committed to high levels of conscience and making their communities better. If you are that kind of developer, you are who this show is made for. I'd love to hear from you. You can email me at Developer Tea at gmail.com. And if you do believe that you're a part of that group, then I encourage you to subscribe in whatever podcasting app you're currently using. Thanks so much for listening to today's episode. This episode was produced by Sarah Jackson. My name is Jonathan Cutrell. Then until next time, enjoy your tea.