If software could talk, if it could write an autobiography, it'd be an interesting thing to read, because software is developed by usually multiple people. Because people tend to bring their ideas and their experiences into writing that software. And if the software had some level of self-awareness, it would be even more interesting to hear it tell its own life story. In today's episode, we're going to talk about how software can develop over time in a way that makes plenty of sense, but unfortunately, cripples the developers who have to work on it. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal on the show is to help driven developers like you connect to your career purpose so you can do better work and have a positive influence on the people around you. In today's episode, I want to share maybe a personal feeling for a lot of you. The feeling of entering into a software project when it's already been established. You take on a project, maybe you're a new employee at an established company or maybe you are adopting a project from someone else or you may even be entering into an open source project. And as you enter into that project, you face a whole mountain of understanding gaps. You have to develop some kind of sense for the culture of the people who have worked on that software. You have to develop a sense of places in the software that have a lot of churn, that have a lot of change happening, dangerous places, places where people are afraid to make changes, perhaps places where people are less afraid to make changes, and how ultimately the software got this way. How did it get to the place that it's at today? Both good and bad. I don't have a perfect data set to prove this theory, but I do have anecdote and I think a lot of developers at least have experienced a similar event, a similar project, and it does agree with the way that people work. The average software project, I would imagine, looks a little bit something like this. You have places in that software that are new and they're exciting. The people who are working on those new and exciting things, they're probably doing two things. One, writing code that gets the job done, and two, quickly refactoring some of that new code so that this new area, this exciting area, it's perhaps the cleanest part of the project. Then you're going to have other places in the code that are simple. They make a lot of sense. Therefore, because they've been seen so many times and because they are straightforward, they're also relatively clean. These areas tend to have tests that cover them because the tests are easy to explain. The use case is easy to explain. There's probably some documentation, though it's probably spotty. Unfortunately, the documentation is probably not going to cover every single method, every single class, every single component, every use case. It's very likely that some of those methods or classes or components or use cases have changed since that documentation was written. Most likely, that documentation didn't get updated when those things changed. If your project is like most other projects, then you probably have some tests that really don't make a lot of sense. They work, but you're not really sure what they're testing. They seem to be just adding to the coverage metrics. Then you have other tests that work very well. In fact, you probably have a small number of very involved integration tests. These took a long time to write. Maybe they're relying on a significant number of other libraries or some intense setup to actually test that integration. Those tests are things that you're very proud of and you protect as a development team. Then there's other places where in order to write a test for that particular feature, you would need to go through the same rigor as you did in those particularly important integration tests. But you haven't done so. For one reason or another, those other areas are not nearly as well covered as some areas are. If your code is like most code, then you probably have some really weird language, both in the documentation and in the code itself. Some strange naming, perhaps some words that the company, this software was developed for or the group of people or the platform that the software was developed for. Those words, the language of those people that culture has made its way into the code. Finally, you likely have some areas of the code that have a lot of abstraction, a lot of indirection. The things that are loading are passing through a whole host, a long list of perhaps parent classes. For example, maybe there's a lot of inheritance or maybe there's a lot of deeply nested composition that's happening. Perhaps your rendering tree is really quite deep even though in a given file, it looks shallow. To wrap your mind around this code base, to understand everything that's happening in this code base and to be able to work on this code base with confidence, it can be really intimidating. The way that it got this way, the thing that happened to put this code in this state is really what happens in every project. It's very simple. It's the fact that humans are taking some kind of direction and implementing that direction in code. The reality is that humans approach coding as humans. We come to the table with our bias, with our emotions, with our opinions, with our experiences. And for that one day, for that specific piece of code we're working on, all of those factors combine together and we write code a little bit differently than we would have yesterday. And we also combine those human elements with situational factors like, for example, deadlines or revenue or fill in the blank for your particular effort. There are things that push our code in one direction or another. And often as developers, we try to demonize all of these things. We try to demonize our humanity or demonize the business pressures that play into the way that we build our software. And the truth is that we'd be much better off understanding our humanity. And then creating systems that support each other. That support the fact that we have different opinions. That's what we're going to talk about. Right after we talk about today's awesome sponsor, Linode. With Linode, you can instantly deploy and manage an SSD server in the Linode cloud. You can get a server running in just a few seconds with your choice of Linux distribution, resources and the location of your node. Linode has been a sponsor for a long time and we usually talk about these points, but I want to spend a moment to talk about the node location. Picking a node location quite literally means picking a geographic location where your server will physically be located. Now this is important because the distance from your users, from people who are accessing that server to you or the distance to your server can make a big difference in how long it takes to load and use whatever your server provides. So for example, if you are using your server for a personal project, if you would want to pick a node that is closely located to you from geographic perspective. Linode provides so many things like configurable node locations, but they also provide for developer to listeners for free months on a gigabyte of RAM. That's a $5 a month plan. They're going to give you $20 worth of credit for free for being a developer to listener. They also have a seven-day money bag guarantee. So even in that fifth month, if you pay and you don't like what you're using on Linode for whatever reason, then you can get that money back. Linode also has hourly billing and a monthly cap on all of their plans and add on services. Go and check it out. Head over to spec.fm slash linode to get started today. When you check out, you want to use the code Developer Tea2018. That's Developer Tea 2018. That will give you that $20 worth of credit. There's so many other things that linode provides as a part of their service. We're not going to get through them all in today's episode, but linode is a continued sponsor of Developer Tea. Thank you again to linode for sponsoring today's episode. We're talking about the etymology of a software project. All of these things, we probably have some bad and some very good memories that are being evoked by talking about these various types of problems that we face in software. Some of these things can make us feel proud. Some of them can make us feel a sense of shame and perhaps the most important feeling for us to pay attention to is fear. Fear is important because fear is often an indicator, the feeling of fear, is an indicator of some level of uncertainty. The unknown. This is what often causes fear as software developers begin to work on a new project. The fear of the unknown, and specifically, the fear of the unknown as it relates to changes, things that I might interact with, things that I might do. If you give me a task, however you are managing those tasks, doesn't really matter. If you give me a task, and I take this on as a software developer, and I go into this project that has all of these idiosyncrasies that we've already discussed in the earlier part of this episode, then it's very possible, if not likely, that I'm going to have some level of intrepidation. I'm going to be uncertain about the changes that I'm getting ready to make. And so understanding that software comes about as a result of human processes, that should prompt us to create systems that support that human side of software development. So what does it mean to support this? Well, first of all, we have to recognize what of those human traits can cause software to be dangerous. Right? And again, we said it on previous episodes of this show. I'm going to say it again on this episode. If you follow the fear, in other words, if you pay attention to what developers are afraid of, you'll often uncover places where your software needs to be refactored, needs to be changed or rethought. In some way, that software is causing a level of uncertainty. Now, some uncertainty is absolutely attributable to a lack of experience for a given developer. And this needs to be kind of brought out as well. But very often, uncertainty and fear come as a result of a developer feeling like there's something that they should know, but they don't. And perhaps that thing that they should know is not necessarily rudimentary programming knowledge, but instead it's some kind of knowledge that's embedded in this project, something in that life cycle, that etymology, something human, some decision that was made along the way or some colloquial language that was adopted along the way, some vocabulary that is not obvious. Maybe some level of indirection is confusing or maybe even unnecessary. And so as new developers come on to projects, this is a critical point to understand the fear, the uncertainty that those developers have, because this is going to point you in the direction of places where your code has the artifacts and perhaps even in a damaging way, the artifacts of the humans that have built it along the way. So how do you avoid or perhaps make systems that accommodate for these human issues, these human errors? Well, this is really kind of the long-term topic of this show. How do we deal with our humaneness as developers? And we're going to talk about this more in upcoming episodes, because I think this is a bigger topic than we can cover in a single episode. But for example, perhaps it's a reasonable idea to create code in combination with someone who is unfamiliar with the project, someone who is working on something entirely different. These people who have very little context for whatever code is being written now can illuminate things that have gone forgotten or otherwise ignored things that are taken for granted. As we take more things for granted, and as we create these subcultures and colloquialisms and language in our code, we begin to get further and further away from simplicity, from a base level of understanding, from approachability. And so if we can create systems that bring us back to some baseline that pull us out of our embedded context and require us to think more like beginners, these are the kinds of systems that perhaps counterintuitively can improve our code. Thank you so much for listening to today's episode of Developer Tea and I encourage you. If you found this episode valuable and you're excited by the idea of talking more about how our humaneness affects our code, I encourage you to subscribe and whatever podcasting app you're using right now so you don't miss out on those future episodes. Thank you again to Leonard for sponsoring today's episode. You can get a server running in just seconds. This is an SSD server in the Leno Cloud. You can choose your Linux distribution, your resources and your node location. Go and check it out. Spec.fm slash Leno. Make sure you use the code Developer Tea 2018 at checkout for $20 worth of credit. Thank you again for listening to today's episode and until next time, enjoy your tea.