Hey, everyone and welcome to Developer Tea. My name is Jonathan Cutrellan. In today's episode, we're talking about lessons from the lab. Thank you so much for listening to today's episode of Developer Tea. Of course, you can find the show notes for this episode, but more importantly, you can find hundreds of other episodes of Developer Tea, as well as tons of other great content for designers and developers who are looking to level up at spec.fm, a huge shout out to all of the incredible podcasts that are putting out great content on spec right alongside Developer Tea. So go and check out the other podcasts on spec if you haven't yet. Of course, you can join our spec Slack community by going to spec.fm slash Slack. I want to jump in and talk about lessons that we can learn from the lab today. We often think of our work in terms of simply the business problems that we're trying to solve with skill sets we already have available. And a lot of times this gets pretty messy and it gets rushed and we end up doing the same thing over and over. Right? There are a few things this does for us and a few reasons we do it this way. First, we can work with a dependable set of tools. And this is important that we develop this skill of working with a dependable set of tools so that we can have a dependable outcome, a dependable amount of energy outgoing. Right? And understand how those tools interact with one another. We can also eliminate variability and risk by working with code that we're already familiar with, working with libraries or languages that we already know so that we can solve a generic problem solving, it comes easier when you know those languages and when you're familiar with those tools. Now, on the flip side though, and this is what today's episode is about, on the flip side, if we only work with this perspective, if we only work with the perspective of the business problems, being the most important thing and the technology itself or the solution itself not matter as much as it actually being solved, the character, the solution not mattering as much. If we only work with that, that kind of perspective is likely that our level of innovation will drop. Now, what does that mean? Innovation dropping. Practically, it means that instead of trying something new or inventing a better, newer solution, our gut instinct will be to reach for the most familiar solution to the problem. Now, notice I said the most familiar, not the easiest solution. Right? Now, think about this for a second, it's very important that we as developers understand that both sides of the scale, if you go extreme in either direction, the extreme ends are both bad. Right? And knowing what tool is correct for the job is important. I had this discussion recently with the coworker of mine, if you went to dig a hole in your backyard and you started out with your hands and that was the thing you were most familiar with, then your tool set is going to be a little bit more familiar. It is not the correct size, but it's also not really appropriate for you to go and rent a bulldozer just to dig a hole in your backyard. The more appropriate thing is to find a good shovel. Right? And that's really what we're talking about here in terms of finding balance. But if we always go to the solution that we know, we may end up dead ending ourselves with the wrong tool. Right? And you guys know that I'm all about sticking with your tool set and not being too quick to change, not being too quick, too quick to jump to a new tool just because it's the new hot thing on the market. Right? That's not a good practice. It's not responsible with your time because you're not going to be able to master all of the different tools that you touch. Now, this concept is very well known, especially in the engineering community. Because sometimes we have to take a higher level view of our practices and analyze them more holistically to determine how to combine innovation and exploration with practical business needs. In other words, we need to take a step back and figure out what size our shovel should be. And on the opposite end of the spectrum from a service business is a laboratory. Right? And in a lab, the experimenter may be given some raw information to work with. For example, they may be charged with fitting more information onto a smaller silicone chip or maybe developing a new vaccine or maybe they're given the task of learning more about how sleep affects the human body. Obviously, there are endless possibilities of fields to research. We're not even going to touch the surface. But that's the kind of thing that I want you to be thinking about when you think about a laboratory. In a lab, the experimenter generally follows a procedure that looks something like the following. They start by developing a particular train of thought to shape their experiment. In other words, there's some kind of problem that they're trying to solve and they're focusing on one aspect of this problem or one interesting area that they think is relevant. And this may start with some kind of hypothesis. Then the experiment begins, they'll plan out their experiment, plan out their methods. And then they actually carry out the thing that they've planned. They eliminate their outlier variables. They try to eliminate as many dependent variables as possible and try to get some good measurements, right? That's the whole idea behind an experiment. They take good notes and then come out on the other side having recorded their results and finally survey the results to compare them against their hypothesis. The whole point of this is to determine was my hypothesis accurate or not? Was it correct or not? And then they take that information and feed it into new experiments. Don't forget that last part that this is an ongoing loop that these new findings for each experiment, they feed information for the next experiment. And don't underestimate the importance of the final stage of the experimentation process, specifically the analysis, right? Determining is there a possibility that I did this experiment wrong or maybe my methods caused the experiment to go wrong. So this is what an experiment looks like. You probably learned about this in school. When you were younger, the scientific method, this relatively simple template that gives experimenters a way of thinking about performing their experiments. So there are some very clear differences in the way a lab operates from the way a business operates. It was the last time that you thought about having a hypothesis for a project, for example. Most of us don't operate this way. I'd like to discuss three lessons, though, three habits that we can take from the lab, from that experimentation process that I just talked about and apply to our work as developers in the service industry or in the product industry for those of you who are working on a product more specifically that can help elevate us into higher levels of innovation. But before we go into those three lessons that we can learn from the lab, I want to talk to you about today's sponsor, Imagix. Imagix is a cloud-based image editing and optimization solution. It's bill for developers and their API allows you to resize, crop, compress, apply, create a filters, and do much more just by changing the image URLs. This is an incredible, incredible service. The Whiteboard pretty much uses Imagix on all of our projects now. Earlier tonight, I found an incredible feature that Imagix provides. This isn't even in the read. I'm going to go ahead and give it to you for free. They do face detection and they will return to you the JSON information from their face detection. There's tons of awesome stuff that go far beyond what I'm talking about right now. For example, you can apply filters just by adding a URL per amp. This works with wherever your images are hosted. It already works with them where they are now, whether they're on Amazon as three or Google Cloud Storage and they've created libraries to make this URL manipulation and adding these perams to make it easier on you and to bring it into your development environment. For example, if you're using Ruby or Python or PHP or Go or Objective-C or Swift, the list goes on, all of those languages they have built libraries for you to make that image URL generation process much easier for you. Of course, you can resize images. You can do tons of stuff with this. Once you go and check it out, SpectataFam slash Imagix, by the way, they process over two billion images per day so they know what they're doing with images. It's incredibly fast. That's another added benefit. Instead of you taking on the load on your server, you're now offsetting that load to Imagix and they can handle it. They're processing two billion images per day. That's billion with a B. So go and check it out. SpectataFam slash Imagix. That's I-M-G-I-X. Thank you again to Imagix for sponsoring today's episode of Developer Tea and for creating one of the coolest services that you're going to find on the internet. So go and check it out Imagix. Lessons from the lab, which is what we're talking about today. We have three lessons that we can learn from the lab experimentation process. I want you to start viewing yourself a little bit more through that lens of the methodical experimenter when you're trying to solve a problem. Now this doesn't mean that you become cold to the business personality. That's not what this is about. You don't wear a lab coat to work and suddenly change your personality and you don't become a scientist just because you start thinking about how some of this experimentation process can benefit you. Instead you're learning how to take some of those pieces that work in that environment and bring them into your environment and apply them. These are the three lessons that I want you to learn from the lab. Number one, focus on one problem at a time. Focus on one problem at a time. Many experiments end up failing simply because the experimenter did not isolate the variables. Let me say that again and translate it into our business world. Many projects can fail if we don't isolate the thing that we are putting our energy into. The problem we are trying to solve. An unfocused experiment is not going to work because the experiment is highly focused to try to measure a specific thing. It's highly focused to try to validate or invalidate the hypothesis. If we bring this same concept of hyper focus, in other words, everything is focused on a single problem. In fact, not only is everything focused on the single problem, but you're actively trying to eliminate things that may get in the way of that focus. This is what we do in the lab. When we try to eliminate all external variables, we want our learning and our experiment, our validation or our invalidation of the hypothesis. We want that learning to not be marred by some kind of other thing. If it is marred by something else, then our learning ends up being difficult to validate. In other words, the outcome of the experiment is less reliable. Our assumptions about the data that we collect becomes less reliable in that experiment scenario. What this also does quite simply is it focuses your efforts. If an experimenter is doing one experiment to validate 15 hypotheses, then a lot of that stuff is going to cross over. A lot of that effort is going to end up being wasted because it's going to be very difficult to do anything when you're trying to do 15 things at once. Focus on one problem at a time. This is going to eliminate a lot of the other things that are floating around and causing noise in your experimental work. Lesson number two, develop a hypothesis. We've talked about this all day pretty much. The hypothesis is incredibly important. Before you go in to a problem, before you start actually working on a problem, develop what you think is a good solution for that problem. This is a guess. This isn't the solution. This is what you're going to try. The solution that you have designed, whether you've created a wireframe or you have a plan in mind for where you're headed with your software, that solution is a hypothesis until after it is built and validated. This is incredibly important for us to understand as developers. A lot of the time we try to build something and it fails and we try to put that failure on ourselves. But as experimenters, we have to recognize that many hypotheses fail. This is bleeding over into our third lesson, so we'll get there in a second. The important part here is that you go into all of your problems, all of your work, and have some level of hypothesis. This is going to allow you to develop intuition about the problems that you're solving, because you're going to be making guesses about how to solve that problem rather than just blindly walking into the maze. If you're blindly walking through the maze and you're not really keeping track of where you're going and you're just hoping that somehow you're going to solve the problem that way, that's effectively not having a plan. A hypothesis is a plan of action. Hypothesis is a plan of action with the intention to evaluate that plan of action once you've executed it. Again, lesson one, focus on one problem at a time. Lesson two, develop a hypothesis. Lesson number three, do not confuse the quality of your work with the result of an experiment. Do not confuse the quality of your work with the result of an experiment. In other words, if your hypothesis ends up failing, if the thing that you expected to work ends up not working, do not take this as the world critiquing you as a developer. This is incredibly important to understand. Every successful experiment, every successful research and development, scientist, engineer, all of those people have had hypotheses that fail and not only do they fail, but they are absolutely incorrect from the ground up. These researchers are not bad researchers. They aren't suddenly the world's worst scientists because their hypothesis failed. Instead, what they did in their experiment allowed them to learn about their hypothesis. This is the important thing to understand. When you go through the process of experimenting, validating or invalidating your hypothesis, the point is not to support yourself. That work is not to support your hypothesis, but rather to learn whether your hypothesis is correct or not, and then update your knowledge. When you have an incorrect hypothesis, when you walk out on the other side after learning that it is incorrect, you now have the opportunity to get better. You've just validated something to your brain, and your brain will adapt. That's the incredible part about experimentation. Instead of walking through your job and never having an invalid hypothesis, instead of simply writing code and knowing that it's basically correct and doing the same thing over and over, you're taking the chance of failure for the sake of learning. If you take nothing else away from today's episode, take that away. Getting from the lab means giving yourself the opportunity to fail for the sake of learning. Giving yourself the opportunity to fail for the sake of learning. Thank you so much for listening to today's episode of Developer Tea. I encourage you to go and look at the practices of a lab, of a good experiment. What does it look like? I think you'll find a lot of inspiration I certainly did. There are a lot of incredible things that people have done over the years and so many interesting insights into research and development that you will do in your development processes, in your code development processes, that have been experienced in labs for hundreds of years now. Go and check that stuff out. It's really, really cool stuff. Thank you so much for listening to Developer Tea today. Thank you again to today's incredible sponsor, Imagix. They are already serving up two billion images per day. Go and check them out if you need an image manipulation library. If you don't want to deal with the hassle of doing all that on your own server, Imagix has you covered. Spectre out of them. Slash Imagix. Thank you again for listening to today's episode of Developer Tea. And until next time, enjoy your tea.