Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we are talking about the antidote to I Told You So. Recently there was a discussion in the Developer Tearoom in the spec Slack community. By the way you can go and join the spec Slack community. You'll probably actually be able to catch the last part of this discussion. You can go to spec.fm slash slack. Of course that is free to you. But the discussion was around whether or not it's a good idea to ever bring up and I told you so. Now if you've never experienced this you will very likely experience it because developers have a tendency to see a little bit further down the road specifically when it comes to technical debt. Okay, so we'll play this out for a second. For example let's say that you are a highly principled developer and you know that high code quality prevents later technical debt, right? Or you know that high code quality is going to make it a little bit easier down the road when a new developer is hired to onboard that developer. And like so many of us have experienced at one point or another someone in the organization you are working with. Whether it's your boss or it's a colleague they disagree with you. They think that for whatever reason that you should be cutting corners in order to deliver the code faster, right? So this is a common scenario. We've talked about this same kind of scenario many times on Developer Teawhere the developer is relatively aware that cutting corners is going to cause problems and they are told to do so anyway. And there's a conflict there, right? And so a lot of times the developers will move forward with this kind of grudge holding this concept in the back of their mind that okay, if you really want me to do this I will but if it goes wrong then I told you so. And I want you to think very, very hard about those moments for a second. I want you to revisit one or two of those moments, really connect this story to something you've experienced because you're likely to see a lot of parallels with your own experiences and the experiences that we're talking about today. The moment where you feel like if someone had just listened to your advice earlier or if someone had just heard what you had to say earlier then you could have avoided all of these problems. Now there's a couple of things wrong with this and we're going to outline those in today's episode and also hopefully provide for you the hope of getting out of this scenario without compromising on quality, without going down that poor decision road that us developers and hopefully many managers, many people who are listening and learning about code, hopefully you're seeing the better decisions, the better code quality, ultimately being more maintainable or being more valuable usually in the long run. But we want to come out on the other end having not had to say something so brash as I told you so. So let's outline the problems with the perspective of I told you so. I knew this was going to happen and I told you and you ignored me. That's the message that you send when you sit down with your manager, when you sit down with a client or when you sit down with a coworker and you say something along the lines of I told you so I told you this was going to happen if you would have just listened to me and the problems are deep, right? There's a couple of really important primary problems that I want you to pay attention to. The first one is psychological. No one likes being told that they were wrong. No one likes having to confront the fact that they were wrong. And so when you create the situation where you are the upper hand in the discussion, whether that is actually true or not, no one really wants to hear it. Now, that doesn't mean that you get to wear the badge of the person who delivers the hard truth. When people don't want to hear what you have to say, the purpose of you delivering that message is lost. In other words, the whole idea behind you saying I told you so is hopefully to gain some level of trust, right? What you want to do is change what happens in the future. If your goal is to make someone feel bad or if your goal isn't focused towards making things better, if your goal is not towards the future, then maybe what we're talking about today isn't going to apply to you. And this podcast is really not focused on helping you feel better or stroking your pride. Quite honestly, none of that stuff is going to be valuable for you, right? What we want to look to is how to get better, how to become better developers, how to move into the future and prevent the same problems that we've seen in the past from happening again and again in the future. Certainly, we will re-experience similar things and we can learn every time we experience a problem, but we want to look towards the future. We don't want to dwell and try to make someone grovel and apologize or take the time out of their day to tell us, yes, you were right, I was wrong. That's not really valuable. What we want to do is moving into the future, do things better. So that first problem is psychological. You're already putting yourself in a position where your communication with your boss or with your colleague, it's going to be very difficult for you to gain any ground in that kind of situation, right? Because you've already put them on some defensive perspective. They're already going to be rejecting you a little bit because they don't want to have to deal with any kind of situation where they are wrong. And this isn't a bad thing. It's not a bad thing to not want to deal with this. It's instinctual because it's painful. And we want to avoid pain as humans. We don't really like the idea of having to confront other people and it's painful for us. We don't want to have to spend our time confronting other people about how right they were and how wrong we were. So again, psychological problems with this perspective, with the presentation that I told you so. But perhaps of equal importance is the simple fact that you actually cannot prove your position. In other words, even if you could go back and replay all of those scenarios, even if you could go back and force everyone to do things the way that you thought they should have been done, there's no way to guarantee that that would have fixed the problem. And then, basically, all you're doing when you say, I told you so, is you're outlining how poorly everything was done. You're outlining the failure. If you're trying to build up your own method as we should have done this instead, right? If you're looking back into the past and you're saying the antidote for what we failed at is this. Well, if you can't prove it, then it doesn't really sound much like an antidote. That it sounds like once again, you're pointing more at the failure than you are at a solution. And that's what we're going to talk about in just a moment. We're going to talk about how to fix the I told you so. And instead, focus our direction instead of focusing it on the past, instead of trying to cast blame and cast guilt. And as we discussed in Slack, instead of being passive aggressive about the situation, we want to shift our focus into the future. And we're going to talk about that in just a second. I want to talk about today's sponsor, Imagix. We've been talking about Imagix this week. Imagix isn't an incredible service. We use it at Whiteboard. On pretty much every project, Imagix is one of those things that when you launch your project, it's going to help you scale so quickly and take off a lot of the mundane tasks that you otherwise would have been performing on your images. And they're going to do it all for you. And it's all done through a simple URL driven API. You can do things like cropping, you can filter your images, you can even do face detection with Imagix. And they do this for over 2 billion images per day for hundreds of incredibly large clients. So they certainly can take care of your image load. It's also going to give you the added benefit that your server load is going to be significantly reduced. So you're going to see a lot more of your server CPU cycles going to the things that matter the most rather than trying to process images. So let Imagix handle all of those pains that you've had with image manipulation libraries. We all know how difficult it can be to get those things running right and to keep them running smoothly. Instead, give it to Imagix. Imagix is the easiest way to do this. And of course, it works with wherever your files are already hosted. So if you're on S3 or Google Cloud, whatever you're using pretty much Imagix can work with. And Imagix has built simple URL manipulation libraries for pretty much every popular language no matter what you're using, including Ruby, Python, JavaScript. And the languages that are used on native mobile applications like Swift and Java. So go and check it out. Spec.fm slash Imagix. That's spec.fm slash IMGIX. Thank you again to Imagix for sponsoring today's episode of Developer Tea and for creating such an incredible service and lifting the load off of me as a developer. Man, I love using Imagix. So I really do recommend it to pretty much everyone. All of our clients, they don't even realize that we're using it. It is that transparent to set up and run on whatever project you're using. It's not something that you have to spend a lot of time with. It's kind of a set it and forget it thing. So go and check it out. It's really cool. So we're talking about getting rid of this. I told you so moment. This confrontation where something goes south, right? And this happens all the time in business. It's not just for developers. It's in business. When something goes wrong, we want to diagnose the problem. We want to find out what the root cause was. Then we want to avoid it going into the future, right? So a perfect example of this as a test-driven developer. If you are advocating for test-driven development in your company and somebody bypasses those standards, or they bypass the rules on the development team. A lot of times when those people who are bypassing the rules, when they push something and it fails. If something fails, if the app crashes or something like that, a lot of times those test-driven development advocates will have that moment of, well, if you had written tests, if you had done what I told you, I told you so. I told you to write the tests that would capture that problem. You would have avoided this altogether in the first place. You wouldn't be experiencing the pain you're experiencing now if only you had listened to me. And we've already discussed some of the problems with this. Of course, as someone who is experiencing frustration or pain or failure, they don't really need the picture of what could have been. Let me focus on that for a second. If you're in a situation where you are experiencing failure, experiencing pain, you're experiencing sickness, that sense of if only I had done this, right? If you think about that mentally, it's kind of an agonizing thought. If only I had gone this direction instead of that direction. And often we aren't learning from that. We aren't being enlightened by that. We aren't being uplifted by it. We aren't feeling better when we think, oh, now I have the new solution the next time I encounter this problem. Now, a lot of the time when we are presented with that alternate route that we could have taken, it only makes us feel worse. Just at an emotional level, it's difficult to see that that is going to make our lives better in the future. And what we want to do is focus to the future. Now, how do we do that in these moments of frustration? I want to recommend that you do three key things. I want to make these quick and we're going to wrap this episode up as quickly as we can. But three key things to avoid the I told you so moment. The first key thing is have regular scheduled reviews for your projects. Sounds so simple, but so many people omit this because it seems unnecessary as you're going through the project. Maybe what we're talking about here is having short work sprints and then reviewing at the end of that work sprint, what went well and what could be improved. What this does is it allows you to constantly evaluate. This becomes a part of your practice and you can change. You can adapt much quicker. You may be saying, well, how can we connect this to the I told you so moment? How is this going to help us avoid and I told you so moment? When you have regular reviews, you're making much smaller corrections. In other words, instead of making big turns on the wheel, if you're using an analogy of a car, instead of only turning the wheel once every two hours while you're driving down the road, you're turning it once every 10 seconds. There's more regular review, more regular adjustments, making things better. It's going to allow you to see the progression of discussion. In other words, the progression of all of the people who are involved, their opinions and how they've shaped this progress. There's documentation that's involved. There's some kind of accountability when you have these regular reviews. It's up to you to decide the frequency of these. I would recommend something around once per week. That's a good cadence that people are used to. They're already in a project doing that kind of thing. A week is a normal rhythm for people anyway. We have work weeks for that reason. I recommend something around a week for the average project to have some kind of check-in, some kind of rhythmic check-in. This allows you to map those decisions and to map those pieces of advice as you move forward with a project. That evaluation effectively consists of what have we done recently? How are we doing with the things that we've done? How effective have our decisions been? What do we plan to do in the next week? How can we learn from what we did this past week as we move into next week? It's a very simple transition meeting from one week to the next and you're bettering at each of those meetings. The hope here is to completely avoid the, I told you so, situation by making better decisions and making much more smaller decisions rather than fewer, larger decisions. The second thing I want you to practice isn't just a rhythmic subjective evaluation, but I want you to put in place a way of measuring whether or not a decision was successful, right? A measure of success. This is business 101. If you read a business book, you know that setting goals, the most important thing when you set a goal is to determine what it means to be successful, what does success look like. When you actually make a decision on a project, it may be that you as the developer have a different version, a different perspective of what it means to be successful. An example of this. A lot of times as developers, we believe that what it means to be successful is to be bug-free and to not have to spend any time after launch fixing bugs, right? To be relatively stable and to minimize the amount of effort and energy that goes into something. If we have to go in and manually edit something, it feels like we've done a large injustice to our craft, right? It's very difficult to escape that sense that we've done something wrong when we are going against our normal patterns, the things that we know to be best for our craft. And so it's very possible that our version of success doesn't necessarily line up perfectly with the definition of success from the business perspective, right? It could be that the business perspective is okay with us editing and spinning extra time to manually change a config file on the server in the live environment. It could be that that is within the realm of what the business side is willing to spend to accomplish a particular goal. So it's important that as developers, we recognize that even though we have a measure of success, it may not necessarily always line up with the project's business level success. Now, this doesn't mean that you absolutely let go of your standards, right? It doesn't mean that you suddenly just conform 100% to only the business goals. It's important that you balance out the competing priorities, right? It's important that you as a developer, you present your priorities in your craft. How to do what you do the best way possible, right? Doing code that's maintainable because that will kind of fundamentally underlying reduce the cost for a company. And in general, when you can reduce costs, it's a positive thing. But if a business goal allows for a little bit of loss, for example, or allows for a margin of error, it's important that you recognize that in those evaluative measures, right? When you decide to look back on the past week or perhaps you do a monthly review, maybe you look at the last month and you try to determine, did we succeed with these various decisions? It's important that you recognize the different competing types of success, the different competing definitions and measures of success. Don't forget that your priorities as a developer, your priorities, your success measures as a developer are not always going to be the full picture. They're not always going to be all encompassing of your job, your strategic positioning, what your company has you doing, your ideals as a developer are not always going to be perfectly contributing to your strategic positioning as a developer. That's very difficult to grasp in the moment. It's very difficult to let go of your standards for the sake of a larger goal, but it's important that you learn how to balance those two things. Finally, the third thing I want you to practice when you have the urge to say, I told you so, the third thing I want you to practice is fixing the problem first. Fixing the pain point, the immediate pain point first. What this allows you to do, really what we're talking about here, let's imagine that you had a catastrophe and the server has failed. The server for your web application is totally down and you saw it coming. You could forecast that was going to happen based on memory usage. Maybe there's a memory leak and you said, we really need to fix this and somebody told you that instead of fixing it, they just wanted you to push a feature. They wanted you to work on a particular feature and push it instead of fixing the memory leak. You could see that eventually this is going to cause a server crash. We're sitting in the office at 7 pm. We're pulling a little bit of a later night than normal and it's a little bit frustrating. Emotionally, we want to lash out and say, if we had only done what I said, if we could have just rewind the clock, if we can just go back and just do what I originally told us to do, then we wouldn't all be here frustrated and trying to get the server back up. Here's the problem. If you are saying that in the moment of pain, it's not going to be productive for all of the reasons that we've already mentioned. But if you first solve the problem, if you are first there to help alleviate the pain, and we should have focused on that, this isn't validating the decisions that led to the problem. This isn't validating the issue, but rather it's addressing the symptoms of the problem. It's addressing the results of the problem. If you can address the results of the problem, then you maintain a sense of stability you can get back to a place where pain is not being actively experienced by the people that you're trying to communicate with. It's going to be much easier to communicate with somebody if they're not worried about a server crashing, and then also piling on top of the worry that they have about the server crashing. Now you're telling them that they could have avoided it had they listened to your sage advice. That's not going to be productive. If instead you can help solve their pain problem, you're going to gain authority with that person. You're going to gain appreciation and respect with that person. Ultimately, think about the reception more than about your own frustration. Think about the future more than you're thinking about the past. Think about preventing these problems in the future more than about assigning blame to those problems in the past. Thank you to the Specks Slack community for having great discussions day in and day out in the various rooms, including the Developer Tea room. Thank you so much for joining in and participating in the discussion there. If you are listening to this podcast and you haven't joined the Specks Slack community, you can do that for free, you can do that for free, you can do that for free. That will always be free to the Speck community. Again, a quick announcement in January. We were going to have somewhat of a focus on JavaScript. If you are interested in JavaScript and learning some of the ins and outs of JavaScript, if you have questions in general about the language or about frameworks around the language, send them into me. I will try to formulate those questions into something that's appropriate for Developer Tea. Of course, you all know that we cover soft skills things similar to what we talked about today that are applicable to a broad range of people. We do want to open up some more specific discussion about JavaScript in January. I think it's a growing community. It's exciting community. There's some really cool stuff happening. So we just want to do a little bit of something different for January. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Imagix for creating an awesome product, but also for sponsoring Developer Tea. Our awesome sponsors allow us to keep on doing what we do day in and day out. So thank you again to Imagix. Go and check them out. Specht.fm slash Imagix. That's IMGIX. Thank you so much for listening and until next time, enjoy your tea.