Vox

Leitura de 27 min

3X3: Fallacies to Avoid as a Developer

Summary

In this episode of Developer Tea, host Jonathan Cottrell explores three cognitive fallacies that commonly affect developers and offers practical strategies to counteract them.

The first fallacy is the belief that we will remember everything we do today. Cottrell explains that our brains naturally forget most information within 48 hours, retaining only about 40% of what we learn. This has significant implications for software development, as developers often return to code they wrote days or weeks earlier and struggle to recall their reasoning. The solution is to write code as if you’re handing it off to a stranger—improving documentation, naming conventions, testing, and overall design quality to compensate for inevitable memory decay.

The second fallacy is the planning fallacy—the belief that with enough effort, we can accurately estimate large projects. Cottrell cites studies showing that humans consistently underestimate project timelines, with the average completion time often exceeding even worst-case estimates. He references research including the Chaos Manifesto and a 1994 study where psychology students underestimated their thesis completion times by significant margins. To combat this, Cottrell recommends breaking projects into the smallest estimable components and consciously adding buffer time, recognizing that optimism and wishful thinking often distort our predictions.

The third fallacy is the belief that there is a single “best way” to do something. Cottrell argues that in a constantly changing environment with multiple competing priorities (technical considerations, design requirements, business needs), the optimal approach is rarely fixed. Instead of seeking perfection, developers should aim to balance various motivations and create effective solutions within real-world constraints. This requires consolidating different perspectives rather than dismissing them, and developing decision-making rubrics that account for multiple factors.

Throughout the episode, Cottrell emphasizes that awareness of these fallacies can help developers make better decisions, write more maintainable code, and approach projects with greater realism and effectiveness.

Recommendations

Concepts

  • Planning Fallacy — Discovered by Daniel Kahneman and Amos Tversky, this cognitive bias describes the tendency to underestimate task completion times despite past experience suggesting otherwise.
  • Forgetting Curve — The pattern of memory decay where about 60% of information is forgotten within 48 hours of learning, with only 40% retained without reinforcement.

Studies

  • Chaos Manifesto 2012 — Cited as showing that less than a third of IT projects finish on time and on budget, with most having significant cost and schedule overruns.
  • Harvard Business Review study on IT projects — Analyzed over 1400 IT projects and found that 83% had cost overruns averaging 200% and schedule overruns of nearly 70%.
  • 1994 study by Buehler, Griffin, and Ross — Psychology students underestimated their senior thesis completion times significantly, with average actual completion taking nearly twice as long as their best-case estimates.

Topic Timeline

  • 00:00:00 — Introduction to cognitive biases and fallacies in development — Jonathan Cottrell introduces the episode’s theme: exploring cognitive biases and fallacies that affect developers. He explains that these mental patterns shape our thinking, sometimes in flawed ways, and emphasizes that the goal is not to create fear but to equip developers with awareness. The episode will focus on three specific fallacies common in software development.
  • 00:03:27 — First fallacy: Believing you will remember everything — Cottrell presents the first fallacy: the belief that we will remember everything we do today. He explains that memory retention drops significantly within 48 hours, with only about 40% of information retained. Our brains prioritize survival and other functions over detailed memory. The practical implication is that developers should write code as if for a future stranger—improving documentation, naming, and design to compensate for inevitable forgetting.
  • 00:12:03 — Second fallacy: Believing we can accurately estimate large projects — The second fallacy is the belief that with enough effort, we can accurately estimate large projects. Cottrell cites studies showing most projects exceed budgets and timelines, with the Chaos Manifesto indicating less than a third finish on time and budget. He references a 1994 study where students underestimated thesis completion times by wide margins. Causes include blind optimism, wishful thinking, and self-serving bias. The solution is to break projects into smaller estimable components and add buffer time.
  • 00:21:17 — Third fallacy: Believing there is one definite best way — The third fallacy is the belief that there is a single “best way” to do something. Cottrell argues that in a constantly changing environment with multiple competing priorities, optimal solutions are rarely fixed. Developers must balance technical considerations, design requirements, business needs, and other factors. Rather than seeking perfection, they should consolidate competing motivations and find effective balances, sometimes prioritizing certain factors or finding creative compromises.
  • 00:24:26 — Conclusion and practical takeaways — Cottrell summarizes the three fallacies and their importance for developers. He emphasizes that awareness of these cognitive pitfalls can prevent missteps and improve decision-making. The episode concludes with encouragement to apply these insights practically and to subscribe to Developer Tea for more content that challenges developers to think deeply about their work.

Episode Info

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

References

Podcast Info

Transcript

[00:00:00] What if there were things that you act on and things that you believe, whether explicitly

[00:00:09] or implicitly, that just simply weren’t true?

[00:00:14] This is actually a reality for pretty much everyone, and that’s a topic we like to discuss

[00:00:20] on the show, the idea of fallacies or biases.

[00:00:24] These are things that change the way that we think or mold the way that we think so

[00:00:29] that we have our own particular viewpoints, and sometimes those viewpoints are flawed

[00:00:35] in some way.

[00:00:36] In today’s episode, we’re going to talk about three of those biases or fallacies that you

[00:00:42] need to kind of protect yourself from as a developer.

[00:00:45] Our goal on this show is not to create fear, but instead to equip you as a developer to

[00:00:51] be able to face this kind of stuff.

[00:00:53] My name is Jonathan Cottrell.

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

[00:00:57] My goal on this show, my big goal on this show…

[00:00:59] is to help driven developers connect to their career purpose so they can do better work

[00:01:05] and have a positive influence on the people around them.

[00:01:09] And of course, for you to connect to what you want, or for you to connect to a purpose,

[00:01:16] an underlying kind of methodology of thinking and believing in values that you have about

[00:01:23] the world and beliefs that you hold that drive your actions, for you to be able to do that,

[00:01:28] you have to…

[00:01:29] You have to understand the way that your mind works.

[00:01:33] You have to know what you believe.

[00:01:34] You have to actually be able to articulate it.

[00:01:37] Or if you can’t articulate every single thing that you believe, because that would be incredibly

[00:01:41] difficult, you do need to be able to understand some of the areas that may be detrimental

[00:01:48] for you to not have control over, or at least have awareness about.

[00:01:53] This isn’t the first time we’ve talked about biases or fallacies on this show.

[00:01:58] You know, this is actually a very…

[00:01:59] This is a very common topic that comes up pretty much in every other major topic.

[00:02:04] This is embedded in it, because we aren’t really talking about, you know, some specific

[00:02:09] thing that is quarantined to one area of your job.

[00:02:13] This is really talking about a high-level perception, how you see the world, how you

[00:02:19] can actually decode the things that are happening around you.

[00:02:21] But we are going to talk about specific things today, three specific fallacies that I don’t

[00:02:28] want you to fall prey to.

[00:02:29] That are very common for developers to fall prey to.

[00:02:32] So we’re going to get into that in just a minute.

[00:02:34] Today’s episode is a three-by-three episode.

[00:02:38] This week, we’re doing the three-by-three episodes.

[00:02:41] These are three practical takeaways in each episode for a week.

[00:02:45] And the reason that we’re doing this is because, quite simply, I found that these episodes

[00:02:50] are particularly popular and impactful to this audience.

[00:02:55] And I want you to have these practical takeaways.

[00:02:57] I want you to be able to apply this stuff.

[00:02:59] On a day-to-day basis, you know, the goal of the show is not to be heady.

[00:03:04] It’s not to disconnect from reality.

[00:03:07] It certainly isn’t to only discuss philosophy.

[00:03:10] We will discuss things like philosophy on this show.

[00:03:13] That’s totally on the table.

[00:03:15] But we’re only going to discuss it if we can then turn around and act on it.

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

[00:03:22] The three-by-three episode, three fallacies that I want you to avoid as a developer.

[00:03:27] The first one.

[00:03:28] This is a very strong fallacy.

[00:03:31] Everyone goes through this.

[00:03:33] We believe that the fallacy is you will remember everything you did today.

[00:03:39] You will remember everything you did today in the future.

[00:03:44] Perhaps another version of this fallacy is I will remember better as I go along.

[00:03:50] I’m going to remember today better than I remembered yesterday.

[00:03:54] That my power of memory is somehow getting better over time.

[00:03:58] And that even though I can’t remember my childhood and I can’t remember, you know, five years ago very well,

[00:04:04] it’s not very clear to me that actually, you know, today is pretty clear.

[00:04:09] And I’m not going to forget what’s happening today.

[00:04:11] And this is totally incorrect.

[00:04:13] This has been studied many times.

[00:04:16] More specifically with relation to learning, but the same insights can apply in many other areas as well.

[00:04:24] The studies show that the forgetfulness curve looks something like this.

[00:04:28] When you get new information, let’s say when you’re reading a book or maybe you’re listening to this podcast,

[00:04:35] even when you are intentionally engaging that information in about two days,

[00:04:41] the course of 48 hours, you will have forgotten over half of it.

[00:04:46] The number is about 40% that you’re going to retain after two days.

[00:04:50] Furthermore, your brain is selective about what it remembers even in the short term.

[00:04:55] For example, even though this podcast has only been playing,

[00:04:58] for a few short minutes, could you recite every word of what I’ve said without re-listening and writing it down?

[00:05:06] In fact, even if you did this 20 or 30 times, if you re-read or re-listened to everything that I’ve said,

[00:05:13] to recite it word for word would be a huge difficult task for your brain to accomplish.

[00:05:20] And the point of what I’m saying here is not to, you know, lead you down the road of trying to increase your memory ability,

[00:05:26] but instead to recognize that you’re not going to forget.

[00:05:28] We need to recognize that memory is not nearly as simple as we may intuitively believe that it is.

[00:05:34] The salience and presentness of the information that we have in front of us makes it feel like we will never forget it.

[00:05:43] It’s very easy to believe that the feelings and the emotions and all of the present nature of things,

[00:05:53] you know, you’re looking around you, you can see, you can feel, you know exactly what’s happening.

[00:05:58] It’s all happening in real time.

[00:05:59] So it’s hard to believe that you’re probably going to forget it.

[00:06:03] And it may even feel a little bit alarming or negative that you would somehow lose sight of these moment-to-moment interactions that you have with the world.

[00:06:14] But I want to encourage you, don’t let this cause you anxiety.

[00:06:17] This is actually how our brains are.

[00:06:19] They’re engineered this way.

[00:06:21] They work this way.

[00:06:22] Our brains are prioritizing other things.

[00:06:25] They’re prioritizing other things.

[00:06:27] They’re not using their energy and their space to remember things that are basically useless, right?

[00:06:34] And it’s very difficult to signal to your brain what is and what isn’t useful.

[00:06:38] Our brains are prioritizing other things like survival and food and tons of other things that we can’t really explicitly nail down exactly how it’s working.

[00:06:48] There’s not an algorithm that we can go and read that explains how the brain makes these decisions.

[00:06:53] But the information our brains is collecting and then associating,

[00:06:57] this is one of the major mysteries of the way that we think, the way that we see the world.

[00:07:04] And so we can’t look up what happened, you know, on a random Tuesday afternoon four years ago without the assistance of some recording mechanism, maybe a computer, right?

[00:07:14] Or a diary, for example.

[00:07:16] Keeping history is a difficult process for this very reason.

[00:07:19] And because our brains tend to forget most of what happens to us, not just some of it, most of what happens to us,

[00:07:26] our brains tend to forget and instead adapt to the impressions of what happens to us,

[00:07:32] recalling information based on association and context when it is most relevant.

[00:07:38] So why does this matter?

[00:07:39] Why does our forgetfulness matter?

[00:07:42] First of all, it’s important to remember this just in general,

[00:07:45] because a lot of the experiences you’re going to have, you know, a lot of the social experiences,

[00:07:51] a lot of their relational experiences, they’re going to rely on memory of some sort,

[00:07:56] or you’re going to have some kind of intuition based on your memory that may not be shared with another person.

[00:08:02] So it’s important to have that understanding that your memory is really kind of a complicated machine that you don’t really see the source code of, right?

[00:08:11] But the other piece of this is, you know, if this is true, if we forget most of what we’ve done,

[00:08:16] if we forget most of our experiences, then we shouldn’t write our code as if we will understand it implicitly in the future.

[00:08:25] You know, you should write your code for other people to read it.

[00:08:29] But sometimes that other person isn’t actually another person per se, but it’s simply you in the future, right?

[00:08:38] Write it as if you are going to hand it off to a stranger who knows nothing about the code at all.

[00:08:44] And this will lead to better documentation, better naming, more thoughtful design all around.

[00:08:49] But it will also allow you in the future as your memory, unfortunately,

[00:08:55] is not going to hold all this code in mind.

[00:08:58] And it’s not really unfortunate, is it?

[00:08:59] Because our brains are prioritizing other things.

[00:09:03] Instead of forcing your brain to try to remember something that it is categorized as unimportant,

[00:09:09] instead what you can do is create better documentation, right?

[00:09:14] You can create the code as if you’re writing it for another person to work on with you.

[00:09:19] Now, how often have you returned to code and you’ve asked this very simple question,

[00:09:24] right?

[00:09:25] It’s five words long.

[00:09:26] Why did I write this?

[00:09:30] Why did I write this?

[00:09:31] I’ve asked this so many times.

[00:09:33] I can come back to a project and I can understand the general structure, but then suddenly I run into code that doesn’t have an explanation.

[00:09:42] And it creates some anxiety around changing that code, right?

[00:09:45] Especially if I didn’t write tests and tests, for example, are another way to future proof.

[00:09:52] If you keep a test suite and you keep it up to date,

[00:09:54] then your future self will thank you because now you have a kind of a way of saying here is why that piece of code exists.

[00:10:02] If I remove that piece of code, then this test starts failing, right?

[00:10:07] So documentation, testing, naming, the overall design, the intentionality of what you do,

[00:10:13] the quality of your work as a developer is going to go up if you internalize the concept that you’re probably going to forget.

[00:10:24] You’re not going to be able to hold in memory all of the reasons why you designed it that way.

[00:10:29] You’re not going to be able to recall the entire application structure even as soon as just a few days from now.

[00:10:38] So make sure that you are building as if you are building for a stranger, someone who is not watching over your shoulder, who isn’t in your head.

[00:10:48] Someone else is going to be collaborating with you on that code.

[00:10:53] Of course, the side benefit is…

[00:10:54] Because if someone else does come along, right?

[00:10:57] If another developer comes along to actually collaborate with you or if someone else picks up the project and you move on to something else,

[00:11:05] well, you’re already prepared for that.

[00:11:06] You don’t have much of a crossover in training.

[00:11:09] You don’t have to rely on person-to-person communication in order to make that transition a little bit smoother.

[00:11:18] Of course, everything is in moderation.

[00:11:21] You’re probably going to still have to do some person-to-person.

[00:11:24] You’re probably still going to have some issues with remembering, even with good documentation, good design.

[00:11:31] There’s no silver bullet answer, unfortunately.

[00:11:34] And this stuff is hard.

[00:11:36] Being a software developer is hard.

[00:11:37] That’s why we can have so many episodes of Developer Tea about subjects like this, and it still isn’t answering every single question.

[00:11:45] There’s always going to be more questions and more problems to solve, but taking steps towards solving those problems.

[00:11:52] That’s the key.

[00:11:53] That’s kind of the key takeaway.

[00:11:54] Anyway, let’s move on to the second fallacy, the second fallacy that I hope you can prevent from falling victim to.

[00:12:03] You may have already fallen victim to these fallacies.

[00:12:07] It’s very easy to believe these things.

[00:12:09] So number two, if we try hard enough, we can estimate large projects or tasks.

[00:12:16] If we try hard enough, if we try long enough, we can estimate.

[00:12:20] We can accurately estimate large projects and tasks.

[00:12:24] Unfortunately, the information that we have available, the studies that have been done on project completion, project success, estimation, pretty much unilaterally agree that estimation is something that humans are very bad at doing.

[00:12:42] And this gets worse as the thing that you are trying to estimate gets larger.

[00:12:47] More specifically, if you are trying to estimate how much energy is going to be needed to accomplish a task.

[00:12:54] And in particular, a complex task that hasn’t been accomplished before.

[00:13:00] If you’re in that scenario and you’re trying to estimate a large task, a large complex task that’s never been done before, you’re probably going to be wrong.

[00:13:10] And you’re probably going to underestimate.

[00:13:13] According to most data, in fact, there is a chaos manifesto.

[00:13:18] This is found on the version one site.

[00:13:20] If you’re looking for it, probably search chaos manifesto 2012.

[00:13:24] But less than a third of projects finished on time and on budget in 2012.

[00:13:30] According to the chaos manifesto, a study published in the Harvard Business Review, which analyzed over 1400 IT projects, found that all but one in six projects, all but one in six projects.

[00:13:44] That’s 83 percent, actually more than 83 percent.

[00:13:49] Eighty three percent of projects have cost overrun of 200.

[00:13:54] On average, and a schedule overrun of almost 70 percent.

[00:14:00] And this concept is known as the planning fallacy.

[00:14:02] This is a fallacy that was discovered by Daniel Kahneman and Amos Tversky on the Wikipedia page.

[00:14:09] You can find a really good study that was done by Roger Buehler, Dale Griffin and Michael Ross back in 1994.

[00:14:17] And what’s that?

[00:14:18] What this study found in 1994, 37 psychology students were asked to estimate how long it would take for a project to be completed.

[00:14:24] How long it would take to finish their senior theses.

[00:14:27] The average estimate was 33.9 days.

[00:14:31] Right.

[00:14:31] Put this in your mind.

[00:14:32] Thirty three point nine days.

[00:14:34] About a month.

[00:14:35] They also estimated how long it would take if everything went as well as it possibly could.

[00:14:41] And that average was about twenty seven point four days.

[00:14:44] And then if everything went as poorly as it possibly could.

[00:14:48] Averaging about forty eight point six days.

[00:14:50] All right.

[00:14:51] So we’re looking at a range of about.

[00:14:54] Twenty seven to forty eight.

[00:14:56] We’ll we’ll say, you know, that’s almost a one hundred percent increase from the best to the worst case scenario.

[00:15:02] Now, the average actual completion time for for these senior theses.

[00:15:09] Again, the average estimate was thirty three point nine.

[00:15:12] In the worst case scenario, the average was forty eight point six.

[00:15:15] The average actual completion was fifty five point five, which is greater than the average estimate for the worst case scenario.

[00:15:24] In other words, things went beyond the worst case scenario on average.

[00:15:30] This isn’t for a few of the students, but on average and only about 30 percent of the students completed their thesis in the amount of time they predicted.

[00:15:39] But perhaps most alarmingly here is the the jump from their predicted best case scenario to the average outcome.

[00:15:48] The predicted best case scenario was around twenty seven point four days.

[00:15:53] And the average completion time is over twice that.

[00:15:57] This is a huge, huge fallacy that we very often become victims of in good intentions.

[00:16:06] And this is such a problem in development, especially because so much of what we do is still in the unknown category.

[00:16:14] Now, there are many theories as to why this occurs, why humans are bad at estimating.

[00:16:19] More specifically, we’re bad in the in the worst direction.

[00:16:22] We underestimate.

[00:16:23] We underestimate what it’s going to take, which means that we end up in a costly scenario.

[00:16:28] Very often, overestimation is actually a better idea.

[00:16:33] It’s a better call to overestimate.

[00:16:35] It would be a better outcome if we overestimated and then had the extra time or the extra resources available to reallocate to other places.

[00:16:45] But unfortunately, this isn’t the case.

[00:16:47] So theories as to why this occurs.

[00:16:49] The first theory is blind optimism.

[00:16:52] This is just simply.

[00:16:53] Not thinking about everything that could go wrong.

[00:16:57] We aren’t thinking about the variety of factors that we can’t predict.

[00:17:01] We can’t predict sickness.

[00:17:02] For example, we can’t predict accurately how good we’re going to feel on a given day, how energetic we’re going to feel.

[00:17:10] We can’t predict accurately how often we’re going to be interrupted.

[00:17:13] There’s so many other things that we can’t predict.

[00:17:15] And this is not even getting into the fact that we can’t predict what kind of technological hurdles we’re going to face.

[00:17:23] Incompatible.

[00:17:23] Even changes in the business market that we have absolutely no control over.

[00:17:29] So blind optimism.

[00:17:30] This is a huge issue.

[00:17:32] Number two, the next theory is wishful thinking.

[00:17:35] We are eternally optimistic as developers, especially when we see a relatively clear path.

[00:17:43] When we feel that we have certainty about how we would go about attacking a particular problem, we have a sense of positive kind of optimism, wishful thinking.

[00:17:53] And that encourages us that we’re going to be able to do this particular task in a shorter amount of time than we actually will.

[00:18:01] Because we can see the finish line, we have a hard time judging how far away it is.

[00:18:07] The next theory as to why we are bad estimators is the self-serving bias.

[00:18:14] So if we’re thinking in terms of learning, we can look back into our past and we can kind of predict what’s going to happen in the future based on what we’ve done.

[00:18:22] We can predict what’s going to happen in the future based on what we’ve done.

[00:18:23] We can predict what’s going to happen in the future based on our past.

[00:18:24] And you would think that this would help us become better estimators.

[00:18:28] But for some people, it actually makes it worse.

[00:18:30] Because things that went well in the past, we tend to apply that credit to ourselves.

[00:18:38] And things that went poorly, we tend to blame other people.

[00:18:42] So what this means is we kind of cherry pick from our past experiences to build the picture of our own ability.

[00:18:51] And we feel good about ourselves.

[00:18:53] And we feel good about our future abilities because we’ve cherry picked the good things from the past.

[00:18:58] So there’s plenty of other theories as to why we are bad estimators.

[00:19:01] We can’t get to all of them, obviously, in one episode.

[00:19:04] Because this, again, this study has been going on for a long time.

[00:19:08] But I do want to give you a takeaway from this fact that we are kind of bad estimators as a general rule.

[00:19:15] So when possible, we should reduce every estimate to the smallest possible item to be estimated.

[00:19:22] In other words, break up.

[00:19:23] Your estimates into the smallest things that you can estimate.

[00:19:26] We’re much better at estimating how long it’s going to take to walk across the room than we are at estimating how long it would take to walk across the city or even across the neighborhood.

[00:19:39] The same is true in most things.

[00:19:41] If it’s smaller, it’s going to be easier to size up.

[00:19:45] So break it down into the smallest thing.

[00:19:47] Ask yourself in the worst case scenario, how long could this take?

[00:19:51] And then add more to that.

[00:19:53] Right.

[00:19:54] Recognize that you cannot, you know, reasonably evaluate the things that you don’t yet know are going to happen.

[00:20:02] Evaluate the real problem with estimating more realistically.

[00:20:05] The driver here is often fear of losing a client or a promotion or the approval of peers.

[00:20:12] Now, I have a personal theory on this.

[00:20:14] It’s kind of a bonus theory here.

[00:20:16] People want the gratifying effect of an on-time estimate today.

[00:20:22] We want to feel.

[00:20:23] The sense of accomplishment.

[00:20:26] Today, by estimating that we could finish something in a certain amount of time that satisfies the requirements of a given project or satisfies the desires of a client or a boss or even a co-worker.

[00:20:41] We we get that gratifying effect by making them happy with our estimate.

[00:20:46] And we fail to measure the future negative effects of an overtime or over budget reality.

[00:20:53] Down the road to that future pain is not a strong enough threat to avoid the gratification today.

[00:21:03] So this concept is, you know, it’s supported by some psychological theory, but certainly there haven’t been any studies done on it.

[00:21:11] It’s just a personal theory.

[00:21:12] OK, so we’re going to move on to our third fallacy that I want you to avoid as a developer.

[00:21:17] And that is there is a definite way, a definite best way to do something.

[00:21:22] Now, given.

[00:21:23] A infinitely small moment in time, there may be a single way to optimize for particular variables.

[00:21:33] Right.

[00:21:34] If you could stop time from moving on, if you could stop all change, all dynamic events from happening.

[00:21:41] And if you could control for every variable, then perhaps you could determine one best way.

[00:21:47] But the reality is far different from this.

[00:21:51] Everything around us is always changing.

[00:21:53] And it’s.

[00:21:53] Always evolving and transforming.

[00:21:55] Even we as humans are doing this.

[00:21:58] We’re growing.

[00:21:59] We’re being born and we’re dying.

[00:22:01] So this is at a at a fundamental level.

[00:22:04] Change is kind of the only constant.

[00:22:06] Right.

[00:22:06] We’ve heard this this quote before.

[00:22:09] And so the reality is there’s so many variables that the best decision in a given scenario may be changing instantaneously from one decision to another.

[00:22:18] Now, our jobs as developers is not to try to track this change.

[00:22:22] It’s not to find the absolute best way.

[00:22:26] It’s also not to find the best language or the best tool, the best framework.

[00:22:32] It’s not to find the best person to hire.

[00:22:35] Instead, it is to make the best of a situation with all of the things brought into consideration.

[00:22:43] Now, this balance is difficult to achieve, but it is the most important reality for developers to understand.

[00:22:49] It is extremely difficult to get this perspective.

[00:22:52] Without having other people who will help you to understand the different competing motivations, it’s easy as a developer, for example, to think that the technicalities of a platform are kind of the linchpin, the of utmost importance.

[00:23:09] And we also adopt various beliefs of parallel industries.

[00:23:12] For example, if we work heavily with visual designers, we may have a high level of importance that we place and a bias towards visual organization.

[00:23:22] And likewise, if we work with a marketing guru, then we might place a lot of emphasis on A-B testing or validation from day one, gathering data.

[00:23:32] If we work in a culture of agile practitioners, then we may lean towards the idea of MVP and constant iteration over grand design.

[00:23:41] In order to become better as a developer, you must be able to consolidate these competing motivations, not destroy the ones that you don’t personally find valuable.

[00:23:52] But consolidate the competing ones and find the most effective balance between them.

[00:23:56] Sometimes this means prioritizing those motivations so that when you’re faced with a decision that compromises between one or the other, you have a rubric for making that decision.

[00:24:06] Sometimes it means finding creative ways to satisfy a whole handful, a host of motivations.

[00:24:13] Sometimes it means re-evaluating your own motivations and recognizing how they affect the project as a whole.

[00:24:22] These are three fallacies that I think are super important for you to pay attention to as a developer.

[00:24:26] I hope that this episode has been enlightening, inspiring, and maybe it’s going to protect you a little bit from a misstep that you would have made otherwise.

[00:24:35] I hope that’s the case.

[00:24:36] I hope you’ve been challenged by this episode, and I hope you’ll listen to the other 3x3 episodes from this week.

[00:24:42] If you’re enjoying this podcast, make sure you subscribe in whatever podcasting app you use.

[00:24:47] That’s not for everyone.

[00:24:48] Not everybody needs to subscribe to this podcast.

[00:24:51] Only people who are interested in this podcast will be able to do so.

[00:24:52] Only people who are willing to think and be challenged while you’re listening to a podcast.

[00:24:56] This is not really a light listening kind of experience.

[00:25:00] We’re dealing with the things that we really need to deal with as developers.

[00:25:04] Thanks so much for listening, and until next time, enjoy your tea.

Visão de gráfico