Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell, and in today's episode, I'll be answering Cody's question about whether or not he is too slow as a developer. Before we dive in today, I want to take a moment to share a really exciting personal note with all of you. I feel like so many of you have been listening to Developer Tea since basically the very beginning of the show. In a lot of ways, you are kind of the extended family, the spec extended family. So I want to take a moment and celebrate with you all. My wife and I found out that we are expecting a child this June. We're incredibly excited, and we're looking forward to it, looking forward to sharing more about that with you in the future. You know, I don't say a lot about my personal life on this podcast, and that's intentional because it's such a short podcast. And going on long rants about my personal life and my personal experiences, that doesn't really add a ton of value. But hopefully, you will find a moment or two to celebrate with me about this really exciting life event. So if you want to keep up with me a little bit more closely, personally, like at the personal level, you can follow me on Twitter and also on Instagram. It's the same username. It's Jay Cottrell. I'm not super active on both of those, but that's probably the best way to keep in touch with me. That and, of course, the Spec Slack community. You can go to spec.fm slash slack, and I am in there. Also, I believe as Jay Cottrell. I'm Jay Cottrell pretty much everywhere. So go and check those things out. Of course, links for those can be found in the show notes at spec.fm as well. Let's jump into Cody's question. Cody sent me an email at developertea at gmail.com. He says, hi. As I've previously said when we have chatted in Slack, I get a lot of value from Developer T. Furthermore, I have recently found out that I'm a developer. I've found that same value within the Spec FM community as well. For all of that, I am grateful. I do have a question for you. When it comes to programming, I'm not very fast, and I never have been. I am a self-taught developer, and so much of my process involves reading documentation and testing what I'm reading in a sandboxed environment, building incrementally and ensuring stability and quality. I program very methodically and purposefully. It seems like I'm always up against the wall. I'm always up against the wall. I'm always up against the wall. I'm always up against the wall. I'm always up against the wall. I'm always up against the wall. I'm always up against the wall. At the same time, I'm always up against the choice of missing a deadline or reducing the quality of my code. For instance, I've recently started at a new company as a senior member of a dev team. Over the past two months, I've put a lot of work into version 2, an upgrade implementing a lot of performance and stability measures that seem to me to be common-sense practices. My team lead, however, has steadily found cause to remove everything I've added, citing our upcoming deadline. He claims that most of my improvements are going to require further development time, some of which is true, though doubtfully not more than it takes to remove it. How can I improve my speed, or should I? I take great pride in delivering high-quality code, and I'm starting to doubt if I should be employed by a company that seemingly doesn't want that quality of code, but I'm unsure of how I ought to proceed. Thanks again for your show and all you do to help us devs. Cody, first of all, you're welcome for the show. You all are helping me as well, so thank you for listening. I'm very excited about this question because I think this is actually something most developers go through, not just a few, I think a lot. If not all developers, at some point, they go through this exact experience. It's an expectations versus reality mismatch. You go down the road of building high-quality code, and it feels wrong to take shortcuts. We spend a significant amount of our energy and time learning the right way to do things to avoid issues. A lot of us are still learning those right ways of doing things. We're still refining our processes. We're still learning why tests are important and what the different types of tests are. We're learning what amount of coverage is enough, when to feel confident in our code. We're learning about patterns. We're learning about anti-patterns. We're learning about ways of refactoring our code and ways of isolating our code so that it's a little bit more maintainable, so that our dependencies aren't colliding. There's so many things that we are learning every single day as developers, and it's very difficult to ignore some of that learning, to take a subsection of what we have learned and go against that. We have some ingrained beliefs as developers, and a lot of those ingrained beliefs are built from a very, very good place. In other words, there are people who have come before us who have learned from their poor experiences. They've learned the hard way so that we don't have to learn the hard way. And we can trailblaze a path that has already been kind of laid out in front of us. Cody, that sounds like you are in that spot right now. And there's not just one problem going on here. There's a couple of different problems that are occurring in this scenario, Cody. Before we jump into those, I want to say, first of all, that it is your job to have a stake in the quality of your work. No one else is going to care about the quality of your work as much as you will. And the reality is that there are going to be people who oppose the amount of energy that it takes for you to create quality work. There are going to be people who ask you to take shortcuts. And it's important as a developer to cultivate two kind of opposing! They seem to be opposing at least skills, right? The first one is maintaining a veracity, a strong-willed and unwavering commitment to quality. This is your job to have that strong-willed, unwavering commitment to quality. A lot of developers actually get to that spot. And Cody, you seem to be in that spot where you are dedicated to high-quality code, and it's difficult to imagine going against your better judgment. The problem, that a lot of developers face, is that they don't also learn this second skill, which is called advocation. Advocation. Basically, it doesn't really matter how committed you are to something if you can't get other people sold on the value of that commitment. And the way this plays out usually, the way that most developers see this actually working in their day-to-day job, is that they have to become kind of the ogre in the office. They are the ones who seem like the stick in the mud. A lot of the work that a developer does, a lot of the standards that a developer wants to follow, are difficult to explain to non-developers. And some of them are perhaps even impossible to advocate for, to sell to non-developers. So this is a skill that takes time to develop, but effectively, what you want to do as a developer is learn how to advocate for quality. Learn how to advocate for quality. Learn how to advocate for quality. Learn how to sell your team members and your clients on the importance of the quality of that code. So if you think about it this way, when you go to buy a car, let's say you're buying a car, and the salesman tells you to buy the more expensive car, but they don't give you good reasons as to why you should buy the more expensive car. They tell you it's a better car, but when you ask for more details, if that salesman says something along the lines of, just trust me, I'm the expert, well, you as the customer, you're probably not going to want to spend much money with that salesman. You want to understand in your terms, you want to understand in a way that is applicable to you as the consumer, you need to understand why that car is worth the extra money. There's some similar psychology at play in the average workplace. If you have someone who has the ability to sign off on, for example, extra energy, if you're a supervisor, a Cody can sign off on you spending some more energy on a particular feature so that you have better test coverage, or you've spent the time actually going through the documentation to a sufficient extent that you feel like the quality is certifiable. If you are trying to convince that person to give you that yes, then in a way, you are trying to sell to them, right? You're trying to explain to them the exchange of that extra margin, that extra time. And they have to exchange that for value. So it's your job, Cody, to go and figure out how to communicate value to your supervisor, how to communicate value to your client. So that's the first step in this equation, figuring out that number one, you have to have an unwavering commitment to quality, but number two, you need to learn how to sell the value of that quality. You need to learn how to explain, that value to key stakeholders who have the power to make those decisions. And we're going to take a quick sponsor break. And then I'm going to come back and give you four key takeaways from today's episode, specifically wrapped around some of the things that Cody mentions in his email. Today's episode is sponsored by Linode. Cody, with all of the things that you feel like you are slow at, one thing that you can certainly be very fast at is getting a new server up and running. And that's what we're going to talk about today. So let's get started. At the At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At At worth of credit at checkout. Once again, that's spec.fm slash Linode and use the code developer T20 to get $20 free of value on Linode. So I've got four key takeaways for you, Cody, and these takeaways are really not all the same kind of thing. That's why I'm just calling them takeaways. Really, they're just a collection of thoughts in response to your situation. Number one, you need to get a strategy in place for your prioritization of features. You need a strategy to prioritize the features that you're going to be working on on a project. This is a huge discussion, by the way. There's no way we can cover all of the ins and outs of this. This is typically referred to as project management. Some people don't like that term, but it is what it is. There are entire books and job titles and podcasts and gurus who all, talk about this topic. There's tons of information, tons of methodologies, tons of opinions out there, but perhaps the most consistent opinion that everyone agrees with is that building features blindly without a plan is a recipe for disaster. If you walk into work on Monday morning and you decide on Monday morning on your own without consulting your other team members what it is that you're going to do on a project that the rest of your team is working on, you're going to be in a situation where you're going to be able to do a project that you are collectively responsible for, that is a recipe for disaster. You need to be certain every single moment that you are coding that the software design you are implementing is focused on the most valuable and most important aspect of the project for today. That's the ideal situation. Sometimes it gets a little bit messy. Once again, there's tons of information out there. Some of the information is going to tell you that chaos can be good, but it's not going to be good. You're going to have to be careful. You're going to have to periodically, for example, and the idea of promoting chaos for a short period of time, that's what a brainstorm really is, right? So there's a lot of different ways of going about practicing this, but the important thing is that you do it with intentionality. In other words, you make a plan and you follow that plan. If you do not have a way of determining feature priority, you will always be shooting in the dark. I recommend following a method that is relatively inspired by the idea of chaos. If you do not have a way of determining feature priority, I don't like to attach my endorsement to one single methodology 100% because there's value to be found in multiple methodologies. But I think that there's some good methods that apply pretty broadly in the agile world. The most important aspects are prioritizing most important features, determining the dependency of those features. So in other words, if we have one feature, that is extremely important, and it depends on a slightly less important feature on its own, well, that slightly less important feature now inherits the importance of its dependent features, right? So that's the concept there. And then limiting your work in progress. This eliminates much of the anxiety and the angst about what should be done now versus later, and it will help build the most valuable version of a product in the amount of time that you have to build it. So that's number one. And then number two, it's important to have a way of getting a strategy in place for the prioritization of features. Really, this is energy management, project management, whatever you want to call it. Number two, sit down and talk with your supervisor about code quality standards. Do this as soon as possible. Sit down and talk with your supervisor about the standards that your company has in place, or hopefully will have in place, that you should be following. Every company has a minimum standard of quality standards. So if you're a company that has a minimum standard of quality standards, even if they don't have a minimum standard of quality that they have determined, they have built a minimum standard of quality by actually building products, right? By building output. Make some time to discuss this kind of stuff with your supervisor. In this meeting, you want to keep the discussion pointed towards the future. Don't try to talk about previous projects. Instead, point this towards the future, because really all that matters is what you're going to change as you're building your product. So if you're a company that has a minimum standard move forward as well. So don't try to learn from the past when you're having this discussion for the first time. Explain that you want to be an advocate for the quality of the code, and you're willing to help determine a strategy to ensure that the code you write is meaningfully contributing to the overall goals of the product, and is doing so in a time-efficient manner. It's very important that you understand this. You can't just be an advocate for the quality of the code. This is what we were talking about before the sponsor break. You can't just say that you want high-quality code, because that is not doing the advocation step. You're not actually proving business value by just saying you want high-quality code. So sit down with your supervisor, discuss the code quality standards, and how that affects your business goals, right? This gives you the opportunity to help define the standards for the company if they haven't been defined, if they haven't been signed, and if they haven't been signed. So you can the standards for the company if they haven't been defined, if they haven't been explicitly stated, that otherwise they may go undetermined. When a standard is set for minimum quality of code, for example, if you set a minimum test coverage standard, then there's a little question as to whether the code is up to par or not. Make sure that you can look at a code base and with some level of tooling or some level of inspection, you can verify that that code base meets a minimum quality standard. Now here we're not talking about qualitative quality, right? We're not, we aren't talking about subjective quality. We're talking about having some level of measurement that you can absolutely determine does this code match up to the quality or not. So that's number two, sit down and talk with your supervisor about code quality standards. Number three, value. Value over time. Learn about value over time. Today, code quality is more costly than the shortcut. In other words, today, taking the extra time to build the higher quality code does not convert into business value today. And this is an important part of your discussion with your supervisor, as well as with clients, or product owners, that kind of person. You have to discuss value over time. Code quality is often discussed unilaterally by developers, simply based on how good the code is. Is the code good or bad? And a lot of the time, that quality of the code doesn't have a direct and visible impact on the business process side. But the quality of a given code base is most effective to the business if that code base has a long future. So if you're looking to build a roadmap in front of it, it's your job to see down that road. It's your job to determine that roadmap. It's your job to discuss the future of the company and help determine the trade-offs for your time and energy. In other words, you have to explain why good code today means good things in the long run, and how the math shakes out. If you can show that the investment will bring you closer to your goals more consistently over time, this is a good thing. This often is the metric that persuades most management to invest the extra time in code quality. Now, this is something that I've learned this year, perhaps more than any other year. It is important that you don't take the moments when the code is failing as an opportunity to say, I told you so. Instead, provide the fix and evaluate after you have fixed the problem. What this does is psychologically, it relieves the problem. It relieves the tension of the broken code base. And a lot of times, that broken code base would have been fixed a little bit faster had the code been tested properly, for example. If you can evaluate the code after the fact and provide an updated estimate, for example, of how long it would have taken to fix that problem, or if the problem would have been avoided altogether had the code base quality been better, had the code been designed in a way that would have been better, designed more holistically. The key here is when you're doing this, when you're doing this kind of evaluation, you want to do it after the problem has been solved, after the pressure is relieved. Do not take this as an opportunity to gloat or to show how smart you were five months ago when you said this should have been designed better. That's not going to win you any points on a personal level with your boss or with the client. So that brings us to our fourth takeaway. This is the shortest takeaway, probably. You mentioned, Cody, in your email that your boss or your supervisor threw away all the code you've been working on, that they went through and reversed it all. And I have a very simple fix for this. If you aren't using some kind of version control system, I highly recommend, it's almost industry standard at this point, to use some kind of version control system. Particularly, Git is the most popular, I believe, in the world at this point. So take some time, learn a little bit about Git. And then learn a little bit about branching. What you can do is develop the features on their own branches so that when that code is brought into the fold or when you show that code to your manager, instead of throwing it away, they can just not include that branch. In other words, if you created a pull request through GitHub, they can just not accept that pull request until they're ready for it to come in. This entirely, does away with the concept of undoing code. Instead of undoing it, you just never apply those changes to the original code base to begin with. If they are in their own branches, it's effectively like you have your own copy of code. So go and learn a little bit about that. I assume that you have been exposed to GitHub to some degree, but I highly recommend that you use branches for this exact purpose so that any code that you write, if you no longer want it, you can simply leave it in the branch. Close the branch out, do whatever you want to do, but the history is still retained. You can always go back and fetch those revisions from previous work that you've done. Version control systems, specifically GitHub, has saved our company hundreds of hours of rework, hundreds of hours of syncing time. The amount of value that we get out of this is completely astronomical. So if you're not using it, then it should be a drop everything else and go and do whatever you want to do. So if you're not using it, then it should be a drop everything else and go and do whatever you want to do. So if you're not using it, then it should be a drop everything else and go and do whatever you want to do. So if you're not using it, then it should be a drop everything else and go and do whatever you want to do. So if you're not using it, then it should be a drop everything else and go and do whatever you want to do.