In today's episode, I give you 3 anti-resolutions to start out your 2018 planning. Today's episode is brought to you by Linode. Linode provides superfast SSD based Linux servers in the cloud starting at $5 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners .
In today's episode, I give you 3 anti-resolutions to start out your 2018 planning.
Today's episode is brought to you by Linode.
Linode provides superfast SSD based Linux servers in the cloud starting at $5 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners!
There are things that we all are probably going to try to start doing when January rolls around. We've talked about this on the show before, making your New Year's resolutions or, you know, 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. And 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, well, 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 is what we're going to call them. Three anti-resolutions for your New Year as you prepare. Hopefully, you're going to be able to do them. Hopefully, if you're like me, you're kind of preparing your mind for the New Year. You're journaling a little bit, maybe 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 Cottrell. 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. And 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. And if you're like most people, even the time you're going to work, time outside of work is spent thinking or talking or studying about these subjects. So 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 threes. I think that people are going to absolutely benefit from having these key takeaways. One thing that we do during the three by three, we have a sponsor for these. We like to do at the beginning so we can go straight through the three takeaways. Today's sponsor is Linode. And with every sponsor, we send kind of a request to ask the sponsor what they'd like for us to talk about. And of course, you've heard a lot about Linode and they sent us this request quite a while back. They've been supporting the show for a long time. And so what I've decided to do recently is go and look a little bit deeper into the service offerings that they have to kind of bring to the service even more of the value that Linode is providing to developers. And the thing that I want to kind of 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. And a lot of the time when we encounter these kind of cold server environments, we can get used to dealing with kind of kludgy 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. And this can be undervalued. Especially by developers. But 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. So if your service you're going to be able to make a difference. And that's what Linode is doing. And that's what you're 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 Linode. 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. And 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. And it's worth it just to check them out because it's so, so affordable. You can get a gigabyte of RAM. Pretty much every personal website that I know of can run on these $5 a month servers. So go and check out what they have to offer. They're going to give you $20 worth of credit just for being a Developer T listener. Use the code DEVELOPERT2017 at checkout. Now, remember, that's probably going to expire when 2018 rolls over. I'm sure that they will give us a new code. So if you're listening to this in 2018, you may want to check it out. If you're listening to another episode in 2018 that Linode is supporting as well. Thank you so much to Linode for sponsoring today's episode and for continuing to support Developer T right into 2018. So let's get straight into these anti-resolutions. Anti-resolutions. You can adopt these today or you can wait until 2018. But 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. So 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 would be a good example. But what does this mean? Well, as developers, we like to throw around these words that are used to describe things. And these are words that, especially in the web development world, have come to mean a lot of different things. And 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. And 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 co-workers, we do have one caveat that I'm going to list here in just a second. But especially when you're talking with your co-workers, 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 avoid words that are loaded. You try to avoid these buzzwords. 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. Now, here's the caveat. And it's an unfortunate caveat, but it's one that I'm going to list here in just a second. 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, when they're searching for a developer. In particular, if you're working in an agency, you're likely going to have people searching 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, right? 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, right? That's kind of the heuristic that they're using. They're trying to use these words as a way to find someone who's a good developer. And they're trying to find someone who's a good developer. And they're trying to find someone who's a good developer. And they're trying to find someone who's a good developer. And they're trying to find someone who's a good developer. And they're trying to find someone who's a good developer. And they're trying to find Now, whether that is good or bad, we aren't really going to debate on this episode. But it certainly is still the case. So don't go and try to rip all that stuff out of your website. And certainly don't look down on your marketing manager or on the person who's 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. And they are not just words. They are not just words. They are not just words. They are not just words. They are not just 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. And hopefully this will help you kind of translate between you and a co-worker, 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 this subject that are coming out right now. But 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. And I want you to look at this schedule and I want you to identify the most important... We'll 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. So you want to protect the time to cook your breakfast. But 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. That you doing the cleaning work yourself is not really important to you. That if you could offload that, if you could hire someone to do it for you, you might identify that that wasn't really that important to you. Then you would. Now, 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. So it's a good break. It's a good physical break, a good mental break to clean your house or to mow your lawn. But take a look at that, and identify that top 20% most important stuff that you do in your day. And 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 public transportation. This may be a way that you can read a little bit more, for example, right? 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. And this does also come with a caveat, similar to the first anti-resolution. I have a caveat for the second one as well. And 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 a lot of the things that they've done in their life. 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 it. 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 your time to the project. And that's a very important thing. If 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. And it's very difficult to subvert. And we're not going to go into the details on that, but this is very difficult to subvert. And we're not going to go into the details on that, but this is very difficult to subvert. 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 asked for? Does it have every interface, you know, a polish that they wanted or that you, you wanted? Does it have everything that the client asked for? Does it have everything that you wanted or that the product called for? No, it doesn't. It is intentionally forcing you to pare 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 curve. And you get the learning curve. And you get the learning curve. 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. And you get the learning curve. And you get the learning curve. 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. And 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. And you're going to find that they're going to run over that 50% mark. 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 kind of track progress. See how far along you got by the 50% mark. And what you're likely to find, once again, is that if you were to scope things down to that 50% mark, that 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 you're a freelancer at home, or if you work at a huge software development company, you're going to be able to do better work. 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.