Hey, everyone and welcome to Developer Tea. My name is Jonathan Cutrellan in today's episode. I'm going to be talking to you about client communication. Today's episode is sponsored by Linode if you're looking for a Linux-specific SSD host. Then Linode may be the perfect option for you, especially with some of the features they have, but also a special deal they have just for developer T-listeners. We'll talk more about what Linode has to offer you as a listener of this show later on in the episode. But first I want to go ahead and talk to you a little bit about client communications. Every good relationship has communication at its core. Communication really survives its best when you put effort into making it intentional. And I hope that you've come to this episode willing to be intentional with your communication with your client. Now, you may work for a firm where you don't necessarily interact with the client all that often, but these principles that I'm going to lay out for you in today's episode, they're going to work well with you and your manager as well. Because what we're going to be talking about today is proactive versus reactive communication. Proactive versus reactive communication. So what is proactive and what is reactive communication? And I'm going to go ahead and tell you we want to err on the side of proactive. So we'll start by explaining what reactive is. Imagine that you get into a situation where you've pushed some code and you've done all of your due diligence, hopefully, and you've tested the code, but somehow something unexpected occurs. And this is going to happen. I want you to go ahead and prepare for this. It will happen in your career at some point. Something unexpected is going to occur. Perhaps it's going to happen every single day and quite honestly that is more likely than not. So something unexpected occurs. Now what is your proper course of action as the developer of that project? Well, you could go in and try to fix it before anybody sees it, right? That's what our gut tells us to do is to go and try to fix it, go and try to patch it up before anyone sees it. Now the issue with this is that sometimes it takes longer for us to patch things up than we actually recognize. Sometimes it takes longer for us to patch things up because we rush through that initial response. We end up making mistakes when we're rushing. And ultimately we break the code even further, we put in bad solutions to the original problem. And beyond that, we're trying to hide our failures. We're trying to hide our failures. If you feel pressured to try to hide your failures, then you're trying to be a perfect human. Okay. And let's take a step back here and talk a little bit philosophically. That's impossible. You're never going to get to the place where your code is 100% bug free without a doubt if you continue to change that code. And these unexpected things are going to occur. Now when you try to hide, when those things do occur, whether it's to your client or to your boss or even to yourself, if you try to ignore that your code has a bug in it, ultimately you're lying. You're lying to yourself. You're lying to your client, you're lying to your boss. And you're trying to portray this idea that you have the ability to write code that is perfect. And this is only going to get you in trouble. This is only going to get you in trouble because if you try to portray that idea and then eventually they find out that that's not true, they're not going to trust you. You're not building trust. And the code is already broken. And it's becoming more broken because you're rushing. And this is just a sick cycle. This is a very bad situation to be in. Reactive communication when you make a mistake is the wrong choice. Let me say that again. Reactive communication when you make a mistake as a developer is the wrong choice. What is proactive communication? What does proactive communication look like? Well, I'll tell you more about proactive communication right after this quick sponsor break. Today we're talking about Linode. Thank you to Linode for sponsoring today's episode with Linode. You can instantly deploy and manage an SSD server in the Linode cloud. You get a server running in just a few seconds with your choice of Linux distribution, resources, and node location. They have eight data centers and their plans start at just $10 a month. I don't know about you, but for something as important as a server, I'm willing to pay $10 a month. With $10, you can get a server running in under a minute. You get hourly billing with a monthly cab on all of your plans and your add on services, including backups, node balancers, and long view. You can set up a virtual machine for full control on one of these Linode servers in the cloud. You can run Docker containers, you can run encrypted disks, VPNs, etc. You can even run a private Git server. There's so many things you can do with a Linode SSD server. Now I mentioned SSD. It's a native SSD storage on a 40 gigabit network with Intel E5 processors. So for those of you who are worried about speed on your server, Linode has you covered there as well. There's no risk here because they have a seven day money back guarantee. You can try Linode for seven days. If you don't like it, you can get all of your money back. Now on top of that, if you use the code Developer Tea 20 at checkout, Linode is offering you a $20 credit. That's $20 just for free. For every single person listening to this show, Linode is offering you $20 worth of credit just by using the code Developer Tea 20. Of course, you can find that code in the show notes at spec.fm and there will be a link to directly send you over to Linode as well. Thank you so much to Linode for sponsoring today's episode. So we're talking about proactive versus reactive communication here, particularly when you make a mistake or when something unexpected happens. And I actually had this experience recently. I had set a crime job to go off at 6 p.m. Eastern Standard Time. When the time changed, that crime job started going off at 7 p.m. Eastern Standard Time. The client asked for that to go back an hour back to 6. I accidentally set that crime job to go forward an hour, which is 8 p.m. And that simple move happened to bump that crime job into the next day. In my code, I was checking to see what day of the week it was and that crime job ended up running a day early. This is kind of a weird situation that I just didn't think about when I was setting that crime job up. And ultimately, it was one that wasn't that big of a deal, but it was so important that I explained why that crime job ran a day early to the client. And this is exactly how I did it. I'm going to teach you how to do this proactive communication so that when something like this occurs in your projects, you know how to handle it. Instead of getting panicky and rushing through, trying to fix the problem as fast as possible, you'll be able to take a step back and handle the issue deliberately and correctly without getting out of control. So that's the whole point of this. To build trust with your client and also give you the proper space to respond to issues as they occur. So this is how you're proactive. It's much better to be proactive when something goes wrong than reactive. In other words, don't wait for your clients to come to you and ask you why something went wrong. Be upfront with your clients and tell them what went wrong. Tell them what went wrong and exactly why it went wrong. And what you're doing to ensure as much as possible that it doesn't happen again. Be certain that when you're talking with your client, you don't dive in head first with all of the technical details. This is the way that our minds are naturally wired to think. We go straight to the very specific zoomed in line of code level detail. That's the way that we solve problems as developers. But this is not how you want to communicate to your clients. You need to start by assuring them that the situation is under control. Start by assuring them that the situation is under control. Simply by you telling them that you found an error rather than them finding the error, you are already building confidence for that client. That's a little bit non-intuitive that by you admitting your faults, you're actually building confidence. But the truth is if your client never saw the error, then they're only going to see this as another reason why you're the best. You found errors that they couldn't find. You found errors that they couldn't find. Start by assuring your client that the situation is under control. Next, give them the layman's terms version of what happened technically and how you fixed the issue. Layman's terms for the time zone issue, for example, would be something along the lines of there was an issue with the time zones of the two different computers, the server, am I local computer or the server and the local area time. And the issue happened when we reset the time for that particular action to occur. That's a layman's terms version. It's not the absolute bare minimum, but it's not the technically dense explanation of what UTC time is, for example. We don't want to do that. We want to give that layman's term version so that they have an idea and a general idea of what happened. Next, you're going to make the disclaimer that the next part of your email or the next part of what you're going to say on the phone or however it is that you're communicating, the next couple of things you're going to say are going to dive into the gritty details of what happened. As well as the technical solution you've chosen to go with. This serves many purposes. First of all, it once again underlines that you understand the technical side of what happened, that you weren't shooting blindly, that you knew exactly what occurred to cause this thing to go off the rails. Number two, by describing the technical details, you've shown your client that you are competent and capable of doing something that they are hiring you to do because quite simply they don't know how to do it. If you show them that you are doing something for them that they do not have the capability of doing for themselves, that in and of itself is valuable. You want to show them those technical details and you want to explain the technical solution. The third reason you want to do that is because it provides some documentation. It provides some shared documentation between you and your client. Hopefully you've seen someone else on your team. It provides that documentation so that you can go back and reference it if something happens in the future with time zones. If something happens in the future with the same area of the application, then you have a little bit of documentation both for the client and for you. Like that client takes that particular product. Let's say they decide to leave you one day and they take it to another developer. You are helping that client in the long run. Even after they've left your services, your documentation in that email could be passed on to the next developer that helps them out. We believe in doing good via clients even if they choose to go and work with someone else. The value I provide by writing a simple email with the technical details in it. The value I provide both now and the future is incredibly enhanced by this method of proactive communication. You have to do this. You have to do proactive communication. Finally, once you've done all of this breaking down of what occurred and what you are doing to make sure it doesn't occur again in the future, you're going to end the email by looking forward into the future with a tone of strong confidence. Let me say that again. Finally in the end of the email, you're going to look forward into the future with a tone of strong confidence. Let me tell you what a tone of strong confidence doesn't sound like. You shouldn't be ending your email with, let's hope this fixes it. Let's hope this fixes it is not a tone of strong confidence. Your client is going to be just as concerned as you are at that point. You're transferring some of that uneasiness, some of that anxiety over your own code over to your client's shoulders and that's not what they hired you for. Okay. Instead, treat the problem that you just resolved as resolved. Maybe mention some of the other features that you're developing for that particular platform or mention broadly that you're excited about working on that platform moving forward. Don't go back and reinstate the feeling of doubt that your client walked into this with. Okay. Don't go back and give them a reason to be concerned. Give them a reason to be confident with you and excited about the future. This is basic client communications. You're going to give them the solution and you're going to give them a way of looking forward to new and better things. Okay. So be proactive in your communication rather than reactive. This is going to go a very long way with your clients. Don't lie to yourself. Don't lie to your boss and don't lie to your clients about your own abilities. Bugs happen. Unexpected things happen. You're going to experience issues with your code and responding to them properly is essential. It's particularly essential for your business relationships. Thank you so much for listening to Developer Tea today. Thank you to Linode for sponsoring today's episode of Developer Tea. If you are looking for a cloud SSD hosting option specifically, if you work on a Linux based platform, then Linode is a great option for you. On top of that, they're offering you $20 and a seven day money back guarantee. Go and check it out Linode.com and the code for that $20 credit is Developer Tea 20. Of course, that will be in the show notes. And every other relevant thing that I mentioned for today's episode will be in the show notes as well at spec.fm. Once again, Developer Tea is now on Google Play. If you want to find it on Google Play, you can of course Google it or you can look in the show notes for the link. And of course, there will also be a link to leave a review for Developer Teain iTunes. Of course, this helps the show tremendously. You're not only helping other developers just like you find the show, but you're also helping the show climb in the rating. So if you believe Developer Teadeserves to be climbing in the ratings on iTunes, then go and leave a review on iTunes. Thank you so much for listening to Developer Tea today. And until next time, enjoy your tea.