Do you always do things the same way? Do you approach problems with the same mindset or the same set of tools, the same problem solving strategies that you did before? How can you continue to grow the way that you approach any given problem? In today's episode we're going to talk about ways that you can manipulate the elements of whatever it is that you're working on. This is techniques for experimentation, introducing new variables that you otherwise wouldn't have had. Some of these variables may be your perspective on the problem. Some of the variables may be the elements of the problem itself. This isn't specific to any type of problem and as you'll see, it doesn't necessarily just apply to, you know, easy to articulate problems. This could be experiments that you run in your life. It could be experiments that you run with your habits, with your code, with your relationships. You can apply the same principles, the same concepts that we're talking about in today's episode in a lot of domains and still find some value in them. So that's what we're talking about today. I'm going to give you five different experimentation techniques, ways of shaking up, changing your perspective, changing the elements of the experiment, ways of introducing a new experimental mindset into whatever it is that you are facing today. My name is Jonathan Cutrell, you're listening to Developer Tea and my goal on this show is to help you as a driven developer connect to your career purpose and help you do better work. So you can have a positive influence on the people around you. These techniques can absolutely apply to you finding your purpose. Let me explain how this works. In today's episode, we're going to talk about ways of changing your approach, changing how you see or how you interact with whatever the subject material is. You can see how this plays out. We're going to go ahead and jump in so you can see how this plays out with things like finding your purpose. If you're having trouble kind of defining your goals, defining your purpose, defining the things that you care about, then you can use these techniques to hopefully start giving you some new gripping on those seemingly slippery subjects. So let's start in with number one, manipulate time. So how does this work? Well, when you're talking about a subject, when you're talking about any subject, let's take your purpose, for example, and you're trying to decide what do you want out of life. Part of the difficult difficult decision that you have to make when answering this question is trying to determine what scale we're talking about. What do I want out of my life in the next week or in the next 40 years or perhaps beyond myself, beyond my own life? What do I want for life for others? And so if you can take a step back and manipulate time, right? So start to think about what if you only had a 20-day window to answer this question with or what if you only had a 15-year window to answer this question with? Let's apply it to something else. Imagine that you are trying to decide what is most important for a product that you're developing. You're working on a product team, maybe you're a lead developer, you're in some kind of decision-making position, and you're trying to decide what is most important. Well, what time frame are you looking at? Are you looking at what is most important for the business to succeed over the course of the next month? Or are you scanning out to the six month or 12 month position or maybe you're looking at the five or 10-year position? All of these can be relevant to your particular situation, but when we don't manipulate time, we end up answering these questions typically pretty vaguely. So manipulate time, this means you can squash it down, you can create arbitrary limits, you can also create a false sense of unlimited time. You can imagine what would I do if I had no restriction on time? These are empowering ways of thinking because even though they are kind of false realities, you're creating these fake boundaries or these fake kind of baselines, what they do allow you to do is create some kind of point in space. And that point in space is something that you can look at and say, maybe I don't want exactly that, but maybe I want something towards that point. So that's your experimentation tip number one for today's episode. Experimentation tip number two, what happens when you remove something that you kind of take for granted? What happens when you remove something, some ingredient, some aspect, some supposed truth, some piece of the puzzle? What happens when you remove it? Does the whole system fall apart? This applies certainly to your code. But perhaps we have similar things in our lives. Do we have elements of our life that are kind of tightly coupled to us that we depend on perhaps too deeply? On the flip side, we may find that removing something has little to no effect whatsoever. And instead of having that thing kind of being carried along and taking up resources or taking up mental energy or taking up our time, we can cut it and perhaps replace it with something better or leave that space open. So that's the second experimentation tip. Try to remove things that you take for granted as necessary. This is also, by the way, the second tip is a process of simplification. And often you end up with unique results that lead to new ideas entirely. It doesn't necessarily iterate on the previous idea every single time. Sometimes out of this concept emerges a brand new thing. I'll give you a very simple good example of this out of the idea that what if we had JavaScript, but without the browser? Right? This is the very simple concepts of removing something that we've kind of taken for granted that JavaScript lives in the browser. Why would you ever take it away from the browser? Or why would you ever separate those two things? And now, of course, we have node. And that was a hugely important move that started with cutting out something that we took for granted as tightly coupled to JavaScript. So that's experimentation number, experimentation tip number two to cut out something that you kind of assume you can't cut out or that you shouldn't cut out something that seems integral. We've got three more experimentation tips for you today. But first, I want to talk about today's sponsor century. Your code is broken most likely. There's probably a way that you have a bug in your code. And it's going to be hard for you to figure that out, even with great test coverage. Why not cover every scenario with a test? Life would be perfect. But the problem is we're humans. And as we talk about on the show all the time, humans have blind spots. We have biases. There's no way that we can assume that all of our code is going to be tested perfectly. So it's much better to attack this problem from multiple angles to write good tests. Absolutely. But beyond that, we're all a little bit lazy, right? Let's add some support here. For all of the unexpected ways that a user might interact with our product and all of the crazy things that may happen, now that's what century comes in and helps you with. Century tells you about errors in your code before your customers have a chance to encounter them. Not only does century tell you about them, but it also gives you all the details you'll need to be able to fix them. You'll see exactly how many users have been impacted by the bug. You'll see the stack trace, the end, even the commit that the error was released as a part of. So you can figure out what engineer wrote that line of code. You can figure out why they wrote it that way. Perhaps there was a reason. Maybe it's not as simple as just changing that line of code. Then you can go and fix your code with less effort, less effort writing every single test case out. Now you can go and fix your code before your users encounter those really difficult to predict bugs. Go and check it out. Century.io. Thanks again to Century for sponsoring today's episode. Okay, let's start with number three. We're going to start into number three. The experimentation tip, number three for today. Perhaps not surprising, instead of removing something, consider adding something that you wouldn't have expected to add. So the idea here is combining two things that seem to be kind of in disparate areas. This is particularly interesting when you talk about relationships, about introducing two people in your life that you never would have expected to introduce. Another useful example of this is when people combine their external hobbies and interests with their careers. Very often, this is where those pet projects come from, those interesting portfolio pieces, and sometimes really powerful and really impactful projects can come out of this as well. Now this doesn't mean that you have to combine two big ideas. You may take a small idea and combine it with a bigger idea, or you may take a big idea and add it to a small idea. Imagine the scale of these things having nothing to do with whether or not they're combinedable. So that's experimentation tip number three. Add something that you wouldn't have expected to add. Experimentation tip number four. Invert or reverse the goal or the intention of a given element of your experiment. Invert or reverse the point that the idea, the purpose of a given thing. Now this is typically done purely as a mental exercise. It can actually be carried out. And sometimes you'll see some interesting effects as a result of this. But imagine that your goal initially is to generate the most number of users that you possibly can. Now what changes about your mindset if you instead say that you want to generate the least number of users that you possibly can? Of course, you have to put on parameters in these discussions, for example, doing nothing is not an option. So generating the least number of users that you can with the parameters that you're still creating some kind of product. Why would you do this? Well, there's a couple of reasons. In this particular example, you may do this to identify what a bad experience, a bad user experience might be. You may be kind of identifying the inverse of what you want, which may help clarify the goals in the other direction. It may help clarify the goals for generating users. When you know what the inverse goal is, you can avoid those inverse goals. But you may also stumble upon some more valuable ways of thinking about your goals as well. For example, generating the least number of users may help you think about creating a product that relies on the psychological principles of exclusivity. So if you create a product that you're trying to limit the number of people that are getting into the application, for example, what this is really doing, it's not about the goal itself, it's about interrupting your default way of thinking about your goals. If you can interrupt the things that you take for granted, and that's what really all of these experimentation tips are about, is to interrupt the things that you take for granted and change your approach. So changing the way that you think about the coupling, changing the way that you think about what you need or what you don't need in a given thing, changing the way that you think about time. And in this case, changing the way that you think about goals. My fifth and final experimentation tip is perhaps the most important of the five. And it is very simple. When you are performing any kind of experiment. And by the way, when you're coding, when you're writing code, and you have, for example, a test suite, and you write code, and then you run your tests, you're running a kind of experiment to see if the code that you wrote and the hypothesis that the code will work actually does what you think it will do. And so the key to having a successful experiment is to have a tight feedback loop. Now part of the reason for this is because we as developers, our experiments are very quick. They're not long drawn out, you know, data collection types of experiments typically. Most of what we do as developers and as human beings are fast iterations on the same things. But the problem is that we often iterate without good feedback loops. So we try something and then we judge based off of some kind of heuristic, biased perspective, whether that attempt, whatever that experiment was trying to attain, whatever the hypothesis was, we judge those hypotheses based off of something that is at most pretty loose and usually not even the right thing to be judging it off of at all. And so this happens when, for example, we have poor test coverage in our code. When we change our our code and we don't have a way of verifying it, verifying that the code does what we expect it to, then it's kind of like changing variables in an experiment without any control, without any kind of control measures taken at all. And so in your code and in your life, in your day-to-day experimentation, in your career, in your relationships, I encourage you to find ways to tighten up your feedback loops. This means getting closer to the responses that you need, gathering direct feedback from the people that you're in relationship with, even if it feels awkward sometimes, setting up these these better feedback loops. And by the way, feedback is not just feedback that your test provides you or that a person provides you. Sometimes feedback is your ability, you know, you measuring something. Sometimes feedback is absolutely your emotions. But not knowing what that feedback is, not having a direct feedback loop is going to screw up the experiment, right? It's going to result in you trying to do one thing to affect something in your life or something that you're working on and not actually affecting it at all, or perhaps affecting it, but not in a way that you could predict or that you can hone and that you can improve. Thank you so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Cintry. You can fix your code with Cintry's help and avoid all of those bugs that your users would find in a much more frustrating fashion. Head over to Cintry.io to get started today. Thank you so much for listening. If you enjoyed today's episode, by the way, then you would absolutely love the T-Break Challenge. This is new this year. We just launched it on the 1st of January. You know, we're four years into creating Developer Tea and the T-Break Challenge is a new, a new form of content that we haven't ever experimented with before. You can find it at tbreakchallenge.com. You can get emails from that. You can also go and find those challenges on Twitter and on a few other platforms. The ones that you probably already use. Thank you so much for listening. And until next time, enjoy your tea.