In today's episode, we're going to talk a little bit about belief.
In today's episode, we're going to talk a little bit about belief. Often this word is used and abused as something more than it is. In today's episode we're going to reinvigorate your appreciation for the word blief and hopefully, encourage you to use the concept of beliefs when constructing software.
Clubhouse is the first project management platform for software development that brings everyone together so that teams can focus on what matters – creating products their customers love.
Listeners of Developer Tea will receive a special two-month free trial when signing up at: clubhouse.io/developertea
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
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/.
This is part two in our discussion on how we construct software. Not the mechanics of how we type, not the languages that we use or even the particular paradigms that we use. But rather a few steps before that. How we perceive problems and how we construct solutions. How we model those things in our head. And then how we take those models and express them. And in part one, we discussed why questions are so important. And how difficult they are to avoid. We also discussed very briefly that we often answer questions, not by listening and thinking thoroughly about that question, but instead by substituting for an easier question. I hope since that episode that you've had a chance to think more thoroughly about some of the substitute questions that you have used both when you're creating software and also in general in your life. In today's episode, we're going to talk a little bit about belief. Often this word is used and unfortunately abused as something more than it is. In today's episode, I want to reinvigorate your appreciation for the word belief and hopefully encourage you to use the concept of beliefs more often when you are constructing software. You're listening to Developer Tea. My name is Jonathan Cutrell. My goal in this show is to help driven developers like you connect to your career purpose and do better work so you can have a positive influence on the people around you. I'm going to avoid the obvious question of what is a belief. We're going to provide a very simple definition, a working definition, but it should be validated that belief is somewhat of a divisive topic. For the sake of today's episode, we're going to talk about belief as something that you think is true. Why are our beliefs important? At a fundamental level, our set of beliefs is really our model of the world. We have a perception on how things interact, for example. When we act in the world in any particular way, we are using that model or those models. It's not a clean system though because often we will act in ways that contradict things that we say that we believe. And so beliefs aren't always easily articulated by the person who holds those beliefs. These are articulated beliefs are different from the beliefs that we act on. Sometimes our beliefs are cognitive appreciations for things that we wish that we could act on more regularly. These could be considered aspirational beliefs. Sometimes our actions are abstracted from our beliefs enough that actions don't necessarily seem to line up with those beliefs even though they don't necessarily directly contradict them. Sometimes our beliefs are constructed in such a way that the beliefs themselves seem to contradict each other. Some beliefs are static and definitive. Other beliefs are dynamic and functional. They change with time, or perhaps they change with context and circumstance. The point of this is that our model of the world is incredibly complex. And it's difficult to know exactly what one believes and how one will react to the world because of those models. But what we do know is that we value consistency as humans. Perhaps because consistency is necessary for collaboration. Perhaps because consistency often means confidence or perhaps even at some point in human history consistency meant correctness. But this leads us to act in all sorts of ways that are not necessarily to our benefit in order to maintain consistency of our beliefs. For example, you are more likely to adhere to a commitment if you make it publicly. You're also more likely to adhere to a commitment if you've made it multiple times. And when we use the word commitment here, we aren't necessarily talking about something like a New Year's resolution. Perhaps we're talking about ascribing yourself to a certain belief or, let's say for example, a brand. You can see how this can affect a programmer's work directly. If you've chosen a particular strategy when you're writing an application and you have a particular model in mind and that strategy and that model, they cause problems down the road, it may be difficult to abandon them. Perhaps you feel some connection to them. There's many reasons why maybe you feel fear over changing that code for other reasons, but perhaps you feel that you need to remain consistent with what you said was a good idea to begin with. When we have consistent beliefs, our brains are able to see the world with less dissonance. There's less of a hurdle to jump over to make sense of things. This means that keeping the same beliefs is, biologically, more efficient. We don't have to change the way that we do things, the way that we see things, the way that we operate in the world if our beliefs stay the same. The problem with this efficiency model of thinking is that often our beliefs are wrong. Even if you just simply look at the complexity of all of the beliefs that you would have to have to model the world or the universe accurately, it's nearly impossible. The amount of calculation would require too much energy. And you are faced with this dilemma of impossible rationality because you simply don't have all of the information. So what can we do as Developer To be open to changing our beliefs without spinning all over our time trying to figure out just exactly how to model the world perfectly? We're going to talk about that right after we talk about today's sponsor, Clubhouse. Clubhouse is the first project management platform for software development that brings everyone together so that teams can focus on what matters, creating products their customers love. Clubhouse provides the perfect balance of simplicity and structure for better cross-functional collaboration. This fast and intuitive interface makes it easy for people on any team to focus in on their work, on a specific task or a project, while also being able to zoom out to see how that work is contributing towards the bigger picture. With a simple API and a robust set of integrations, Clubhouse also seamlessly integrates with the tools you use every day, getting out of your way so that you can deliver quality software on time. And listeners of Developer Teacan sign up for two free months of Clubhouse, two free months by going to clubhouse.io slash Developer Tea. Go and check it out. Clubhouse.io slash Developer Tea. By the way, this is on top of the 14 day free trial that Clubhouse offers. So you're actually getting more like two and a half months and go and check it out. Clubhouse.io slash Developer Tea. Thank you again to Clubhouse for sponsoring today's episode. So we can recognize pretty quickly that our beliefs are fairly complicated. Their contextual, often they are intermingled with our emotions. They're intermingled with our experiences. They're heavily biased in ways that we won't ever be able to unravel completely. When we bring those beliefs, when we bring our model of the world into our work, we should expect that sometimes that model is going to yield bad results. Sometimes our model of the world just simply doesn't have enough information available. Another example of this is that even if you had a perfect model of the world, you still wouldn't be able to account for randomness. There's going to be failure with your model. Why is this? Why do our models fail? Why can't we ever learn everything that we need to? At a fundamental level, a model is an abstraction. It's an abstraction that compresses out a lot of information that we otherwise would need to be able to predict everything that would happen. Model is useful for predicting the world, but it also is often wrong in some way or another. We often believe that our models are accurate and that they are not an abstraction, but instead a simulation. In a perfect simulation, all of the same variables that control whatever the original simulated thing is are available to the simulation. The human mind does not have the capability of simulating the universe. Much less the many universes that we would need to simulate to be able to run, for example, odd scenarios. We also, quite literally, don't have all of the information available, even simply because humans have only been recording information for a fraction of the age of the universe. Hopefully at this point, you can understand that our models are extremely limited, but still useful. But the models become less useful when our beliefs become inflexible. So how can we fight against this inflexibility of belief? I'm going to give you two recommendations, and there are certainly more. I encourage you to do more thinking and studying on this topic, but two recommendations that are studied and they actually work for helping you kind of remain more plastic in your belief systems. My first recommendation is when you're facing some kind of decision or when you're facing some kind of important prediction that you need to make. And you're trying to lay out how you expect things to happen, or perhaps you're trying to make a decision for yourself, or for your team, or for your family. I encourage you to reframe whatever the center topic is. Sometimes that center topic is a question. Sometimes that center topic is a decision. When reframing works best when you have a should question, for example, should I use this new feature in a library? We've talked about reframing recently on Developer Tea. One of the ways that you can reframe a question like should I use this feature is to shift time. So for example, move forward. Imagine three months and you've decided to use that feature. Now ask yourself the question, did I make the right choice to use this feature? And do the same and run the scenario without using the feature. Oftentimes this will shift the way that you think about the argument. Reframing is very important because our brain takes cues from whatever information is available. And so for example, if you're trying to predict whether you should use a particular feature, you're going to use arguments that other people are providing for why you should or shouldn't use that feature. If you are trying to predict how that feature has affected you, that's a different question. And as we said in the previous episode, questions are very important. And the way that we ask those questions and the way that we frame the topics that we are talking about can drastically change the answers that we provide to two nearly identical questions. By the way, framing is a very important tool in communication. For example, imagine that you're trying to convince someone to have food delivered to their house rather than going and picking up that same food from the restaurant. The food delivery costs money, the tip to the driver costs money, and often the food itself is marked up on services that deliver the food. So how can you convince that person to pay more for the same effect? Instead of telling the person that they're paying for delivery, you can reframe what they are paying for. For example, they may be buying their own time. Reframing also causes us to break out of whatever our initial perspective is and it forces us to reevaluate. And when we reevaluate, we do it much less based on heuristics, much more based on that slower thinking, that more deliberate thinking process. OK, so that's the first recommendation. Take a moment to reframe whatever the central topic is in your decision. My next recommendation is to think explicitly in probabilistic terms. You've probably heard this probabilistic thinking, but I encourage you to take a moment whenever you are kind of stating a belief, right? If you say that you know that X is true or you believe that this is the best decision, then take a moment to imagine that the stakes are high, that you've placed a large bet on this decision. One of the signs that you're doing this correctly is when many of your I know statements turn into I think statements. Belief and knowing can often come across as binary statements, having 100% confidence or 0% confidence. I do know or I don't know. If you think something, you're providing yourself the flexibility for a magnitude, thinking provides space for uncertainty. It provides you the opportunity to change what you think. Perhaps you even have 20% confidence that whatever you think is right, but you don't have any other theories. This way of thinking and approaching difficult decisions helps to disarm the sense that your beliefs need to be solid. Instead, you can constantly cultivate better guesses. You can try to figure out how to gain more confidence in the beliefs or discard them, so you can choose a better one, so that you are giving yourself the signals of a higher degree of confidence in the beliefs that you hold. Thank you so much for listening to today's episode. Thank you again to Clubhouse for sponsoring the episode. Head over to clubhouse.io slash Developer Teato get started with two free months on Clubhouse. Thanks again to Clubhouse. Today's episode was part two in our episode series on constructing software, how we construct software. I encourage you to go and listen to part one where we talk about questions and substitute questions. Thank you so much for listening. If you are enjoying these episodes and if you want to hear more in this particular series, I encourage you to subscribe and whatever podcasting app you use. We're in the 600-something number of episodes and we continue to pump out three episodes a week. If you don't subscribe, you end up losing out on a lot of excellent content that I truly believe can help your career and help you as a developer. By the way, Developer Tea is a part of the spec network. I help start the spec network back in 2015 as a resource for designers and developers who are looking to level up in their careers. Go and check out all of the other amazing podcasts that are on the spec network. Head over to spec.fm. As an example, we have a brand new podcast that just recently joined the spec network. It's called Framework. Framework is a podcast about the process of researching, planning and building that goes into bringing a product to market. It's hosted by Tom Creighton and Rob Hayes. Roburt Hayes, go and check it out at spec.fm slash podcasts slash framework. Of course, you can find it on the homepage of spec by just going to spec.fm. A huge thanks to today's editor and producer, Sarah Jackson. Thanks so much for listening and until next time, enjoy your tea.