What are you afraid of? What we're afraid of motivates us. And it's not just the things that we're afraid of on a large scale. Sometimes it is very small, small changes that we make as a result of our fears. In today's episode we're going to talk about how we might be able to uncover some of those fears and how our decisions may be impacted by those fears. 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. And you've probably heard that in order to get over your fears you have to face them. Now why is this commonly accepted cliche so pervasive when we talk about fear? And the reality is of course it depends on what your fears are. Maybe your fear is that you're going to accidentally jump off a cliff and in order to face that fear you have to walk up to that cliff and prove to yourself that you're not going to jump off of it. But for the sake of working as a programmer and how this affects you at a practical level as a programmer is to understand that a lot of your decisions are motivated by some kind of underlying fear. It's not just fear that motivates us. We're going to talk more in this week's episodes about other things that may motivate decisions that you otherwise may make a different decision. Let's say you were consulting for another person and trying to give them advice. You wouldn't make the same decision but because of some emotional state that you have you've decided to do something different than you would recommend for someone else to do. So fear is not the only thing that drives our decision making but certainly is a powerful decision making factor. So as an illustration I'm going to use a very common example that occurs in small startups all over the place. That is the overworked senior developer. And it's not just that the senior developer is working too many hours but that they're having to be responsible for all of the code. There are only ones that are allowed to release code to production. They're the only ones that are reviewing pull requests. All of the code goes through them. And of course you can see that this is a bottleneck. This isn't something that we would design. We wouldn't want a single point of failure. What happens when that one senior developer is available. And this can happen not just because they choose to leave which is one way that they may become unavailable but let's say they get sick or maybe they want to go on vacation. Eventually there will be a time when that senior developer is unavailable. So this isn't an ideal state. And how can we figure out why this happens so often? I would guess that nine times out of ten. If you were to talk to the senior developer and ask them why they are a bottleneck they would say because it's the safest thing for us to do. Because I am the one who knows the most about this system. Because the other developers who work here haven't really been here long enough to understand everything that's going on. And we don't want to risk putting our system on the line. Having a large amount of downtime maybe we'll lose a bunch of our user base if we have a lot of downtime. So we're going to unpack some of these reasons and really drive at that fear right after we talk about today's sponsor. Today's episode is sponsored by DigitalOcean. DigitalOcean is providing Developer Tealisteners with a hundred dollars worth of credit just for going to d.o.co slash t.e.a. today. DigitalOcean is the easiest cloud platform to run and scale your applications from effortless administration tools to robust compute storage and networking services. DigitalOcean provides an all-in-one cloud platform to help developers and their teams save time. And running and scaling their applications. Go and check it out. Head over to d.o.co slash t.e.a. Thank you again to DigitalOcean for sponsoring today's episode of Developer Tea. So many of us have been in this position before. The position of the senior developer who really if they were to kind of let go, if they were to loosen the reins a little bit, unfortunately things do fall apart. Sometimes we do have downtime. Sometimes we do seek code shipped to production that ends up breaking the system. So it seems that the fears are validated. And so the answer that we very often, unfortunately again, we answer by creating support systems to maintain our fears. So the fear again is that the code that may go into production that the senior developer didn't review, that code itself may be totally fine, but unfortunately because of some particular quirk that was written a year ago, it has to be written differently and it brings the system down. And these are the fears that we have. And so the answer that most organizations come up with is to free up more time for the senior developer or to hire more senior Developer To try to educate them about what's going on in the system so they can be the ones that carry this load. And this really perpetuates the problem. The problem is that you're afraid to change your code base. The problem is the root of that fear is that you don't have confidence to make changes to your code base. And perhaps the root of the fear is that you're afraid that somebody who doesn't have enough knowledge will break things. And so these are the problems that you want to address. You want to address the things that you're actually afraid of rather than providing resistance to that fear, providing some kind of support to surround the fear. Instead you want to address these problems, the fear of change. How can we address fear of change? Well one example would be to have a solid testing suite. So that if something, especially the critical parts of your application, if you're not testing those critical parts, then of course you're going to be afraid of some kind of regression. Having something that will signal when those regressions occur that you have a test suite and that test suite is run no matter what before that code goes to production. Of course this sounds pretty obvious but very often these are the things that get left behind. We skip testing and we think that the only benefit to testing is that added layer of pride or added layer of quality but in reality that testing may be the key to freeing up that senior developer's time. If you fear that someone is going to accidentally push their code to master or that a young developer is going to be able to push untested code to your system, then this is the fear to address. Then of course there are many ways to address this. You can create some kind of continuous integration where no code that is untested makes it to a production, production server. Ultimately you want to put your energy into the things that you are afraid of. This brings me back to the very beginning of this episode. This requires you to face those fears. Face the fears that maybe you are not confident in the Developer That are on your team. How can you work to become more confident in those developers? Maybe the fear is with your own performance. Maybe you are afraid that if you are not the one that is reviewing the code as a senior developer, actually what is your value? Maybe you have some sense of imposter syndrome or you are trying to make sure that your job is not eliminated by you no longer reviewing code. These are very human emotions and these are the fears that developers deal with all the time. It's important if you want to be effective. It's important to find the fears, face the fears and then address them directly. Don't build support systems for bad habits. Don't create ways to continue and it may even look like a good idea. Hiring more senior developers, that seems like a perfectly fine idea. There's nothing anti-pattern about that. But if you are not addressing the fear directly, if you are supporting that fear, you will always have that fear's influence on your work. So never be freed up to do the best work that you can. I encourage you to write these fears down, get familiar with them, understand them as closely as you can. And if you can, try to talk to other people about their fears and what you think their fears are. Fear is an intensely personal thing and very often we become self-conscious about our fears. So it's important to talk about them. It's important to drive towards an ego-less discussion about fears and how those fears are affecting the work that you do. Thank you so much for listening to today's episode. Thank you again to DigitalOcean for sponsoring today's episode. You can get a hundred dollars worth of credit by going to dio.co slash tea as dio is in digital ocean.co slash tea that's the word t. Thank you again for listening to today's episode. If you haven't subscribed in whatever podcasting app you're using right now, I encourage you to go and press that button. The reason for that is because we released three episodes a week and if you found value out of this episode, then you're likely to find value out of more episodes. And unfortunately if you don't subscribe, it's pretty easy to get behind. So I encourage you to subscribe in whatever podcasting app you use. Thank you so much for listening and until next time, enjoy your tea.