Vox

Leitura de 24 min

3x3: The 3 Things you Shouldn’t Be Doing As A Developer

Summary

In this episode of Developer Tea, host Jonathan Cutrella kicks off a “Three by Three” week with three practical things developers should stop doing to improve their effectiveness and impact.

The first behavior to stop is staying up late. While it might feel productive or align with developer culture, staying up late often leads to wasted time and less effective work. Research shows our brains are freshest in the morning when we haven’t made many decisions yet, making early mornings more productive than late nights. Getting adequate sleep (at least 6 hours) and optimizing for energy and focus rather than trying to reclaim minutes is more valuable.

The second behavior is relying on gut estimations for project timelines. Our gut tends to underestimate because it focuses on the simplicity of the path to completion rather than accounting for unexpected variables like interruptions, bugs, stakeholder changes, or personal issues. These compounding variables can exponentially extend timelines beyond initial estimates.

The third behavior is optimizing small things before fixing big problems. Using web development as an example, developers might spend time minifying JavaScript while ignoring much larger issues like uncompressed multi-megabyte images. The principle applies broadly: prioritize the biggest gains first, whether in code optimization, feature development, or life priorities. Identify the most important task each day and tackle that before smaller optimizations.

Throughout the episode, Cutrella emphasizes that the ultimate goal isn’t just personal success but helping driven developers create positive impact through their work. The practical takeaways are designed to help listeners become more effective in their daily work.

Recommendations

Practices

  • Daily Most Important Task — Jonathan suggests writing down today’s most important task each day as a practice to maintain focus on priorities rather than getting distracted by small optimizations.
  • Early Morning Work Schedule — Recommends shifting to early morning work (like 4:30 AM wake-up) rather than staying up late, based on the principle that our brains are freshest before decision fatigue sets in.

Tools

  • Linode — Linux service provider recommended for developers, offering affordable plans starting at $5/month for 1GB, with fast internal networking and Node Balancer service.

Topic Timeline

  • 00:00:00 — Introduction to Three by Three Week — Jonathan introduces the concept of ‘Three by Three’ weeks where he’ll share three practical takeaways in each episode. He explains the show’s mission is to help driven developers become better at what they do so they can create positive impact in the world, not just achieve personal success metrics like salary increases or titles.
  • 00:04:50 — Sponsor: Linode — The episode is sponsored by Linode, a Linux service provider. Jonathan recommends Linode for its affordable pricing starting at 20 credit using code DEVELOPERT2017 at spec.fm/linode.
  • 00:07:03 — First Thing to Stop: Staying Up Late — Jonathan argues against the developer culture of staying up late, noting it often leads to wasted time and less effective work. He explains that our brains are freshest in the morning before decision fatigue sets in, making early mornings more productive. He shares personal experience of shifting to early mornings (4:30 AM wake-up) and getting adequate sleep rather than trying to reclaim time through late nights.
  • 00:13:26 — Second Thing to Stop: Gut Estimations — Jonathan warns against relying on gut feelings for project estimations. Our gut focuses on how easily we can see a path to completion (simplicity) rather than accurately forecasting time. Unexpected variables like interruptions, bugs, stakeholder changes, or personal issues can compound and exponentially extend timelines beyond initial estimates.
  • 00:17:48 — Third Thing to Stop: Optimizing Small Before Big — The final recommendation is to stop optimizing small things before fixing big problems. Using web development as an example, developers might minify JavaScript while ignoring much larger issues like uncompressed multi-megabyte images. The principle applies broadly: prioritize the biggest gains first in code optimization, feature development, and life priorities. Jonathan suggests identifying the most important task each day and tackling that first.
  • 00:20:32 — Conclusion and Call to Action — Jonathan concludes the first Three by Three episode and encourages listeners to provide feedback if they enjoy this format. He reiterates the show’s mission of helping driven developers create positive impact and thanks Linode for sponsoring. Listeners are encouraged to rate and subscribe to help reach more developers.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2017-11-06T10:00:00Z
  • Duration: 00:21:48

References

Podcast Info

Transcript

[00:00:00] As a developer, you’re often told all of the things that you should be doing, and that

[00:00:11] list can get long very quickly.

[00:00:13] In fact, it can get so long that really it becomes impossible to accomplish.

[00:00:18] So in today’s episode, I want to talk about things that you shouldn’t be doing.

[00:00:23] And the hope is that you can create the space to do only the most important things, only

[00:00:30] the things that matter.

[00:00:32] My name is Jonathan Cutrella.

[00:00:34] You’re listening to Developer Tea.

[00:00:36] My goal on this show is to help driven developers become better at what they do.

[00:00:41] The ultimate reason for this goal, which I don’t know that I’ve ever shared this on the

[00:00:46] show before, but the ultimate reason for this is because I believe driven developers that

[00:00:51] have a strong sense of values.

[00:00:53] They’re going to create tomorrow that you as the developer, the software developers

[00:00:58] who are listening to this show, you have an opportunity to make a big impact in the work

[00:01:04] that you do.

[00:01:05] And that means that your job is not just a job, that your development interest is not

[00:01:12] just a hobby, and that you’re not just working for a paycheck.

[00:01:16] You’re going beyond that.

[00:01:18] You’re diving into your personal values.

[00:01:21] You’re understanding how to best.

[00:01:23] Organize your time and stay mindful of what you’re doing and the effect of what you’re

[00:01:29] doing.

[00:01:29] All of these things are so important.

[00:01:31] So we’re going to talk about all this stuff on every episode of Developer Tea from a different

[00:01:36] angle, from a different facet of this same ultimate underlying mission, really, for this

[00:01:43] show, which is to enable you as the driven developer to become better at what you do

[00:01:49] so that you can go and make a positive impact on the world.

[00:01:53] Not just so you can raise your salary, not just so that you can get a title or accomplish

[00:02:01] some kind of personal goal.

[00:02:04] Those things are all certainly perfectly fine.

[00:02:08] There’s nothing wrong with getting a higher salary or accomplishing a personal goal or

[00:02:13] getting a new title.

[00:02:14] All of those things are perfectly fine.

[00:02:16] But the ultimate goal that we have on this show is to help you create a positive impact

[00:02:22] on the people.

[00:02:22] And ultimately the world around you.

[00:02:25] That’s why it’s okay that if you have only selfish motivations that you don’t listen

[00:02:30] to this podcast.

[00:02:31] That’s why it’s okay for you if you’re looking to only hack your way to the top or take shortcuts

[00:02:38] and reduce your effort and try to stop working or try to retire as early as possible.

[00:02:45] If there’s no passion or appreciation for the work that you’re doing, then you’re probably

[00:02:50] not going to enjoy this podcast.

[00:02:52] So we want to encourage you to believe in the work that you’re doing and to walk into

[00:02:58] your workplace every single day with a drive and a passion for what you do.

[00:03:03] So that’s part of becoming better at what you do.

[00:03:07] So that’s what we’re doing.

[00:03:08] We’re enabling you as a developer, as a driven developer to become better at what you do

[00:03:13] so that you can create a positive impact on the people and ultimately the world around

[00:03:18] you.

[00:03:18] So we’ve done a lot of episodes of this show.

[00:03:22] We’re well into the 400s.

[00:03:24] I think we’re around 450 episodes at this point.

[00:03:28] And some of the most popular episodes that we’ve done are the ones with digestible kind

[00:03:34] of focused points that you can take away, practical points.

[00:03:38] And that makes total sense, doesn’t it?

[00:03:40] This is the way that we understand information.

[00:03:43] We can categorize it.

[00:03:44] We can create, you know, if you’re journaling, if you’re writing notes about these episodes,

[00:03:49] you can create points in your journals and you can actually write them.

[00:03:52] Down and take them away and use them.

[00:03:55] So the practical value of these episodes certainly correlates with their popularity.

[00:04:02] And so what I’ve decided to do is every few months or so, we’re going to do a week that

[00:04:07] is solely dedicated to practical takeaways.

[00:04:10] These weeks are going to be called three by threes, and we’re going to have three episodes

[00:04:14] where you have three practical takeaways.

[00:04:16] We may have a bonus takeaway here and there, but three by threes.

[00:04:20] And this week is the first three.

[00:04:22] Three by three week.

[00:04:24] And we already mentioned what we’re talking about today.

[00:04:26] We’re talking about things that you should stop doing, things you should stop doing as

[00:04:31] a developer.

[00:04:32] Some of this is behavioral, but some of this is also things that you may think are proactive,

[00:04:39] but they’re actually not.

[00:04:40] So in these three by three episodes, because you can’t split three in half, we’re going

[00:04:44] to take a moment before we talk about those three takeaways to talk about the sponsor

[00:04:49] for today.

[00:04:50] Today’s sponsor is Linode.

[00:04:52] Linode has been a sponsor of Developer Tea for quite a while, and you can thank them

[00:04:57] for a significant portion of this show’s ability to continue doing what we do.

[00:05:03] And one of the things that you definitely should stop doing is searching for a Linux

[00:05:09] service provider.

[00:05:10] If you’re spending time comparing different providers and you haven’t looked at Linode,

[00:05:15] I recommend you go and check them out.

[00:05:16] Linode provides the best dollar per gigabyte service that I’ve found.

[00:05:22] They have a one gigabyte plan for $5, so that’s an incredible entry-level price.

[00:05:30] No matter what level of developer you are, you should be able to afford $5 per month.

[00:05:38] But they also have higher level plans.

[00:05:40] Linode is not just a hobby service.

[00:05:43] They provide much higher gigabyte plans.

[00:05:46] They have incredibly fast internal network for networking.

[00:05:51] Multiple…

[00:05:52] Nodes together.

[00:05:53] And they have a service called Node Balancer to do exactly that.

[00:05:57] So I recommend you go and check out Linode.

[00:05:59] If you are looking for a Linux service provider, basically you can get a Linux box up and running

[00:06:06] in just a few minutes.

[00:06:07] And it’s very easy to do.

[00:06:09] And they have excellent customer service.

[00:06:11] So many reasons to take a look at Linode.

[00:06:13] Spec.fm slash Linode.

[00:06:15] If you don’t have enough reasons already, here’s kind of the final reason that should

[00:06:20] push you over the edge.

[00:06:21] Linode is going to…

[00:06:21] It’s going to provide you with $20 worth of credit that you can use on any Linode service

[00:06:27] just for being a Developer T listener.

[00:06:30] If you use the code DEVELOPERT2017 at checkout, you will get that $20 worth of credit.

[00:06:37] Thank you again to Linode for continuing to sponsor Developer T and helping developers

[00:06:42] everywhere have access to excellent Linux boxes for less.

[00:06:47] Thank you again to Linode.

[00:06:48] So we’re talking about things that you shouldn’t do.

[00:06:51] In today’s first episode of a three-by-three week, this whole week, we’re going to be doing

[00:06:56] these three-point takeaways.

[00:07:00] Today’s episode is three things you should stop doing as a developer.

[00:07:03] Number one, staying up late.

[00:07:05] Staying up late.

[00:07:07] At first in my career, I thought I was doing a good thing by staying up late.

[00:07:14] I felt creative.

[00:07:15] I felt energized.

[00:07:16] I felt like I could get a lot done.

[00:07:18] And I felt like burning the midnight oil.

[00:07:21] That was something that was, you know, kind of, it followed the lore of being a developer.

[00:07:27] It was part of being a developer in a lot of ways.

[00:07:30] Culturally speaking, people know developers as the guys who stay up late and drink energy drinks

[00:07:37] and eat pizza and hack things out, fix problems, build stuff, build side projects.

[00:07:44] And all of that was attractive to me.

[00:07:46] On top of that, I have a natural tendency to want to stay up a little bit later.

[00:07:51] Rather than wake up early.

[00:07:53] And as it turns out, this doesn’t really work out.

[00:07:56] And for a few reasons.

[00:07:58] One, most businesses actually run normal business hours, right?

[00:08:04] So even if your company is progressive and you work remotely and you work asynchronously

[00:08:10] and you get to choose your hours, most other businesses run from nine to five.

[00:08:16] This doesn’t necessarily create a problem, but it might create one in the future.

[00:08:20] Right?

[00:08:21] And you may end up needing to have that productive time that overlaps with that nine to five.

[00:08:28] And if you set up your schedule and you set up your rhythm to be a late night worker,

[00:08:33] then eventually that could become a problem.

[00:08:36] Now, that’s not the main reason that it’s a problem, actually.

[00:08:39] As it turns out, the main reason it’s a problem is because most of the time for most people,

[00:08:45] their best work is done first.

[00:08:50] Now, let me explain.

[00:08:51] The basic science behind this, your best work is going to be done in the morning when you

[00:08:57] haven’t done anything else yet.

[00:08:59] When you wake up in the morning, your brain essentially is fresh.

[00:09:04] There’s a lot of other ways of explaining this, but you haven’t fatigued your brain

[00:09:09] yet.

[00:09:10] You haven’t made a bunch of decisions yet.

[00:09:12] You haven’t had to do a bunch of thinking yet.

[00:09:16] And so your brain is not fatigued.

[00:09:19] And you can actually solve creative.

[00:09:21] And important problems better first than you can later.

[00:09:25] And unfortunately, when you stay up late working, those are the last things that you’re doing

[00:09:31] with your brain.

[00:09:32] And this is a problem, right?

[00:09:33] This is a mismatch.

[00:09:35] Because if your highest capacity, at least from a neurological science level, if your

[00:09:41] highest capacity is early in the day when you haven’t made a bunch of decisions in that

[00:09:46] particular waking cycle, then it only makes sense to…

[00:09:51] You wait your day towards the front.

[00:09:54] It’s also important to note that as it gets later, you become more and more sleepy, right?

[00:10:00] And there’s a very simple and practical reason not to stay up and work late.

[00:10:06] And staying up late on its own may not necessarily be a problem, but you’re very likely to get

[00:10:12] less sleep if you stay up late than if you were to go to bed at a somewhat earlier time.

[00:10:19] For me, my schedule has reduced.

[00:10:21] Recently shifted.

[00:10:22] You know, I have a newborn, so I don’t get as much sleep as an average person does anyway.

[00:10:28] He’s no longer newborn, but, you know, the sleep cycle has been a little bit off.

[00:10:33] But I’ve set myself up for early mornings.

[00:10:37] And this means going to bed more like 10.30 my time and waking up more like 4.30 my time

[00:10:42] rather than, you know, consistently going to bed at 12 or 1.

[00:10:47] Here’s another anecdotal piece of evidence.

[00:10:50] At least for me.

[00:10:51] I found that staying up late, typically, you know, the later I stayed up didn’t really

[00:10:56] have any effect on my productivity or my happiness.

[00:11:00] You know, I usually would waste that extra time.

[00:11:03] I would waste the extra time because my brain is already tired and I just want to relax

[00:11:08] when it’s late.

[00:11:09] I just want to spend that time doing nothing productive, right?

[00:11:14] And so what I found was a lot of that wasn’t even valuable to me.

[00:11:18] It wasn’t really adding extra positive value.

[00:11:21] Or extra positive mental perception of my day.

[00:11:24] And I would go to bed feeling extremely tired.

[00:11:27] I would go to bed having wasted a bunch of time doing kind of mindless activities to

[00:11:33] recuperate from the day.

[00:11:34] And I wouldn’t get as much done as I’d hoped I would get done.

[00:11:38] So this is definitely an opinionated thing.

[00:11:42] Some people find that staying up late is actually a really positive thing for them.

[00:11:48] And I can’t prescribe to you.

[00:11:51] Perfectly, whether this is going to work for you or not.

[00:11:54] What I will say is, on the average case, for most developers who are listening to this,

[00:12:00] staying up late is not going to be as effective for you as getting up early would be, right?

[00:12:06] Getting up a little bit early, going to bed a little bit earlier.

[00:12:09] Really, the coinciding factor here is that you need to get a positive amount of sleep.

[00:12:15] That means you need to be getting the recommended amount of sleep every single night.

[00:12:21] Now, we aren’t going to go into exactly how much that is because the ranges are pretty large.

[00:12:27] But I will say that I go with the recommended number, which is six hours at the minimum.

[00:12:33] I’m not spending a lot of my energy trying to figure out how to regain the one or two hours

[00:12:39] of sleeping time by hacking my sleeping schedule.

[00:12:43] I don’t really find a lot of value in trying to optimize my day down to that level.

[00:12:49] Instead, I want to optimize.

[00:12:50] My energy and focus more than my time.

[00:12:54] Let me say that again.

[00:12:55] It’s kind of like a side bonus piece here.

[00:12:57] I’m going to optimize my energy and focus rather than my time.

[00:13:01] Essentially, what that means is I want to put my energy and my focus on the right things

[00:13:07] at the right time.

[00:13:09] My motivation isn’t to try to regain extra minutes in every single crack that I possibly can,

[00:13:15] but rather to put my energy and focus on the right things at the right time.

[00:13:19] All right.

[00:13:20] So,

[00:13:20] moving on to number two of the three things that you should stop doing as a developer.

[00:13:25] Number two,

[00:13:26] going with your first gut for estimation.

[00:13:30] Going with your first gut for estimation.

[00:13:32] This is a totally different subject than staying up late, right?

[00:13:35] This is more about your working processes.

[00:13:37] We’ve talked about estimation in the past before.

[00:13:40] We’ve talked about estimating sandwiches.

[00:13:42] I recommend you go and listen to that episode.

[00:13:45] That one really kind of changed the way that I think about estimation fundamentally.

[00:13:49] But here’s the reality.

[00:13:50] Your gut believes that you are better than you are.

[00:13:55] Now, this isn’t a bad thing.

[00:13:57] Your gut is not, you know, is not prideful, right?

[00:14:01] It’s not a problem of humility, but rather it’s a problem of perspective and the ability

[00:14:07] to forecast.

[00:14:09] Your gut is not a good forecaster.

[00:14:11] And here’s what ends up happening.

[00:14:13] Unexpected things occur, right?

[00:14:17] Even in the average case.

[00:14:19] Or even in the most predictable work style,

[00:14:23] the most predictable work environment with the most predictable work tasks.

[00:14:29] Unpredictable things can happen.

[00:14:31] For example, you may run into traffic.

[00:14:35] You may have, you may get the flu.

[00:14:38] The client or the user or some other stakeholder may be indecisive.

[00:14:44] So you may have to shift directions.

[00:14:46] You could get called in for jury duty.

[00:14:49] There are a hundred, maybe a thousand variables that your gut doesn’t really take into account

[00:14:57] when you ask it, how long is this going to take?

[00:15:00] And going with your first gut estimation, even though your gut may be able to estimate,

[00:15:06] even here, it’s probably wrong.

[00:15:07] But even though your gut may be able to estimate the actual work, in other words, the amount

[00:15:12] of energy that it’s going to take to do that particular thing, it’s not estimating all

[00:15:17] of the inefficiencies.

[00:15:19] And in a row.

[00:15:19] interruptions that you face every single day. Now, we’ve talked about trying to control for

[00:15:24] those. We’ve talked about trying to protect our focus and build our days so that we can focus on

[00:15:30] one thing at a time and limiting our work in progress. But ultimately, unexpected things

[00:15:36] are still going to happen, even in the most controlled scenarios. Now, if you go to the

[00:15:41] average case where the amount of control over the actual work itself is also variable, right? So we

[00:15:48] have, you know, unexpected features and we have bugs that we can’t figure out for a full day. And

[00:15:54] as it turns out, it was just a syntax error. And, you know, there’s a hundred other things and

[00:16:00] perhaps a thousand other things that you can add in. And you’re not talking about, you know,

[00:16:06] linear variables. This is unfortunately kind of an exponential growth curve, right?

[00:16:11] If you remember from your complexity analysis practice, if you have these variables and they’re

[00:16:18] combined with each other, you could end up in a scenario where those variables really and greatly

[00:16:24] extend the amount of time that you expected, that your gut expected for this particular thing to

[00:16:31] take. That is going to be completely blown out of the water once you start compounding some of

[00:16:36] these variables together. And the reality is, you know, what we do, and this, we talked about this

[00:16:42] in the sandwiches episode, but what we do when we do gut estimation is we, we ask ourselves,

[00:16:48] how easily can I see a path to success, right? Seeing that path, you know, it’s kind of like

[00:16:54] looking at a map or, you know, getting directions on Google maps. It seems like it’s a very easy

[00:17:00] trip, right? It’s, you know, maybe two turns along the way, but that doesn’t give you an idea of how

[00:17:08] long it’s going to take. It only tells you how complex it is. So our gut tells us that it will be

[00:17:14] simple. And we translate that simplicity into, you know, how easily can I see a path to success?

[00:17:18] Simplicity to a time factor. And this is a problem, right? And these are not on the same

[00:17:24] scale. And so even if it is simple, it still is going to take an amount of time. And we shouldn’t

[00:17:30] be using simplicity to determine the amount of time. Now, does it affect the time? Does complexity

[00:17:36] affect time? Absolutely. But we shouldn’t use those on the same scale. So that’s the reason

[00:17:42] you shouldn’t be using your gut to estimate. Number three, and this is the final one for

[00:17:47] today’s three by five.

[00:17:48] Optimizing the small things before fixing the big things. I see this all the time. Optimizing

[00:17:55] the small things before fixing the big things, especially in web development, for example. And

[00:18:00] I think the reason for this is because we perceive those small things to be bigger than they really

[00:18:06] are. Or perhaps we don’t really have the right metrics in front of us. So I’ll give you a basic

[00:18:13] example. If you were spending your time trying to minify and, you know,

[00:18:18] compress your JavaScript, and this is a web development example, compress your JavaScript

[00:18:23] and trying to move everything into the footer so it’s non-blocking and you’re trying to make your

[00:18:28] CSS smaller and you have, let’s say, 10 images on the page that are uncompressed and they’re

[00:18:35] three megabytes apiece, well, chances are that your biggest gains are going to be from compressing

[00:18:42] those images. There are very few instances where compressing your JavaScript is going to provide

[00:18:48] the same gain as compressing an image. And the simple factor there is that the image is much,

[00:18:53] much larger, right? Compressing an image may bring you a significant, maybe even a 10x

[00:19:00] lowering on the number of bytes that you had to deliver to the user’s browser. So that’s a really

[00:19:06] specific example, but this really generalizes to a lot of other problems that we face. For example,

[00:19:13] how we place priority on different views in our applications.

[00:19:16] If a user is really heavily using one view, perhaps 90% of the time, then optimizing that

[00:19:26] view should be of utmost importance over optimizing or polishing a view that they

[00:19:32] only use a fraction of the time. Let’s say, you know, 0.1% of the time. How much more should we

[00:19:38] be focusing on that primary view, that utility of the 90% view is so much more important in

[00:19:46] terms of the overall effect. Now, am I saying that you should just totally forget the small

[00:19:52] stuff? Absolutely not. But you should be prioritizing the big stuff before the small

[00:19:58] stuff. And this really generalizes to your life too, right? This is something that you can apply

[00:20:04] as a life philosophy. You can get the most important things done first. And if you don’t

[00:20:10] have clarity on what the most important thing is, then that is the most urgent task that you’re

[00:20:16] you have right this moment. You should be able to pull out a notebook and I challenge you to do

[00:20:20] this. Pull out a notebook and write down today’s most important thing. This is a good practice to

[00:20:27] get into every single day. And you should be able to answer that question. So thank you so much for

[00:20:32] listening to today’s episode, the first three by three episode for this week and the first three

[00:20:38] by three week that we’ve had. I hope that you enjoy this particular type of episode. If you

[00:20:45] are enjoying this, if you

[00:20:46] want me to do more three by three episodes, please send me an email. You can email me at

[00:20:51] developer T at Gmail. Of course, you can also reach me on Twitter at at developer T or at

[00:20:57] Jay Cottrell and let me know that you’re that you’re enjoying these particular types of episodes.

[00:21:03] Thank you again to Linode for making today’s episode happen. If you are a developer and

[00:21:08] you’re looking for a Linux service provider, you can stop looking head over to spec.fm slash Linode.

[00:21:14] They’re going to give you a $20 bill.

[00:21:16] Well, at least it’s $20 worth of credit on their services. Thank you so much for listening. Make

[00:21:21] sure you rate and subscribe to this podcast that helps us reach more developers. And if you believe

[00:21:28] in the mission, you can become a part of the mission of helping other developers, driven

[00:21:33] developers, just like you go and make a positive impact on the world by becoming better at what

[00:21:40] you do. Thank you so much for listening. And until next time, enjoy your tea.

[00:21:46] Thank you.

Visão de gráfico