Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell 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 Teasince 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 some 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 J. Cutrell. 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 I am in there. Also I believe as J. Cutrell I'm J. Cutrell pretty much everywhere so go and check those things out of course links for those can be found in the show that's at spec.fm as well. Let's jump into Cody's question Cody sent me an email at Developer Tea. at gmail.com and he says hi as I previously said when we have chatted and slack I get a lot of value from Developer Tea. Furthermore I've recently 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 sandbox environment building and commonly and ensuring stability and quality. I program very methodically and purposefully it seems like 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 have put a lot of work into version two 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 have 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 a 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 right and 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 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 right we have some ingrained beliefs as developers and a lot of those ingrained beliefs are built from a 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 in 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 they're 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 a veracity a strong willed an 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 ad vocation ad vocation 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 possible to 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 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 supervisor a code can sign off and you spending some more energy on a particular feature so that you have a better test coverage where you 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're 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 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 with Linode it takes just a few seconds especially if you already have an account which hopefully quite a few of the Developer Tealisteners who have been listening to the show for a while you know Linode has been sponsoring for a long time and hopefully you've taken a chance on Linode because Linode provides fantastic service eight data centers their plans start at $10 a month so this is for even the hobby developer who just wants to launch a personal site you can get in to Linode at $10 a month and this gives you native SSD storage on a 40 gigabit internal network until E5 processors you get a seven day money back guarantee of course you get full control over your Linode server and the minimum amount of ram on one of these servers is two gigabytes so that's their new standard they're setting great quality standards at Linode go and check it out spec.fm slash Linode and on top of all of that you can use the code Developer Tea 20 to get $20 worth of credit at checkout once again that's spec.fm slash Linode and use the code Developer Tea 20 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 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 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 Agile I don't like to attach my 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's 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 get 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 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 move forward you can learn as you 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 that 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 and this gives you the opportunity to help define the standards for the company if they haven't been defined if they haven't been explicitly stated that otherwise they may go undetermined right 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 and 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 over time learn about value over time today code quality is more costly than the shortcut in other words today taking that 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 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 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 often is the metric that persuades most management to invest the extra time in code quality 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 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 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 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 coding in your email that your boss or your supervisor through a way 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 it's almost industry standard at this point to use some kind of version control system particularly get is the most popular I believe in the world at this point so take some time learn a little bit about get and then learn a little bit about branching what you can do is develop the features on their own branches so that when when that code is brought into the fold or when you show that code to your to your manager instead of throwing it away they can just not include that branch in other words if you created like a pull request through get hub 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 get hub 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 from previous work that you've done version control systems specifically get hub 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 start using it immediately highly recommend that you check out some kind of version control system again pretty much everyone is using get and one of the many various services that are available we use get hub there are things like bit bucket especially if your company uses alasia thank you so much for your question Cody and thank you so much for listening to this show Cody thank you also for being in the spec slack community if you are interested in being with us in the spec slack community you can talk to Cody about this episode you can talk to me in the spec slack community you can send me a direct message or we can talk in the Developer Tearoom all of the spec all of the spec hosts are in the spec slack community so go check it out spec.fm slash slack thank you again to today's sponsor linode remember you can get $20 for free and a seven day money back guarantee two gigabytes of RAM minimum and SSD storage on a 40 gigabit network $10 a month eight data centers it's a great deal go and check it out spec.fm slash linode thank you so much for listening thank you again for celebrating the announcement of my future child i'm really excited about it so as my wife and we can't wait to be parents and thank you thank you so much for celebrating that with us until next time enjoy your tea