If you have ever lived in a dorm room, then you've probably heard of the company Ikea. And you probably have heard of that many way. But especially if you've lived in a dorm room because Ikea's furniture is particularly, well, it's affordable. One of the reasons Ikea's furniture is so affordable is because most of it comes unassembled. We've talked about this on the show before, but as it turns out, this isn't just for the affordability aspect of the furniture. You also have a part of your brain that appreciates the building process. Once you've actually gone through the process of building your Ikea furniture, you become somewhat connected to it. You've created a shared history, and the work that you put into building it has actually made you feel something positive about it. This is called the Ikea Effect. And we talked about this back in July of 2015, actually, on Developer Tea, quite a while back. The Ikea Effect is really important to understand because developers go through this all the time. We have another version of this called the Not Invented Here Syndrome, NIH, if you want to abbreviate it. And really Not Invented Here is about trusting other people's code. In today's episode, we're going to extend this a little bit further. 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 so they can do better work and have a positive influence on the people around them. In today's episode, we're talking about principles and protocols. Principles and protocols. And we're not talking about the technical version of protocols for today's episode, although having an understanding of what a technical protocol is may help you get some intuition for what we're talking about in this episode. But I want to talk about kind of the difference between these two things. And then we'll use the information about the difference between a principle and a protocol to help us determine how to create better protocols. So for not talking about technical protocols, what are we really talking about? Well, a protocol is quite simply an agreement, a handshake, kind of a contract, right? Between you and usually another person with computers we deal with a computer to computer protocol. Really, it's more of a person through a computer. I tell my computer how to understand your computer. That's how we get things like Hypertext Transfer Protocol or HTTP. The interesting thing about a good protocol is that it allows for scale. If we strip away this discussion about computers and we've returned to the Industrial Revolution, for example, we can see the same concept, the idea that we're all going to agree on a standardized size of a screw, of a bolt or various parts of an engine. And this becomes our protocol. Because we have standardization, we can now kind of agree that we're going to use a higher level abstraction. Instead of creating those screws, we can go and source those screws. We can get those bolts from the hardware store. This abstraction is essentially a protocol. We're allowing ourselves to stop caring so much about the minute implementation details, but we're also allowing for ourselves to share those resources together. I can send a million bolts to hardware stores all over the United States or all over the world for that matter. And because everyone else is using them, I don't necessarily have to know what those bolts are going to be used for. If I'm a bolt manufacturer, which I'm not, but if I am, then I can send out these bolts and I don't really have to know any specific details about how they're going to be used. And in the same way, we have computer protocols that do very similar things. I don't necessarily have to know what you're going to be transferring over HTTP. I can create the protocol for one point to understand the other point. Now, whatever happens between those points, the protocol doesn't really have to care about that. And this is indeed the value of protocols. A standardized way for one thing to communicate with another or to cooperate with another. All right. So now we have the groundwork laid for what a protocol is. Now we need to contrast that to principles, something we talk about a lot on this show. What exactly a principle is. But before we do that, why are we comparing these two things? Well, as it turns out, this collision actually happens very often within a company or on a project, open source project for that matter. Even within our own lives, the collision between principles, which is something that is true, something that applies beyond myself, beyond my opinion, something that I've observed as kind of an axis and protocol. So what is this collision that I'm talking about? Well, protocols are highly opinionated. For example, returning to our maybe overused discussion on the bolt, someone had to make the call of which bolt sizes to support, specifically the size of the head of the bolt, the diameter of the head of the bolt. And as it turns out, there's actually two different sets of head sizes for bolts, the metric size, which is measured in millimeters, and then the standard size, which is measured in inches or fractions of inches. And at some point, someone in the manufacturing of bolts had to decide on what sizes to support. And as it turns out, this and many other aspects of the industrial revolution were a huge success. Many of the protocols chosen at the risk of sounding hyperbolic kind of supercharged human innovation around the world, really, but the conflict between protocols and principles comes down to the idea that protocol is highly opinionated and a principle is an external reality, something that we've observed as true. And so how can we develop good protocols when they're based on opinions? And unfortunately, here's what so often happens. In your company, you or another developer, maybe senior management, or someone that isn't even at the company anymore, they establish a protocol, they establish a way of doing things. Maybe it's a set of tools, maybe it's a particular idiomatic way of writing code, or maybe it's something more human, maybe it's more behavioral, like for example, a schedule, or even values that you all kind of agree are good, whatever good actually means. And so this protocol becomes established and then the company or the individuals in the company who are within a department or within a small team, they adopt those protocols. And as we practice protocols, over time, we can easily blur the lines between what once was an opinionated and perhaps even arbitrary decision in what is actually principle, something that is fundamentally true. And so we convert our protocols into principles. A similar occurrence is when we allow our practices to drive our values. When we allow something that we're doing, some activity that we partake in, some protocol that we're practicing, we allow that to bleed upward into our values. This can be problematic and I want to talk to you about how we can potentially avoid this. But first, I want to ask you a question about what you do when you're stuck. When you're stuck specifically on a technical problem. Most likely you're going to Google the question and then the top resources that you open up, you're going to help you answer that question. So many times that top resource just so happens to be Stack Overflow. I would venture to say that anyone who's listening to the show already knows what Stack Overflow dot com is. Suffice it to say Stack Overflow has probably saved a lot of people, a lot of time, a lot of money and a lot of grief and ultimately helped make them more successful in their careers because it's a shared knowledge base for common problems that people have. Really any question that you can imagine asking Stack Overflow probably has an answer to it. Now, there is one exception. There is a group of questions that I have that simply are not answered on Stack Overflow. That's because they're specific to my team. They're specific to the people that I work with on a day-to-day basis. Maybe to me and a client, for example, there's a bunch of different teams that I could work on. Stack Overflow is solving this problem with Stack Overflow for Teams. Stack Overflow for Teams helps you and your team get answers fast so you can get back to building great software. It's basically Stack Overflow, but just for your team. You can try it today for free for 14 days. Stack Overflow for Teams is a private and secure home for your team's questions and answers. Stack Overflow for Teams, you're not going to be digging through old, outdated readmeas. You're not going to be searching through all your Slack messages or digging through your emails and trying to figure out which one is the best one, which password is the right password or which procedure or which gold file versus webpack, which thing are you using. You don't have to do all that anymore. Instead, you can use Stack Overflow like you're used to using and it'll all be in one place. You can take advantage of the sophisticated software that over 50 million people already love using every day in a private and secure environment with Stack Overflow for Teams. Go to s.tk-Developer Tea. That's s.tk-Developer Tea to get started today. Thank you again to Stack Overflow for sponsoring today's episode of Developer Tea. We're talking about protocols, we're talking about principles, and how we can actually parse between them. How can we avoid this problem of protocols slowly slipping into principles? Well, the first thing we need to do as companies and as people, as individuals, we need to identify, explicitly identify what our principles are. This is no secret, this is no new thing, this is definitely something we've talked about on the show, but this is another benefit. Defying exactly what your principles are gives you the freedom to make everything else follow those principles. In other words, following those principles means everything else may change. For example, let's say that you established for your software development company, the principle that verification is better than intuition. Verification is better than intuition. This is a straightforward principle that can apply to so many different domains. For example, you may use this concept, verification is better than intuition, to justify a testing protocol. Your testing protocol says that because verification is better than intuition, we want to not only take advantage of good design practices with our code, but we also want to cover that code with tests, some form of programmatic verification. This is a protocol that is derived from our principle. This is the important factor. The protocol is something that we decide once we understand the principle directly. We can form our protocols around the principle and subsequently as the environment changes, as the protocol becomes inefficient or as the protocol becomes too stale or otherwise too restrictive, we can adapt the protocol without straying from our principle. In this case, it may be tempting to view the principle as testing is good or we always test our code, but that's not what the principle says. In fact, the principle doesn't even mention code. It simply says that verification is better than intuition. So if there is a way that we can verify our code without writing programmatic tests, then perhaps we update our protocol to take advantage of that new reality. In the end, what this allows you to do is avoid misplaced dogma and keep focused on the intended effect of any protocol. As your designing protocols, I encourage you to look at the protocols that other people are using as well. This is how the IKEA effect and non-invented here syndrome comes into play. As you are surveying your available protocols to respond to your established principles, remember writing those principles down and identifying them very explicitly is extremely important. As you're identifying ways to practice out those principles through some sort of protocol, I encourage you to go and look at other people's protocols as well. And here's why. One of the major advantages of protocols, remember from the Industrial Revolution, is that if I have a shared protocol with another person, or in this case with the industry, web developer industry, I gain some benefits of economies of scale. In this case, if I establish that I use similar tools and I use similar syntax to other groups of developers, then things like hiring become a little bit easier. Things like onboarding become a little bit easier. Bug tracing, those things become a little bit easier. Because we have this body of knowledge, remember we meant to stack overflow, we have a body of knowledge around a particular subject that if we've all agreed on a particular protocol and a limited set of tooling, then we have very similar problems that we all run into. We have very similar kind of pathways that we all travel. So the more people that travel a particular pathway, the more likely it is that someone else has done exactly what you have done and therefore run into the same problem that you've run into. If instead you decide that you want a unique protocol, which is tempting, by the way, because we have the Ikea effect, because we have the not invented here syndrome that affects our brains, we don't really want to adopt an existing protocol because for some reason, we may believe that our own protocol, our own customized solution for ourselves, is better, is inherently somehow more directly solving our problem. So we very easily jump to the customized solution, the custom protocol for accomplishing a task. And unfortunately, when we go that route, it becomes particularly expensive. We spend a lot of our time forging that custom route, we're creating our own path. And we often lose those economies of scale. Now, that's not to say that there's never a time where custom is important. There are plenty of custom fabricated parts, even now that the industrial revolution has really changed the way we think about manufacturing. There are still reasons that custom parts are made. But for the average case, which most of you who are listening are probably in this average case, there's going to be something that can solve your problem that has already been battle tested that's already been run through its paces. And instead of you deciding directly from your principles, creating this raw protocol from your principles, finding other people who have created raw protocols, and then choosing one based on your principles is a much faster solution to productivity. And it's going to yield a higher benefit in the long run. For the principle is the thing that matters. And if you can detach yourself from the protocol, if you can detach yourself a little bit away from caring about whether you invented it versus someone else, then you're much more likely to gain benefit from those economies of scale from all the things that we've discussed. Thank you so much for listening to today's episode of Developer Tea. By the way, if you want to ask me a question that you'd like me to cover on the show, you can email me directly at developerteatatgmail.com. You can also find me on Twitter and at developerteat. Thank you so much for listening. Thank you again to Stack Overflow for sponsoring today's episode. Stack Overflow has launched their platform for teams. A private space where you and your team can discuss things that really only you want to see and are only relevant to your team. Head over to s.tk slash developerteat.s.tk slash developerteat. To get started today, the first 14 days are free. Thank you so much for listening. And by the way, if you haven't subscribed to this show, I encourage you to do so in whatever podcasting app you are listening to right now. So you don't miss out on future episodes. Thank you again and until next time, enjoy your tea.