Vox

Leitura de 23 min

3X3: Anti-Resolutions To Kick Off Your 2018

Summary

In this episode of Developer Tea, host Jonathan Cottrell introduces the concept of “anti-resolutions”—things developers should stop doing rather than start doing in the new year. He explains that while New Year’s resolutions often focus on adding new habits, sometimes greater progress comes from eliminating counterproductive behaviors.

The first anti-resolution is to stop trying to talk like a developer by avoiding buzzwords and loaded terminology. Cottrell argues that terms like “reactive,” “responsive,” and “adaptive” have become so overloaded with meanings that they often hinder communication rather than help it. He recommends using simpler language when communicating with coworkers, clients, and managers, while acknowledging that these terms still have value for marketing and search engine optimization purposes.

The second anti-resolution is to quit being busy. Cottrell suggests that busyness is often a result of personal choices rather than external demands. He recommends using the Pareto principle to identify the most important 20% of daily activities and eliminating or reducing the less important 80%. However, he cautions against cutting out recreation and rest, emphasizing that this should be a prioritization exercise rather than a productivity exercise to avoid burnout.

The third anti-resolution is to stop taking projects down to the wire. Cottrell advises developers to aim to release the first version of any project at the 50% mark of their planned timeline. This approach acknowledges the common human tendency to underestimate project timelines and helps teams deliver working software earlier. He connects this to Agile and MVP (minimum viable product) principles, suggesting that smaller, more frequent releases lead to better learning and more reliable delivery.

Throughout the episode, Cottrell emphasizes that these anti-resolutions require awareness rather than significant effort, and they can help developers communicate better, manage their time more effectively, and deliver projects more reliably.

Recommendations

Concepts

  • Pareto Principle (80/20 Rule) — Jonathan recommends using this principle to identify the most important 20% of daily activities that produce 80% of the value, suggesting this as a method for prioritizing and eliminating busyness.
  • Agile and MVP (Minimum Viable Product) — Referenced in the context of project management, these methodologies support the idea of releasing smaller, working versions of projects earlier rather than taking projects ‘down to the wire’ with extensive feature lists.

Tools

  • Linode — A cloud hosting service praised for its well-designed user interface and aesthetic appeal. Jonathan highlights that their products are ‘a joy to use because they aren’t ugly’ and that good design improves both user experience and clarity of understanding.

Topic Timeline

  • 00:00:00 — Introduction to New Year’s resolutions and anti-resolutions — Jonathan introduces the episode’s theme of anti-resolutions—things to stop doing rather than start doing in the new year. He discusses how the social motivation of New Year’s resolutions can be helpful but suggests a different approach focusing on elimination rather than addition. The episode will cover three specific anti-resolutions for developers.
  • 00:03:40 — Sponsor message from Linode — Jonathan discusses today’s sponsor, Linode, highlighting their well-designed user interface and aesthetic appeal. He notes that good design in server management tools improves both user experience and clarity of understanding. The sponsor offers $20 credit to Developer Tea listeners using code DEVELOPERTEA2017.
  • 00:06:42 — First anti-resolution: Stop trying to talk like a developer — Jonathan presents the first anti-resolution: avoid using buzzwords and loaded terminology like “reactive,” “responsive,” or “adaptive” in everyday communication. He explains that these terms often focus on semantics rather than clear communication. The caveat is that these terms are still valuable for marketing and SEO purposes when potential clients are searching for services.
  • 00:11:05 — Second anti-resolution: Quit being busy — The second anti-resolution encourages developers to examine their schedules and eliminate non-essential activities. Jonathan suggests using the Pareto principle to identify the most important 20% of daily activities. He cautions against cutting out recreation and rest, emphasizing that this should be about prioritization rather than maximizing productivity at the expense of mental health.
  • 00:15:07 — Third anti-resolution: Stop taking projects down to the wire — The third anti-resolution advises developers to aim for releasing the first version of any project at the 50% mark of their planned timeline. Jonathan explains that this approach accounts for common underestimation of project timelines and aligns with Agile and MVP principles. He suggests that smaller, more frequent releases lead to better learning and more reliable delivery.
  • 00:19:19 — Conclusion and call to action — Jonathan concludes by encouraging listeners to consider these anti-resolutions for themselves. He thanks Linode for sponsoring the episode and expresses his belief that engaging with ideas like these will help developers do better work and improve their careers. The episode ends with the show’s signature sign-off.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2017-12-15T10:00:00Z
  • Duration: 00:20:14

References

Podcast Info

Transcript

[00:00:00] There are things that we all are probably going to try to start doing when January rolls around.

[00:00:11] We’ve talked about this on the show before, making your New Year’s resolutions or, you know,

[00:00:18] viewing it as a fresh start. And it makes sense because there’s a lot of other people who are

[00:00:24] making changes in their life or in their lives, rather. And if you see that happening around you,

[00:00:31] then perhaps you’re more likely or more willing to make changes in your own life,

[00:00:37] particularly changes that are visible. If it’s uncomfortable for you, for example, to

[00:00:42] go to the gym more often because maybe you don’t feel comfortable at the gym,

[00:00:49] well, there’s going to be more people at the gym in January than there are

[00:00:53] in most other months.

[00:00:54] Of course, it falls off as the year moves on, but at least in January, there are other people

[00:01:01] who are attempting to do the same thing. In today’s episode, we’re going to be talking

[00:01:05] about something a little bit different than that. We’re going to be talking about three things

[00:01:08] that you need to stop doing rather than start doing. These are your three kind of anti-resolutions

[00:01:17] is what we’re going to call them. Three anti-resolutions for your new year as you

[00:01:23] prepare, hopefully, for the new year.

[00:01:24] If you’re like me, you’re kind of preparing your mind for the new year. You’re journaling a little

[00:01:29] bit, maybe reflecting a little bit on this past year. You don’t have to wait until January starts

[00:01:35] to do this, but certainly don’t feel guilty if you decide to wait until January. It’s a natural

[00:01:41] time to do that. Other people doing it, like I said before, it adds to that kind of social sense

[00:01:48] of motivation. My name is Jonathan Cottrell. You’re listening to Developer Tea, my goal on

[00:01:53] this show.

[00:01:54] My goal on this show is to help developers like you find your career purpose. What does

[00:01:59] that mean? It means that I help you understand what it is that you care about, what it is

[00:02:05] that you want out of your career. Ultimately, most of your time, most of your waking hours

[00:02:12] at least, are going towards some kind of work. For most of your life, a large portion of

[00:02:20] your time is going towards your work. If you’re like most people, even the time out of your

[00:02:24] work is spent thinking or talking or studying about these subjects. Doesn’t it make sense then

[00:02:31] that we should make it worth our time, make it worth our effort? Doesn’t it make sense

[00:02:38] that the time that we have to do this work that we’re doing as developers, that we don’t just do

[00:02:45] it for the money to fund the minority of our time? Let me say that again and clarify. Doesn’t it make

[00:02:53] sense that we actually care about our jobs more than just for the sake of money to fund

[00:02:59] the small sliver of time that we’re not actually thinking about or doing work? That’s a challenge

[00:03:06] for you today, for you to think about your purpose in terms of that share of your life

[00:03:13] that it actually carries, the significant portion of time that you spend investing into

[00:03:18] this stuff. We’re doing this three-by-three episode. This is the last three-by-three episode

[00:03:23] of the week. I’m really excited about these three-by-threes. I think that people are going

[00:03:29] to absolutely benefit from having these key takeaways. One thing that we do during the

[00:03:36] three-by-three, we have a sponsor for these. We like to do at the beginning so we can go

[00:03:40] straight through the three takeaways. Today’s sponsor is Linode. With every sponsor, we send

[00:03:48] kind of a request to ask the sponsor what they’d like for us to talk about. Of course,

[00:03:53] you’ve heard a lot about Linode. They sent us this request quite a while back. They’ve been

[00:03:59] supporting the show for a long time. What I’ve decided to do recently is go and look a little

[00:04:05] bit deeper into the service offerings that they have to kind of bring to the service even more

[00:04:11] of the value that Linode is providing to developers. The thing that I want to kind

[00:04:17] of highlight today is the fact that Linode has really quite good design. Their products are

[00:04:23] kind of a joy to use because they aren’t ugly. A lot of the time, when we encounter these kind of

[00:04:30] cold server environments, we can get used to dealing with kind of kludgy, out-of-date design,

[00:04:38] but Linode has made an effort to make their user experience and, more explicitly, kind of their

[00:04:44] aesthetic presence online to make it attractive. It’s easy on the eyes. This can be undervalued.

[00:04:53] Especially by developers, but if you take some time and use Linode services, you will realize

[00:04:59] how valuable that actually is. Not only is aesthetically pleasing design a positive

[00:05:04] thing for your experience, but it also makes it a better product to use because it’s clearer to

[00:05:10] understand what’s going on. Of course, design is not just about aesthetics. It’s about organizing

[00:05:15] things in a way that is proper, in a way that your brain works well with them. If your service

[00:05:22] provider that you currently use is a product that you’re using, and you’re using it for a

[00:05:23] specific purpose, then that’s a good reason to check out Linode. There’s plenty of reasons to

[00:05:30] check out Linode. Of course, we’ve highlighted more recently some of their customer service

[00:05:37] things that they do, some of their involvement in the community, their IRC channel. Linode has

[00:05:42] so many offerings that they provide to developers, and it’s worth it just to check them out because

[00:05:48] it’s so, so affordable. You can get a Linode server up and running for $5 a month,

[00:05:53] and that’ll give you a gigabyte of RAM. Pretty much every personal website that I know of

[00:05:58] can run on these $5 a month servers. So go and check out what they have to offer.

[00:06:04] They’re going to give you $20 worth of credit just for being a Developer T listener.

[00:06:08] Use the code DEVELOPERT2017 at checkout. Now remember, that’s probably going to expire

[00:06:14] when 2018 rolls over. I’m sure that they will give us a new code. So if you’re listening to this in

[00:06:20] 2018, you may want to check out Linode. If you’re listening to this in 2018, you may want to check

[00:06:23] out another episode in 2018 that Linode is supporting as well. Thank you so much to

[00:06:29] Linode for sponsoring today’s episode and for continuing to support Developer T right into

[00:06:35] 2018. So let’s get straight into these anti-resolutions. Anti-resolutions, you can

[00:06:42] adopt these today, or you can wait until 2018. But certainly, these are not super difficult to

[00:06:48] adopt necessarily. They don’t require a lot of physical or mental effort, but rather,

[00:06:53] they do give you a lot of support. So if you’re listening to this in 2018, you may want to check

[00:06:53] do require awareness. They require you to think about the things that you’re saying and doing on a

[00:06:59] daily basis. So the first one that I want to outline here is to stop trying to talk like a

[00:07:05] developer. Stop trying to talk like a developer. What does this mean? Well, as developers, we like

[00:07:12] to throw around these kind of loaded terms. Reactive would be a good example. Responsive

[00:07:21] or adaptive. These are

[00:07:23] words that, especially in the web development world, have come to mean a lot of different things.

[00:07:30] And not only do they mean a lot of different things, but there are some people who get

[00:07:34] very passionate about defending the meaning of these words or redefining these words to mean

[00:07:41] something new. And the problem with this is that really it takes the focus off of communication

[00:07:48] and puts it onto semantics. So especially,

[00:07:53] if you are talking with your coworkers, we do have one caveat that I’m going to list here in

[00:07:58] just a second, but especially when you’re talking with your coworkers, and in particular, if you are

[00:08:03] a leader and you have younger developers who are kind of looking to you for guidance, if you’re a

[00:08:10] mentor or if you could be considered a mentor by someone, if someone is listening to you and

[00:08:15] they’re looking to you to kind of explain to them what’s going on in the industry, then I recommend

[00:08:21] that you try to avoid a lot of the things that you’re talking about. So if you’re a leader and you’re talking to

[00:08:23] your coworkers, you try to avoid words that are loaded. You try to avoid these buzzwords.

[00:08:27] Avoid talking about things in kind of ethereal, bigger level, higher level concepts. As much as

[00:08:35] you can simplify these terms, you’re much more likely to be able to communicate well with other

[00:08:42] developers. And you’re much more likely to actually achieve the thing that you’re trying to achieve

[00:08:48] with them. Now, here’s the caveat. And it’s an unfortunate caveat, but it’s one that I’m going to

[00:08:53] that exists and we have to figure out how to navigate around it. The caveat is these terms

[00:08:58] tend to be what people look for when they’re searching for someone like you, when they’re

[00:09:04] searching for a developer. In particular, if you’re working in an agency, you’re likely going

[00:09:09] to have people searching responsive web design to find a firm or find an agency that will do

[00:09:16] web design for them. And every industry has these key terms. These are terms that kind of signal

[00:09:23] various belief systems about how the work should be executed, right? They kind of point towards

[00:09:31] your values as a company. If you value adaptive, responsive web design, then the people who are

[00:09:40] looking for you, the people who are searching these terms, they know that you’re on the leading

[00:09:45] edge of the industry, right? That’s kind of the heuristic that they’re using. They’re trying to

[00:09:50] use these words as a way to find someone who’s going to be able to do the work that they’re

[00:09:53] credible. Now, whether that is good or bad, we aren’t really going to debate on this episode,

[00:09:59] but it certainly is still the case. So don’t go and, you know, try to rip all that stuff out of

[00:10:06] your website. And certainly don’t look down on your marketing manager or on the person who’s

[00:10:12] responsible for your content management. Don’t look down on them for trying to utilize these

[00:10:18] words in meaningful ways. They are not meaningless words, and they are not

[00:10:23] just full of fluff. What this anti-resolution is about is trying to use those words in your

[00:10:30] everyday conversation when you’re building a product, when you’re actually working,

[00:10:35] when you’re trying to communicate about, for example, a problem that you’re having.

[00:10:39] Try your best to frame that problem in the most simple language possible. Go to the lowest common

[00:10:46] denominator that you can, and hopefully this will help you kind of translate between you

[00:10:52] and a coworker.

[00:10:53] You and a client. You and a manager. Your boss. That translation process is extremely important,

[00:11:00] and the simpler language you use, the better. The second anti-resolution, and this is the

[00:11:05] hardest one of the three, probably, but the second anti-resolution is quit being busy.

[00:11:13] Quit being busy. There’s quite a few podcast episodes on this subject that are coming out

[00:11:19] right now, but the idea here is that busy is…

[00:11:23] Very often, a result of your own decisions. I challenge you to write out your entire schedule

[00:11:30] for a given day, and I want you to look at this schedule, and I want you to identify

[00:11:36] the most important… We’ll use the Pareto principle here. It’s very commonly used in

[00:11:42] these kinds of discussions. The most important 20% of events or activities that you participate in

[00:11:49] for that day. For example, you might actually identify…

[00:11:53] That cooking breakfast is extremely important to you, so you want to protect the time

[00:11:58] to cook your breakfast, but you may also identify that later on in the day,

[00:12:04] you spent some time watching TV or maybe something more productive. You spent some time cleaning your

[00:12:11] house. You may identify that that wasn’t really that important to you, that you doing the cleaning

[00:12:16] work yourself is not really important to you, that if you could offload that, if you could hire

[00:12:22] someone to do it, you might identify that that wasn’t really that important to you, that you

[00:12:23] would. Now, I’m not by any means saying that you need to outsource all of the manual labor in your

[00:12:30] life. Very often, these manual labor tasks that we have to do as developers, they can be healthy

[00:12:37] for us because most of the work that we’re doing is not manual labor. We’re not really

[00:12:41] moving around very much in our day job, so it’s a good break. It’s a good physical break,

[00:12:47] a good mental break to clean your house or to mow your lawn, but take a look at that,

[00:12:53] and identify that top 20% most important stuff that you do in your day. You’re likely to find

[00:13:00] that there’s a large portion of things that you do. There’s a large number of things that you do

[00:13:06] that if you were to cut them out entirely, not just reduce them, but totally cut them out

[00:13:12] of your habits, totally cut them out of your schedule, if you could cut those things out,

[00:13:17] then you would be much less taxed for time. Another good example might be,

[00:13:23] maybe you drive to work, and you could take public transportation. This may be a way that

[00:13:32] you can read a little bit more, for example. If you wanted to start reading more books,

[00:13:38] but you can’t find the time, well, perhaps it’s time to start taking the bus.

[00:13:42] This does also come with a caveat, similar to the first anti-resolution. I have a caveat for

[00:13:47] the second one as well, and that is to be careful about eliminating your recreation.

[00:13:53] Be careful about eliminating your rest and your recreation. What a lot of people end up doing is

[00:14:00] they cut in areas that are good for their mental health because they see this as a productivity

[00:14:07] exercise rather than a prioritization exercise. What does that mean? Well, a lot of people are

[00:14:15] trying to squeeze every minute out of every day for the most productive things that they think

[00:14:21] they can do. That means replacing a lot of things that are good for their mental health.

[00:14:23] All of their leisure time with work. Very often, this is the wrong decision because your balance

[00:14:31] as a human, in order to avoid things like burnout, you have to balance, and you have to have that

[00:14:38] leisure time. Now, it may be imbalanced currently. You may be spending a large majority of your free

[00:14:44] time doing something leisurely, and there may be plenty of room for you to cut back a little bit

[00:14:49] on that. But again, remember, this is a prioritization.

[00:14:53] This is a prioritization exercise, not a productivity exercise. This is a prioritization

[00:14:58] exercise. All right, anti-resolution number three. Stop taking your projects down to the wire.

[00:15:07] Stop taking your projects down the wire. If I could tell every team of developers around the

[00:15:15] country, around the world, all the way into the future, if I could give them one piece of advice,

[00:15:21] this would probably be it.

[00:15:23] You need to be targeting to release the first version of any project at the latest, at the 50%

[00:15:31] mark. This means that whatever scoping, whatever planning that you’re doing, whatever your sprint

[00:15:38] planning is, whatever your release schedule is, however you’re doing your management, however

[00:15:43] you’re doing agile or extreme programming, all of these things that culminate to the delivery of a

[00:15:49] project, you should be allocating 50% to the first version of any project.

[00:15:51] You need to be targeting to release the first version of any project at the latest, at the 50% mark.

[00:15:53] You should be allocating 50% of the time that you’re planning to use. You should look at that 50%

[00:15:59] as your primary container, as your very first release. Now, if you’re working on an iterative

[00:16:06] release cycle, then that can be earlier. It can be much earlier than 50%, but certainly no later.

[00:16:13] You shouldn’t be planning your projects as if 100% utilization or even 80% utilization

[00:16:19] is an accurate estimate. Here’s what’s going to happen.

[00:16:23] If you actually take this to heart, if you go and start trying to launch your projects at 50%,

[00:16:29] number one, what you’re most likely to find is that you’re going to be on time more often. You’re

[00:16:34] actually going to hit that 100% mark because most of the time you’re going to underestimate.

[00:16:40] That’s not a knock against whoever’s listening to this podcast. This is just a normal pattern

[00:16:46] that humans follow, and it’s very difficult to subvert. We’re not going to go into the details

[00:16:51] on that, but this is just a normal pattern that humans follow. We’re not going to go into the

[00:16:53] details on that, but this is very common, very difficult to subvert, and you’re likely to

[00:16:57] overestimate. But let’s say that you somehow strike gold and you estimated properly. Well,

[00:17:04] now your project is shipped early. This is never a problem. Your project is shipped early. Now,

[00:17:11] does it have every single feature that you want in that project? Does it have everything that

[00:17:16] the client asked for? Does it have every interface, you know, a polish that they wanted or that you

[00:17:23] wanted or that the product called for? No, it doesn’t. It is intentionally forcing you to

[00:17:30] pare this thing down to make it a smaller project. If everything was smaller, it would become easier

[00:17:37] to do. And so what you want to do is compose that smaller project with more smaller projects. Take

[00:17:44] the next half of your project and iterate over that first part. Now, what you get in addition

[00:17:51] is you get the learning curve. You get the learning curve. You get the learning curve. You get the

[00:17:53] learning that you have by already having this thing in some form as a usable product. This

[00:17:59] really is the basis of Agile and MVP delivery and iterative development, but it can be applied

[00:18:07] across the board. If you start with the idea of cutting your project in half, taking out all of

[00:18:17] the least necessary pieces, I won’t say they’re unnecessary, but take out all of the least

[00:18:23] necessary pieces, cut that scope directly in the middle, and then try to launch that 50% mark.

[00:18:31] Again, you’re very likely to find that the project is going to run over that 50% mark.

[00:18:37] And I encourage you, managers who are out there who are skeptical of your team,

[00:18:43] and you think that your team is going to fill up any schedule that they’re provided,

[00:18:48] whether it’s five days or 50 days, that would take up 100% of the time allocated.

[00:18:53] If you believe that’s the case, then run this experiment with the mindset that you can keep

[00:19:00] the original plan, but you want to kind of track progress. See how far along you got by the 50%

[00:19:07] mark. And what you’re likely to find, once again, is that if you were to scope things down to that

[00:19:12] 50% mark, that you will be much more likely to deliver an excellent product on time.

[00:19:19] Thank you so much for listening to today’s episode of Developer Tea. I hope you will

[00:19:23] consider these anti-resolutions for yourself. And thank you again to Linode for sponsoring

[00:19:29] today’s episode and helping us carry this podcast into the ears of thousands of developers.

[00:19:36] I truly believe that if you engage ideas like what we present on this podcast,

[00:19:42] that you will do better work. That each day that you go into your job or each day that you sit

[00:19:47] down at your desk, if you’re a freelancer at home, or if you work at a huge software development

[00:19:53] company or tech company, or maybe you just work at a mom and pop shop, you know, down the road.

[00:19:58] I believe that if you engage ideas like these, then you will become better in your career.

[00:20:04] Thank you so much for listening. And until next time, enjoy your tea.

Visão de gráfico