There are things that we all are probably going to try to start doing with January rolls around. We've talked about this on the show before. Making your New Year's resolutions or viewing it as a fresh start, and it makes sense because there's a lot of other people who are making changes in their life or in their lives rather. But if you see that happening around you, then perhaps you're more likely or more willing to make changes in your own life, particularly changes that are visible. If it's uncomfortable for you, for example, to go to the gym more often because maybe you don't feel comfortable at the gym, there's going to be more people at the gym in January than there are in most other months. Of course, it falls off as the year moves on, but at least in January, there are other people who are attempting to do the same thing. In today's episode, we're going to be talking about something a little bit different than that. We're going to be talking about three things that you need to stop doing rather than start doing. These are your three kind of anti-resolutions, as well. We're going to call them three anti-resolutions for your New Year. As you prepare, hopefully, if you're like me, you're preparing your mind for the New Year, you're journaling a little bit, maybe you're reflecting a little bit on this past year, and you don't have to wait until January starts to do this. But certainly don't feel guilty if you decide to wait until January. It's a natural time to do that and other people doing it, like I said before, it adds to that kind of social sense of motivation. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on the show is to help developers like you find your career purpose. What does that mean? Well, it means that I help you understand what it is that you care about, what it is that you want out of your career. Ultimately, most of your time, most of your waking hours, at least, are going towards some kind of work. For most of your life, a large portion of your time is going towards your work. If you're like most people, even the time outside of work has spent thinking or talking or studying about these subjects. Doesn't it make sense then that we should make it worth our time, make it worth our effort? Doesn't it make sense that the time that we have to do this work that we're doing as developers, that we don't just do it for the money to fund the minority of our time? Let me say that again and clarify. Doesn't it make sense that we actually care about our jobs more than just for the sake of money to fund the small sliver of time that we're not actually thinking about or doing work? That's a challenge for you today, for you to think about your purpose in terms of that share of your life that it actually carries, the significant portion of time that you spend investing into this stuff. So we're doing this three by three episode. This is the last three by three episode of the week. I'm really excited about these three by three is I think that people are going to absolutely benefit from having these key takeaways. One thing that we do during the three by three, when we have a sponsor for these, we like to do it at the beginning so we can go straight through the three takeaways. Today's sponsor is Linode. With every sponsor, we send kind of a request to ask the sponsor what they'd like for us to talk about. Of course, you've heard a lot about Linode and they send us this request quite a while back. They've been supporting the show for a long time. What I've decided to do recently is go and look a little bit deeper into the service offerings that they have. It's going to bring to the service even more of the value that Linode is providing to developers. The thing that I want to highlight today is the fact that Linode has really quite good design. Their products are kind of a joy to use because they aren't ugly. A lot of the time, when we encounter these cold server environments, we can get used to dealing with kind of a clergy out of date design. But Linode has made an effort to make their user experience and more explicitly kind of their aesthetic presence online to make it attractive. It's easy on the eyes. This can be undervalued, especially by developers. If you take some time and use Linode services, you will realize how valuable that actually is and not only is aesthetically pleasing design a positive thing for your experience, but it also makes it a better product to use because it's clearer to understand what's going on. Of course, design is not just about aesthetics. It's about organizing things in a way that is proper, in a way that your brain works well with them. If your service provider that you currently are using does not have that, then that's a good reason to check out Linode. There's plenty of reasons to check out. Of course, we've highlighted more recently some of their customer service things that they do, some of their involvement in the community, their IRC channel. Linode has so many offerings that they provide to developers. It's worth it just to check them out because it's so, so affordable. You can get a Linode server up and running for $5 a month. It'll give you a gigabyte of RAM. Pretty much every personal website that I know of can run on these $5 a month servers. Go and check out what they have to offer. They're going to give you $20 worth of credit just for being a Developer Tealistener. Use the code Developer Tea 2017 at checkout. Remember, that's probably going to expire when 2018 rolls over. I'm sure that they will give us a new code. If you're listening to this in 2018, you may want to listen to another episode in 2018 that Linode is supporting as well. Thank you so much to Linode for sponsoring today's episode. For continuing to support Developer Tearight into 2018. Let's get straight into these anti-resolutions. Anti-resolutions, you can adopt these today or you can wait until 2018. Certainly, these are not super difficult to adopt necessarily. They don't require a lot of physical or mental effort. But rather, they do require awareness. They require you to think about the things that you're saying and doing on a daily basis. The first one that I want to outline here is to stop trying to talk like a developer. Stop trying to talk like a developer. What does this mean? Well, as developers, we like to throw around these kind of loaded terms. Reactive would be a good example, responsive or adaptive. These are words that, especially in the web development world, have come to mean a lot of different things. Not only do they mean a lot of different things, but there are some people who get very passionate about defending the meaning of these words or redefining these words to mean something new. The problem with this is that really, it takes the focus off of communication and puts it onto semantics. So especially if you are talking with your coworkers, we do have one caveat that I'm going to list here in just a second. But especially when you're talking with your coworkers, and in particular, if you are a leader and you have younger developers who are kind of looking to you for guidance, if you're a mentor or if you could be considered a mentor by someone, if someone is listening to you and they're looking to you to kind of explain to them what's going on in the industry, then I recommend that you try to avoid words that are loaded. You try to avoid these buds words, avoid talking about things in kind of ethereal, bigger level, higher level concepts. As much as you can simplify these terms, you're much more likely to be able to communicate well with other developers. And you're much more likely to actually achieve the thing that you're trying to achieve with them. Here's the caveat. And it's an unfortunate caveat, but it's one that exists and we have to figure out how to navigate around it. The caveat is these terms tend to be what people look for when they're searching for someone like you. You're searching for a developer. In particular, if you're working in an agency, you're likely going to have people searching a responsive web design to find a firm or find an agency that will do web design for them. And every industry has these key terms. These are terms that kind of signal various belief systems about how the work should be executed. They kind of point towards your values as a company. If you value adaptive responsive web design, then the people who are looking for you, the people who are searching these terms, they know that you're on the leading edge of the industry. That's kind of the heuristic that they're using. They're trying to use these words as a way to find someone who is credible. Whether that is good or bad, we aren't really going to debate on this episode, but it certainly is still the case. Don't go and try to rip all that stuff out of your website. Certainly, don't look down on your marketing manager or on the person who is responsible for your content management. Don't look down on them for trying to utilize these words in meaningful ways. They are not meaningless words. They are not just full of fluff. What this anti-resolution is about is trying to use those words in your everyday conversation when you're building a product. When you're actually working, when you're trying to communicate about, for example, a problem that you're having. Try your best to frame that problem in the most simple language possible. Go to the lowest common denominator that you can. Hopefully, this will help you translate between you and a coworker, you and a client, you and a manager, your boss. That translation process is extremely important and the simpler language you use, the better. The second anti-resolution, and this is the hardest one of the three, probably. But the second anti-resolution is quit being busy. Quit being busy. There's quite a few podcast episodes on the subjects that are coming out right now. The idea here is that busy is very often a result of your own decisions. I challenge you to write out your entire schedule for a given day. I want you to look at this schedule and I want you to identify the most important, we use the Pareto principle here, it's very commonly used in these kinds of discussions. The most important 20% of events or activities that you participate in for that day. For example, you might actually identify that cooking breakfast is extremely important to you. You want to protect the time to cook your breakfast. You may also identify that later on in the day, you spent some time watching TV or maybe something more productive. You spent some time cleaning your house. You may identify that that wasn't really that important to you. You doing the cleaning work yourself is not really important to you. If you could offload that, if you could hire someone to do it for you, then you would. I'm not by any means saying that you need to outsource all of the manual labor in your life. Very often, these manual labor tasks that we have to do as developers, they can be healthy for us because most of the work that we're doing is not manual labor. We're not really moving around very much in our day job. It's a good break. It's a good physical break, a good mental break to clean your house or to mo your lawn. Take a look at that schedule and identify that top 20% most important stuff that you do in your day. You're likely to find that there's a large portion of things that you do. There's a large number of things that you do that if you were to cut them out entirely, not just reduce them, but totally cut them out of your habits. Totally cut them out of your schedule. If you could cut those things out, then you would be much less taxed for time. Another good example might be maybe you drive to work and you could take a public transportation. This may be a way that you can read a little bit more, for example. If you wanted to start reading more books, but you can't find the time, well, perhaps it's time to start taking the bus. This does also come with a caveat, similar to the first anti-resolution. I have a caveat for the second one as well. That is to be careful about eliminating your recreation. Be careful about eliminating your rest and your recreation. What a lot of people end up doing is they cut in areas that are good for their mental health because they see this as a productivity exercise rather than a prioritization exercise. What does that mean? Well, a lot of people are trying to squeeze every minute out of every day for the most productive things that they think they can do. That means replacing all of their leisure time with work. And very often, this is the wrong decision because your balance as a human in order to avoid things like burnout, you have to balance and you have to have that leisure time. Now it may be imbalanced currently. You may be spending a large majority of your free time doing something leisurely. And there may be plenty of room for you to cut back a little bit on that. But again, remember, this is a prioritization exercise, not a productivity exercise. This is a prioritization exercise. All right, anti-resolution number three, stop taking your projects down to the wire. Stop taking your projects down the wire. If I could tell every team of developers around the country, around the world, all the way into the future, if I could give them one piece of advice, this would probably be yet. You need to be targeting to release the first version of any project at the latest at the 50% mark. This means that whatever scoping, whatever planning that you're doing, whatever your sprint planning is, whatever your release schedule is, however you're doing your management, however you're doing agile or extreme programming, all of these things that culminate to the delivery of a project, you should be allocating 50% of the time that you're planning to use. You should look at that 50% as your primary container, as your very first release. Now, if you're working on an iterative release cycle, then that can be earlier, right? It can be much earlier than 50%. But certainly no later, you shouldn't be planning your projects as if 100% utilization or even 80% utilization is an accurate estimate. Now, here's what's going to happen. If you actually take this to heart, if you go and start trying to launch your projects at 50%, number one, what you're most likely to find is that you're going to be on time more often. You're actually going to hit that 100% mark because most of the time you're going to underestimate. That's not a knock against whoever's listening to this podcast. This is just a normal pattern that humans follow. It's very difficult to subvert. We aren't going to go into the details on that, but this is very common, very difficult to subvert, and you're likely to overestimate. But let's say that you somehow strike gold and you estimate it properly. Well, now your project is shipped early. This is never a problem. Your project is shipped early. Now, does it have every single feature that you want in that project? Does it have everything that the client asks for? Does it have every interface, you know, a polish that they wanted or that you wanted or that the product called for? No, it doesn't. It is intentionally forcing you to pair this thing down to make it a smaller project. If everything was smaller, it would become easier to do. And so what you want to do is compose that smaller project with more smaller projects. Take the next half of your project and iterate over that first part. Now, what you get in addition is you get the learning that you have by already having this thing in some form as a usable product. This really is the basis of Agile and MVP delivery and iterative development, but it can be applied across the board. If you start with the idea of cutting your project in half, taking out all of the least necessary pieces, I won't say they're unnecessary, but take out all of the least necessary pieces, cut that scope directly in the middle, and then try to launch that 50% mark. Again, you're very likely to find that the project is going to run over that 50% mark. And I encourage you, managers who are out there who are skeptical of your team. You think that your team is going to fill up any schedule that they're provided, whether it's five days or 50 days, they would take up 100% of the time allocated. If you believe that's the case, then run this experiment with the mindset that you can keep the original plan, but you want to track progress. See how far along you got by the 50% mark. What you're likely to find once again is that if you were to scope things down to that 50% mark, then you will be much more likely to deliver an excellent product on time. Thank you so much for listening to today's episode of Developer Tea. I hope you will consider these anti-resolutions for yourself, and thank you again to Linode for sponsoring today's episode and helping us carry this podcast into the ears of thousands of developers. I truly believe that if you engage ideas like what we present on this podcast, that you will do better work. That each day that you go into your job or each day that you sit down at your desk, if your freelancer at home, or if you work at a huge software development company or tech company, or maybe you just work at a mom and pop shop down the road. I believe that if you engage ideas like these, then you will become better in your career. Thank you so much for listening, and until next time, enjoy your tea.