Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be answering a question from listener Jake Schwartz. Jake actually asks this question in the Slack community, the spec Slack community, which you can join by going to spec.fm slash Slack. Jake is in the developer T-Rome and he actually just asked me directly. He said I would like for you to cover this question on the show and it's a great question. I can't wait to get into it but first I want to thank today's sponsor Imagix. Imagix is such a great product and we'll talk about it more later on but go and check it out if you haven't Imagix.com but for now let's jump right into this question from Jake. Jake says I have a question that could be good for the podcast. I started a new job a couple of weeks ago and I'm starting to get a feel for the co-bases that I'll be using for the time being. I have some suggestions on how to improve one of them. I'm going to be the second person to start using the code base regularly. Any strategies for making suggestions without making it seem like I am trying to take over the code base or that I am on some sort of high horse with my ideals? Thanks and let me know if you would like some more clarification. Well Jake that is just about as clear as I would need to be able to answer this question so let's jump right in. This is a hard problem to solve because basically what we're talking about here is you coming in as the new programmer, the new hire in town and that can put people on the defense. People may feel a little bit uneasy about having new people in the office and it's a little bit difficult sometimes to acclimate to the new faces. So I'm going to jump right into my suggestions for you Jake. Number one, I think you need to start by thinking about what it's like to be in the person who wrote that code bases shoes. They probably feel ownership over that code. The person who wrote it often should feel ownership over it because it's something that they created and something they use every single day. Now the reality is for most agency style teams and whiteboarders this way, we don't have all the time in the world to make our internal code bases everything we want them to be because usually these internal code bases, these internal tools that we create, they aren't directly billable. In the agency model because we get all of our kind of our billables go directly to clients when we work on our own stuff, that's kind of a cost rather than a profit. When you work on a tool that isn't directly billable then you're kind of incurring some cost. So you have to cut corners sometimes in order to make that work. Now in the ideal scenario you would set aside this as an investment of some sort and eventually you would see that returned when you're using that tool over and over and it's making you more productive on future projects for example and you can get more done in less time and therefore make more dollars per hour if you want to look at it that way. Usually these tools unfortunately don't get all of the attention that we would like to give them. So keep that in mind when you're approaching this problem because it may be that the person that you're talking to is absolutely ready to have somebody come in and help them better this code base. This is true again for whiteboard. I love it when developers come to me and say hey I would really like to add to our internal tools. I'd like to commit to those repositories and I give them full access. I say go ahead I love for you to contribute to these repositories. Now with that said because you are new and because anybody who is new that comes to whiteboard for example I would rather them spend some time working with the tool as it currently is. Here for that is because you may not have a full idea of what we use that tool for and I don't want you for example to waste your time in one corner of that tool that we use maybe one day out of the year if your time is better spent in a different part of the tool. That's just one example. You need to be familiar with the tools you need to be familiar with the business practices of the team you're currently working on. So it takes some time to understand some of those things. Keep that in mind as you approach this problem. Whoever the person is that wrote this code likely has some things they would like to fix but they also likely don't have a lot of bandwidth to fix it. What you want to do is frame your questions as opportunities rather than criticism. You want to ask questions like if you could change one thing in the code base what would it be? Is there anything new that you would like to add to our tool set? Ask questions that allow the original author to explain how they got to where they are and where they would like to go. Let me say that one more time. You want to ask questions provide an opportunity for you to be the way that the original author can take this code base that they are responsible for from where it is currently to where they want it to go. I'm going to take a quick sponsor break while you think about this idea for a minute or two. I'm going to take a quick sponsor break and then we'll come back and talk more about this concept. But I'm really excited to talk to you about our sponsor today because it's Imagix. I literally use Imagix on every single project that I work on at Whiteboard. And why would I pick up a tool like Imagix and use it on every project? Well because every project I work on at Whiteboard needs images. And pretty much every project any web developer works on needs images. And we need them to be delivered fast and we need to be able to resize them on the fly. Now in the past, I've had to create my own image magic setup to do this kind of thing. And it's a huge hassle if you've ever worked with image magic as powerful as that software is. It's a big hassle. But if you use Imagix, it absolutely fixes this problem. Not only can you resize on the fly, but it's backed by a CDM with global presence, response times, they average around 70 milliseconds. By the way, for those of you who are accounting, that's 0.0 seconds response time. Absolutely incredible. Now Imagix doesn't just resize these photos. It also compresses them. It can apply filters and all of this happens simply through URL perams. If you don't want to manipulate the URL perams directly, there's libraries for Ruby, Python, PHP, pretty much any popular language you would normally use, including languages that work on a native application like Swift. So it will work for your platform. Now Imagix just recently published their first case study with Eventbrite. You can go and read this case study, it talks about how they process images for two million events per week in more than 180 different countries. That's two million events for Eventbrite that Imagix is processing. So go and check it out Imagix. That's IMGIX.com. Of course, there is a link in the show notes. And of course, we'll also include a link to that case study with Eventbrite. Thank you so much to Imagix.com. For entire solution for pretty much every photo you would ever need to serve on the web. It's incredible. Okay. So let's jump back into this topic. This legacy code base, how to make it better, how to suggest something without looking pompous or without looking like you're trying to take over the code base. Now I feel compelled to say that this is not a one shot solution and feelings are always volatile. It's very easy to hurt people's feelings sometimes and sometimes people are, they view things in a completely professional manner. And if you were to bring them the flaws that you see in the current code base, they may treat that completely logically and have no feelings attached. But it's unlikely that most people will treat things without any emotion at all. So Jake, I really appreciate this question for that reason. It shows that you are thinking about these things. It shows that you have at least a sensitivity to the fact that whoever wrote this code base may be sensitive to it. They may have some sense of ownership over it. So let's jump right back into this conversation. One thing that should be covered here is that your ideas may not actually be the best way forward for the team. You may think that they are, but the reality is that you and anyone else on your team is likely to be wrong at some point. So keep that in mind. And the reason you want to keep that in mind is not so that you're constantly feeling like, oh, maybe I'm wrong, but rather so that you will feel less tied to your own beliefs and instead committed to the success of the team and the code base itself. This allows you to step back from your beliefs, step back from your assumptions and view them as purely, as purely experimental, right? If you have a belief about a particular feature that it needs to be your particular way and you start getting invested emotionally into that, then it could be that your investment emotionally is actually going to cause a problem with your ability to change that feature in the future because you're connected to it. And it may be completely logical to change that feature. You could be wrong. Keep that in mind all the time. Just allow yourself the ability to be wrong, the ability to fail and that way you don't get connected to your solutions so much so that you are unwilling to consider someone else coming to you. For example, let's say in the future, imagine a few years down the road, another version of a person just like you coming along comes along and says, hey, you know, I think this code base could be improved again. So keep in mind your ideas may not be the best way forward. It is very possible and perhaps even necessary for you to work on the internal tools in time that isn't directly billable. This has to do with what we were talking about before. Sometimes it's difficult to invest in these tools because they may not necessarily be profit centers right away. So nights and weekends are often when internal tools are built and if you want to change them Jake, it's possible that you need to offer up that extra bit of sacrifice. Unless there is a specific contract that works the overhead of building those internal tools or improving on those internal tools into a client agreement for some strategic reason. Now try forking the code base and experimenting in your off time. You don't really need permission usually to do that kind of thing. Very few employers will disapprove of this. Very few people, even the people who are really protective over their code base are going to disapprove of this. And the reality is if you were to fork the code base and then take it to the original author of that code base and ask them for their honest opinion and say, hey, I've done something with your code that you wrote. It's something that I was experimenting with. What do you think? Now if you frame this not in terms of a criticism or in terms of trying to point the finger, but instead as an opportunity for them to teach you or an opportunity for their code to be bettered, that is a much more likely scenario for them saying, yes, let's go with your idea. Let's try to bring this into our production code. So I could talk about this all day long because this is the kind of stuff that makes our jobs unique. We have these things that we build that are logical tools, but we still have a sense of artistic integrity, artistic ownership over these things, over the code that we write. So I want you to leave with these kind of two lingering ideas. Number one, you do not have to convince the original author of the code that what they have created was a mistake for them to be willing to change it. This is a very common misconception for advancing any kind of software. You should apply this idea to open source software as well. A change to software does not necessarily mean that you are fixing it or that there was something even necessarily wrong with that software, but rather that you are improving upon the software. No one wants to be wrong, but any reasonable person wants to be better. I want to say that again because if you take nothing else away from this episode, please take this idea that no one wants to be wrong, but every reasonable person wants to become better. If you frame your desire to change this code base as an opportunity for someone to become better or for somebody's creation to become better, rather than an opportunity to point out the issues or the things that were wrong in their original creation, they will be much more accepting to this change. And the second idea that I want you to take away here is that the socratic method is still powerful. It's age old, but it still works. Asking questions usually makes more headway when you are trying to change someone's mind, because they discover the need for improvement in the code base without you having to point any fingers. And both of these ideas are kind of married to each other. You don't have to point any fingers. You aren't trying to say that this person is wrong. All you're trying to do is make things better than they currently are. If things work, then technically they're right, but they can be better and right at the same time. And that's the spirit of what you're trying to do. And really, this just comes down to you having empathy for this other person, for their position in this discussion. And I think quite simply by asking this question, Jake, you are in the right place. You understand that if you come across as abrasive, or if you come across as accusing that this person is not going to likely accept your ideas as exciting, or as good ideas necessarily. But if you come across as, hey, all I'm trying to do is help. And I want to help you achieve whatever it is that you want to achieve with this code base. Here are some ideas. That is what this boils down to. Come across with the intention of helping, rather than with the intention of attacking. Thank you so much, Jake, for sending this question to me on Slack. If you are listening to this episode and you are not a part of our Slack community, I highly recommend that you join us. It is free for you forever. You can join right now by going to spec.fm slash slack. Of course, that will be in the show notes. Other relevant links will be in the show notes at spec.fm. Thank you so much again to today's sponsor, Imgx. That's IMG IX. Every single image that you ever serve ever again in the future should be coming through Imgx. It is super fast, super flexible. There's APIs for every language. There's no reason you shouldn't be using it. Oh, and by the way, it is incredibly affordable, just as affordable. If not better than your AWS server and all the time you spend trying to get Imgx. Go and check it out, Imgx.com. Of course, clicking on the Imgx link in the show notes is a huge help to Developer Tea. Speaking of helping Developer Tea, if you have not left a review for the show and you enjoy the show and it provides value to you, please consider providing value back to us, the people at spec. By going to iTunes and leaving a review for the show, there will be a link in the show notes for you to go directly to iTunes. It takes just a few minutes and leave a review for the show. This is the best way to help other developers find Developer Tea. Thank you so much for listening and until next time, enjoy your tea.