We've all heard it said before, whether in our company or maybe someone we know in the industry, we are unique. What we do is special, it's not normal. The way we run our team, it's different from the average team. And we hear these stories about why these teams can't conform to some set of best practices. We're going to talk about this on today's episode of Developer Tea and hopefully help kind of contextualize what people mean when they say unique. And then also kind of bring out into the light the implication of uniqueness. My name is Jonathan Cutrell, I'm listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective and purpose in their careers. What do people mean when they say that they are unique, that they have some special circumstances? We'll run through a few of these kind of trigger phrases to identify the kinds of people they were talking about. Because they may say, oh yeah, we have special circumstances. We have particular restrictions. We're in a highly regulated industry. So the things that work over there don't work over here. We have unique constraints. Sometimes it's based on the timeline that the person that you're talking to bring up the timeline. They'll say, well, we're not really in that phase of our company. We're in a different phase, we're in an important time for a company. These are the kinds of phrases that you hear. And usually this is in response to somebody saying, okay, I think I see a problem with your process or I see an opportunity, maybe is a better way of thinking about it. I see an opportunity for you if you were to slightly adjust the way you do things in this particular way. And the response is we can't because we are unique. And sometimes that uniqueness is even something that they've adopted as a part of their cultural identity. Right? So in other words, we can't do that because it will change who we perceive ourselves to be. It will change who we are and we don't want to do that. We don't want to start requiring that we write tests for every single feature because it will change the culture in our company away from kind of this homegrown, hacky, fast moving startup culture that we're used to. And we don't want that. We want to retain some of that. Now here is what is actually hidden behind this kind of defensive posture of uniqueness. Our uniqueness is an advantage and it is such an advantage that we must protect the uniqueness. That is one kind of assumption that's built in another possible assumption. If that one's not true, we must protect the uniqueness because it's our advantage. Another kind of parallel version of this is we can't, we don't have the ability to change our uniqueness. It's a constraint that we don't have any levers to control that it's kind of imposed on us by let's say policy, for example. So a very common kind of iteration of these arguments is we must use our own homegrown software and we have to use our own platform, our own framework that we built in house because, fill in the blank. Fill in the blank in this case might be because we have some licensing restrictions or because we can validate the security or because we don't want to tie ourselves to an open source project. There's a lot of reasons why you might fill in the blank there and many of them could be challenged on the grounds of pure logic, of pure validity from a logical perspective. For example, you could just as easily validate the security of an external framework of a third party framework. So what we see is that very often people argue against adopting, let's say a best practice, a framework, a tool, something that ostensibly could make them better. In one particular way, it might optimize a particular metric. We will save whether it's better or not for you, the implementer, but maybe you are pushing against the idea of streamlining a particular process because of your uniqueness and built into that uniqueness, you've tied up, you've held hostage, your value. You've attached the value that you provide as a company, as a service, as a product to your uniqueness. Why do we do this? That's what we're going to talk about right after we talk about today's sponsor, Voyage. Voyage is a new sponsor for a Developer Tea. It's a tool built by and for developers. I've seen a demo of Voyage, it's pretty awesome. Voyage saves hours of your time by automating staging environments of your full stack app for each pull request and it includes feedback tools with each deployment so you don't have to juggle emails, Slack messages, Excel spreadsheets, etc. from your counterparts. Some of our favorite features include full stack development. You've spent a lot of time building a complete app so why are you only able to deploy the front end? Well, unlike other tools, Voyage builds and deploys your entire application, not just the front end. If you have multiple repos, multiple services, it's not a problem. Voyage deploys your complex applications the way that you built them to be deployed. Unique deployments happen for each PR and with each Voyage deployment, a unique URL will be generated and delivered to you and your team. But as we all know, a PR may take several commits and that's why the URL remains consistent until the PR is closed. Finally, these built-in feedback tools will allow your whole team to get involved quickly. Once your app has been deployed, you can send your team a unique URL and wait for the feedback to come in via a variety of integrations, for example, JIRA and GitHub. Your whole team can view the link without needing a third-party account, no GitHub account required, but it is safe and secure. Your code is completely secure, it's never accessible by any team. Not actually even includes Voyage. Each subscription plan also includes the ability to password protect your deployments for that extra layer of security. Set sail the voyage in safe time and headaches with Voyages automated staging environments. Go check it out head over to voyageamp.io. That's v-o-y-a-g-e-a-p-p.io. Thanks again to Voyage for sponsoring today's episode of Developer Tea. Why do we equate uniqueness with value? Or why do we conflate them at the very least? Sometimes uniqueness is indeed valuable. We can see uniqueness as a signal, not necessarily proof, but a signal of scarcity. And anytime there is scarcity, the kind of old brain, or lizard brain, sees that as something that we need to pay attention to. A scarce resource is something that if it does exist, we want to get it right away. And if we pay attention to scarce resources, if we see those unique things, then we're more likely to attach our attention to them. So this could be an evolutionary argument for why we care about uniqueness or novelty. Another reason we care about novelty is because of a competitive advantage. This is a term that very often gets kind of thwarted in to be almost equal in meaning to uniqueness. If something is unique, then it has a higher chance of gaining a competitive advantage. But if you are the only one of something, which is what is implied by uniqueness or novelty, then you don't really have competition. Or if you're the first to market, then you kind of gain the name recognition or perhaps you have technology that's ahead of the curve. It's, you know, other people can't outpace you. And so we can easily see why uniqueness is often kind of transmuted into value in our brains. But there is kind of a final, important factor that we often discount or we ignore that's kind of built into the arguments for retaining uniqueness, especially as it relates to our processes or the tools that we use. And that is that the uniqueness itself requires a particular support system or the uniqueness of the value, right? The uniqueness of the thing that you've provided, let's say to your customer, the thing that makes you actually value wise unique is also tied. To the unique constraints that you've adopted within your company. Let's say for example, that you are in a highly regulated industry that requires, you know, particular certifications, people with those certifications to review each item that goes out, right? So you have some kind of bottleneck constraints, something that is probably considered inefficient with relation to other processes they might have, but you have to retain that particular inefficient step in order to continue providing those products because of some kind of external factor, some external constraint that you don't have control over. But very often, even with the smallest amount of inspection, we can find that the things that we do that are unique or the things we choose not to do because they break our unique processes, they would require us to change those processes, those are not actually necessary or critical to maintaining our uniqueness in the market. This calls to mind a particularly interesting effect called the halo effect. The idea is you have a high opinion of somebody in one particular area. Maybe you have come to respect them for, let's say, being a good athlete or maybe they are in your eyes the ideal parent, for example. And you allow that one area, your opinion of them in that one area, to kind of color your opinion of them in all areas. That's the glow of the halo, if you will. And so when we imagine that somebody is a good person in one particular area, then we automatically fill in the blanks. We assume that that carries over into other areas as well. There is a similar thing happening here where we assume that uniqueness provides value on its own. And we're not really kind of diving into the reasons why uniqueness is actually valuable because sometimes uniqueness isn't valuable at all. Sometimes we use uniqueness as kind of a scapegoat for inefficient processes and we are not investigating that uniqueness to determine if it is actually providing any kind of competitive advantage in the first place. So this is what I recommend that you do. As you are facing particularly big decisions, because most of the time the things that we're talking about, the places that it's going to matter are going to be in the big things. When a big decision might be changing the framework that you use, adopting a new language, et cetera. When you're thinking about these bigger decisions, if you are resisting adopting something like a best practice or something that is a very commonly used approach, because you're kind of using the wisdom of the many people who have solved very similar problems to us before, if you're pushing away from using that, ask yourself why and really dig into why. Don't allow that uniqueness as an answer to be enough. What about our uniqueness is providing value in this specific way. Thank you so much for listening to today's episode of Developer Tea. I really do believe that this is a kind of foundational concept that a lot of people get wrong. We do this in our personal lives as well. We imagine that we need to be special and unique in order to be valuable as an employee. This isn't necessarily the case. Sometimes we can be just as good as the next person and reliable and dependable worker. We don't necessarily have to chase after the most unique resume or job experience history, those kinds of things are not necessarily going to translate to value in your career. Thank you so much for listening to this episode. Thank you again to Voyage for sponsoring this episode. If you want to get started with Voyage's automated staging environments, go check it out. Head over to VoyageApp.io. That's VoyageApp.io. Thanks so much for listening to this episode. Until next time, enjoy your tea.