The average engineer hears this over and over, "question your assumptions." In today's episode, we're identifying assumptions that make based on our behaviors in various situations.
How can we avoid throw away responses like "it's the way we've always done things" when we or our teammates ask the question, "Why?"
With HeadSpin, you only need one platform for testing, monitoring, and analytics across applications, devices, and networks. Check them out at headspin.io
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/.
Transcript (Generated by OpenAI Whisper)
In recent episode of Developer Tea, we talked about inherited orders. These are the systems that govern our lives in sometimes invisible or perhaps unquestionable ways. In today's episode, we're going to continue this discussion on kind of the shape of our restrictions, the shape of our environment that we very often take for granted. My name is Jonathan Cutrell, you're listening to Developer Tea, and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. And you probably take something for granted. In fact, we all take things for granted, and most of the time we do this unintentionally. We're not trying to ignore the systems that are around us. We're not trying to discredit the idea of questioning those systems. The average engineer in today's marketplace, they've heard this over and over. Question your assumptions. And it's conventional wisdom now, rather than unusual wisdom, to stop and think about first principles. But in today's episode, I want to give you a specific kind of call to action or hook, if you want to call it that, a reminder that you can use in your day to day work. And it's specifically around identifying places where you're still making assumptions. These are the invisible assumptions. These are the majority of the assumptions that we make, not the ones that we explicitly say that we're assuming something. Most of our assumptions are reflected instead in our behaviors rather than our words. But if we do take that new conventional wisdom, the newly found but now conventional wisdom that we hear all the time of questioning everything and reasoning from first principles, then we know that this starts with asking the question, why? Why are we doing something this particular way? Or why are we using that tool? Or why are we even solving this problem to begin with? These are the kinds of questions that you might ask to uncover your assumptions. But here's the critical thing. When we answer these questions, when we answer the why questions, very often, we assume that we're uncovering the raw truth. But our answers tend to have assumptions in them as well. I want to talk about a specific category of assumptions when we ask the question why. This is really zooming in here. I'm going to talk about a specific category of assumption that is typically used as our answer as to why we're doing something. We're going to do that right after we talk about today's sponsor, headspin. Headspin for mobile, unifies into in automated testing, full stack performance monitoring, and user experience analytics. For any application, whether it's native or on the web, running on any device and any network anywhere in the world, if you are running your test suites only on your continuous integration, or if you are limiting your test suites to only unit tests or only limited integration tests, if you aren't doing true end to end automated testing in a real environment, that means environments that your users are actually using, then you are very likely to miss out on a whole load of bugs. But here's what's almost equally important. To users, bugs are often indistinguishable from usability concerns. It doesn't really matter to your user if you have something wrong in the code or if your query is just taking too long to run. So don't get caught in the trap of thinking that just running through your test suite is enough. Go and check out headspin. Headspin is going to help you take that to the next level like AI-powered analyses that help track user experience metrics and KPIs over time. They look for things like cold and warm starts, errors, crashes, response times, audio and video quality, and even biometric responsiveness. Whenever to headspin.io to get started today, that's headspin.io. Thanks again to headspin for sponsoring today's episode of Developer Tea. So I want to talk about, once again, a specific category of responses to the question why. And this is going to be very familiar to you when you ask the question why the answer that you often hear is because this is the process that we've set up. The more classic version of this is because this is the way that we've always done it. And here's the point that I want you to take away from this episode. We've been taught that this response should be rejected or that it's a bad reason. But the truth is that it's not only a bad reason, it's actually not true. At some point, every process had a beginning. And almost every decision had a reason for being made. Sometimes the reason is valid. And sometimes the reason has nothing to do with any particular restriction. Maybe it's a taste-based reason or it could be purely random. But nothing happens for no reason at all. And when you uncover an answer like this, that this is the way that we've always done it, or this is the process that we decided to use, it's important to dig a little bit deeper. Because very often, we stick with processes that had a very good reason to exist. And there can be something that you can learn from this. If you ask, why are we doing this particular thing? Why are we doing it this particular way? Why did we write this code or this task or this function? Why did we write it this way? If you only kind of resolve to, this is the way that we've always done it, then you lose two things. First, you lose the opportunity to learn what the restrictions or the real reason was for this decision. And those things can be valuable. The second thing that you lose is the opportunity to iterate on that original reason. It's possible that that original reason is still valid. It's possible that changing, simply because you believe that it's the way that we've always done it and choosing to change away from that, you might be ignoring a truly valid reason. More likely, your iteration will be based on false understanding of the reasoning to begin with. It's very possible that the process that you're wanting to change could benefit from change. But if you don't know the reason the process existed in the first place, and you might change it blindly. So when you get this answer, that this is the way that we've always done it, try to dig a little bit deeper because that answer is not fundamentally true. There was some beginning. There was some start to this process, and there was a reason that it was instituted. If you can find that reason, then you learn more about what to do next. Thank you so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Headspin, at root2headspin.io to get started today. This episode and every other episode of Developer Tea is a part of the spec.fm network. I would love to hear your recommendations for this show. There's a couple of ways that you can send them to me. One is to literally just send me an email. You can email me at Developer Tea at gmail.com. You can also reach out on Twitter at at developert. And finally, of course, you can leave a review in iTunes. This also helps other developers find and ultimately decide to listen to this show. Thank you so much for listening to today's episode. This episode was produced by Sarah Jackson. My name is Jonathan Cutrell. Until next time, enjoy your tea.