It's not an easy task to describe what you do as a software developer to a non-technical person. Let's say somebody who teleported to us from the 1940s, if they asked you what you do as a software developer, how would you explain it? A very simple explanation that a lot of developers, including myself, and especially consulting developers, we end up resorting to is that we solve problems. This is kind of a blanket description of what software developers do and really what any kind of consultant position does. We solve problems. So I want to do a couple of episodes on problem solving and specifically finding ways of solving problems better. We're going to use some of the principles that we've discussed in the past in order to inform some of this, but we're also going to use some, perhaps, newer strategies and ways of looking at problems to discover better ways of solving them. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal in the show is to help driven developers connect to their career purpose and do better work so they can have a positive influence on the people around them. We do this in part by exploring principles, exploring the truth that we can uncover in the world around us. As well as the truth that we've discovered through experimentation or perhaps an emerging truth from our own experiences. Because here's the reality. Problem solving is not a simple task. Problem solving looks different. We create this abstract language around problems, but ultimately solving problems is not a formulaic thing that we can partake in. There are some similarities between one problem and the next, but perhaps the most similar thing between solving problem A and solving problem B is the solver, the person, the human, you, the developer. And so a lot of our problem solving strategies are less about the problem itself and more about you, more about the way that you see the problem, the way that you deconstructed, the way that you go about exploring around the problem and finding ways to test ideas and refine your experiments so that you can solve the problem. At a core fundamental level, problem solving is no different than any other activity. We're changing something in our world. We see some organization of matter or some common pattern and we want to shift that pattern. We want to shift the organization of the matter. That's no different than any other change, but problem solving is about finding a way to make that change, finding a way to shift the matter, to shift the pattern. In this first episode on Problem Solving, we'll discuss a somewhat non-intuitive way of looking at a problem. Before we do that, I want to take a moment to thank today's sponsor Stack Overflow. I bet if you were to go and look at your browser history, you would see Stack Overflow all over the place. If you're like a normal developer, if you have a problem with your code and we all have problems with our code, and you're trying to solve that problem, one of the most common things that we need to do is go and talk to someone else who has had that problem. And very rarely do we have unique problems that haven't been encountered before and this is something that Stack Overflow has taken advantage of for years. Years go and share their problems and then they share their solutions on Stack Overflow. And you get to benefit from those years of people sharing those solutions. That's why Stack Overflow is such a popular resource. But sometimes we have problems that are kind of unique to our company or to our team. And the solutions are usually hidden somewhere deep inside of a Slack message thread or maybe an email thread or some kind of old documentation, maybe you have to dig through a bunch of commits to find a particular comment and a piece of code and then maybe that repository was deleted. All of these things happen around solving team specific problems. But now you can solve that in a better way. Stack Overflow has just launched Stack Overflow for Teams. It's basically what you're used to with Stack Overflow. But now it's in a private space for you and your team to use. And of course, it's secure as well. So you're not sharing all of your company secrets onto Stack Overflow for everyone else to see. If you've ever fought to keep your documentation up to date or if you've ever had question and answer sessions that you wish somebody had been recording, I encourage you to go and check out Stack Overflow for Teams. Head over to s.tk-Developer Tea. That's s.tk-slash-Developer Tea. If you get started today, your first 14 days are free on Stack Overflow for Teams. Thank you again to Stack Overflow for sponsoring today's episode of Developer Tea. So we're talking about solving problems today and imagine that you're having an issue where your server is running very slowly. This is a problem that a developer may solve. You're trying to figure out why is it that this server is responding, let's say it's a web server, that your web service is taking much longer than it normally would. It's taking maybe three seconds to respond when normally it takes three tenths of a second. Why is that happening? Now the common response to this, no pun intended, is to go and try to fix it, try to make the server response faster. And so you may go and make sure your resources are g-zipping and whatever other tricks you may want to try, you may actually slide the slider on your resources, let's say you're using Heroku or something, you may scale up your resources, trying to increase your computing power or maybe increase your available memory or something like that. And so you're trying to solve this problem by making something that is bad, better. That's the lever that you're using. And very often we can make strides in this particular way. We can decrease that server response time from three seconds back down to two or down to one. But sometimes our solutions are not complete. And in fact, sometimes our solutions are ineffective altogether. Sometimes we get intermittent responses to input like this. But we're trying to make something better and there doesn't seem to be a huge effect. In fact, we can even have a biased response where we're evaluating the output and we're saying that it got better when actually it didn't. We thought it got better. It's kind of a placebo effect of doing some work and then looking at the thing and saying, oh yeah, because of the work I did, it is indeed better. But the numbers, the data don't necessarily support that hypothesis. And we've all done this. We've all spent days trying to make something better, putting a lot of energy into ensuring that we're doing all of the right things. Unfortunately, very often, doing all of the right things isn't really uncovering the bad thing. The kind of source. We aren't really asking those key five Ys, asking Y over and over to understand why is this thing actually performing poorly. This would be kind of like if your car's engine light comes on and you take it in for an oil change and get the car washed and fill up the gas and maybe even replace the battery and the alternator and turn your car back on and the engine light is still on. Now the car may be in better condition, but the underlying issue that was causing the engine light to be on in the first place, so it's still there. So what can we do? What can we do that is different from this process that is perhaps more enlightening. As with so many other things that we talk about on the show and so many other activities that we take part in, perhaps we should do the opposite. In the past, we've talked about creating a not-to-do list, for example. This is not something that's unique to this show. You've probably heard it on other podcasts. We've also talked about subtractive thinking. What should we do in our day versus what shouldn't we do in our day? What should we take part in as a developer? What languages should we not learn? What languages should we stop learning? In today's episode, we're going to think about the opposite of making something better. In fact, we're going to try to make our problem worse. We're going to go in and try to make this server slow down and then observe the effect of that action. For example, we may scale back our resources to see how much of an effect that actually has. Once we start messing with various parameters, trying to make something worse, maybe a little bit more salient. For example, you may find that scaling down your server, taking away computing resources or taking away some memory, has no effect on the low time at all. It seems unlikely, but it's certainly possible. You may try making the particular page that you're loading from the server, making it compute something really intensive. How much longer does it take for that page to respond? Of course, you have gzipped resources and you try to un-gzip them. Of course, each of these things needs to be done one piece at a time. You can measure the effect. If you just go and start making everything bad, well, it's not really an effective way to perform this particular experiment because the goal is to look at the effect of what you're doing. Look at what is affecting that low time. Look at what is changing that output parameter. If you think about problem-solving as an experimental process, then what you want to do with a good experiment, we'll do some basic experiment theory here. With a good experiment, you have very tightly controlled variables. Wine is a variable that you are changing. We call this the independent variable. It's not dependent on any other thing in the system because you're controlling it directly. Then you're looking at the dependent variable. The thing that you are actually caring about, the thing that you want to move the needle on, and the third element is the control group. In this case, the control group is the things that you had before you started messing with the code. The load time that you were achieving before you started changing your independent variables. For a given independent variable, you want to change it to a few different values and then measure the effect on the dependent variable. As it turns out, there may be a lot of independent variables that have an effect on the dependent variable. This would be true in this particular case where you can obviously increase the load time of your server in more than one way. What we are trying to do is understand the shape of the problem. Understand which of these variables that you're changing has the largest effect? Where are the thresholds for those effects? If I change the computing resources by 10%, does it have a 10% effect? Does it have a measurable effect that I can actually rely on? Once you're able to see the shape of the problem and you can see all of the different things that you are changing clearly correlated or not correlated with the dependent variable, in this case, the server response time, now you can start troubleshooting a little bit more clearly. You may also find that all of the things that you expected to have an effect are less effective than you expected them to be and you may also uncover things that you didn't expect to uncover by doing this. For example, if you changed a variable like the location of the server, the physical location, perhaps this is entirely responsible. By approaching the problem not from the perspective of how do I make this better, but rather, how can I increase the severity of the existing problem? How can I increase the load time? Now you start uncovering the contributing factors. That's really the whole goal of this exercise. How can I make the problem worse? Once you can understand how you can make the problem worse, perhaps you understand the most salient contributing factors to the problem to begin with. Thanks so much for listening to today's episode of Developer Tea. Thank you again to Stack Overflow for sponsoring today's episode. You can get Stack Overflow for your team. That means questions that your team is asking other members of your team. It's kind of like an internal wiki on steroids. Go and check it out. S dot tk slash Developer Tea. That's s dot tk slash Developer Tea. Your first 14 days will be free on Stack Overflow for Teams. Thank you again for listening. If you're enjoying these episodes of Developer Tea and if we've provided any value to you, whatsoever, then I'd love to request just a few minutes of your time. In the first minute of your time, go and subscribe in whatever podcasting app you are currently using. That should only take about 10 seconds. Then you can use the rest of that time to go and leave us a review and a rating and iTunes. I read every single one of these reviews and I've been refreshing in recent days to read each of them. This is the best way to help other developers, just like you, find Developer Tea and in this case, start solving problems better. Thank you so much for listening and until next time, enjoy your tea.