Vox

Leitura de 14 min

When (Not) To Listen To Advice

Summary

The episode begins by asking listeners to recall the best advice they’ve ever received and consider whether it remains relevant to their current life and work. The host, Jonathan Cottrell, argues that advice is almost always context-dependent. We often carry advice from early in our careers, codify it into best practices, and apply it universally, forgetting the original context in which it was formed.

A core example discussed is the principle of writing maintainable code. While generally good, the host explains that in contexts where code will be used once and discarded, the cost of writing maintainable code may outweigh the benefits. The advice’s core value isn’t challenged, but its applicability is shown to be situational. This illustrates that no single piece of advice in software development is universally applicable.

The host encourages developers to identify their own assumptions when starting a project. He shares a personal experience where he assumed a product needed to be a profit center, but it was actually intended to improve customer experience for an established company. This mismatch meant that certain advice about avoiding complexity didn’t apply in the same way. Unchecked assumptions are identified as a common source of costly mistakes like over-optimization.

Finally, the episode frames upcoming discussions about anti-patterns and best practices as assuming a common professional context: working for a company where code quality matters because it will be iterated upon and contributes to profitability. The host acknowledges this is a specific, though common, context. The homework is to simply identify three assumptions you make in your work today, recognizing them as unvalidated beliefs that shape how you apply past advice.

Recommendations

Tools

  • Linode — A sponsor providing Linux cloud servers starting at 20 credit for listeners using a specific code.

Topic Timeline

  • 00:00:00 — Introduction to the nature of advice — The host asks listeners to recall the best advice they’ve received and consider its relevance to their current life and career. He introduces the episode’s theme: examining when advice is applicable, noting that advice is often context-dependent and its relevance changes over time, from our teenage years to a decade in the future.
  • 00:01:54 — Defining advice and its lifecycle — Advice is defined as a suggested belief or action to achieve an ideal state. The host explains that developers often carry advice from early in their careers, codify it, and it evolves into a best practice. Over time, the original context for that advice is lost, yet we continue to apply it as a universal rule, even though no advice in software development is truly universal.
  • 00:07:03 — Example: The context of maintainable code — Using the principle of writing maintainable code as an example, the host illustrates that while it is generally good advice, it is not always the best choice. In contexts where code is disposable or will never be touched again, the extra cost of writing maintainable code may be wasteful. The core value of the advice isn’t negated, but its practical application depends on the situation.
  • 00:09:13 — The role of personal assumptions — The host shares a personal story where he assumed a product needed to be profitable, but it was actually a customer experience tool for an established company. This mismatch meant standard advice about managing complexity didn’t apply in the same way. He stresses that we bring assumptions into projects, and applying past advice without validating those assumptions can lead to mistakes like over-optimization.
  • 00:11:03 — Framing future advice and homework — The host clarifies that upcoming episodes on patterns and anti-patterns will assume a common professional context: working on code that will be iterated upon for a company where quality matters. He acknowledges this is a specific context. The episode’s homework is to identify three assumptions you make in your work today, simply recognizing them as unvalidated beliefs that influence how you apply advice.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2018-09-24T09:00:00Z
  • Duration: 00:12:59

References

Podcast Info

Transcript

[00:00:00] What is the best advice that you’ve ever received?

[00:00:08] Perhaps the advice was about something in your career or something totally unrelated.

[00:00:14] I want you to think about that advice and then I want you to think about some of the

[00:00:19] things that you’ve heard on this podcast or in your career about what it means to

[00:00:24] be a great developer.

[00:00:26] And indeed we’ve talked about this subject at length, in fact we had multiple episodes

[00:00:31] where we identified ways of thinking that a great developer adopts.

[00:00:37] I want you to think about that advice as it relates to your life today, as it relates

[00:00:43] to whatever you’re doing today.

[00:00:47] Is it still relevant?

[00:00:49] There’s a high chance that it is, especially if you got the advice sort of recently.

[00:00:55] And because most people are going to recall fairly recent events, it makes sense that

[00:01:00] the advice would be relevant.

[00:01:01] But imagine if you were to rewind to your teenage years or perhaps even younger in

[00:01:07] grade school years and you tried to apply the same advice.

[00:01:12] Would it be relevant then?

[00:01:15] What about relevance for 10 years from now?

[00:01:21] When is that advice good?

[00:01:24] That’s what we’re talking about on today’s episode as kind of a primer for upcoming episodes

[00:01:29] where we give advice and I want to set the stage for how you should be listening to

[00:01:36] advice in today’s episode.

[00:01:38] My name is Jonathan Cottrell and you’re listening to Developer Tea.

[00:01:42] My goal in this show is to help driven developers like you connect to your career

[00:01:45] purpose so you can do better work and have a positive influence on the people

[00:01:50] around you.

[00:01:51] And here’s the thing about advice.

[00:01:54] Advice is almost always context dependent and in fact you could argue that it is always

[00:02:02] context dependent and unfortunately very often we hold on to advice.

[00:02:08] Now of course advice that people give you over the course of your career should be

[00:02:14] listened to and judged and managed, but how do you know when to let advice go?

[00:02:24] Let me use a different word because we’re using the word advice a lot.

[00:02:27] What does advice actually mean?

[00:02:29] Well it’s someone telling you a way or a belief that you can adopt and perhaps a

[00:02:38] resulting action that you may be able to take in order to achieve some ideal state.

[00:02:45] Whether that’s an internal state or maybe it’s something external to you.

[00:02:52] State in your career for example.

[00:02:55] Now that’s a very broad way of putting it right?

[00:02:57] We have someone coming along in our lives or maybe it’s a book that we read or in

[00:03:04] this case a podcast that we listen to telling us how we should see things.

[00:03:09] How should we behave in a given circumstance?

[00:03:14] And so what makes that advice reliable?

[00:03:17] What makes it applicable?

[00:03:20] The reality for most developers is that we carry advice that we received perhaps early

[00:03:26] in our careers and we hold on to it and we use it over and over and over.

[00:03:33] And eventually this advice that we receive we codify it, we turn it into something

[00:03:38] more than just one person’s suggestion.

[00:03:43] Enough people adopting this suggestion we turn it into something like a best practice.

[00:03:50] And then the best practice becomes the way to do things.

[00:03:55] We all agree on this way of doing things.

[00:03:58] And eventually the context where those suggestions were originally kind of formed, the context

[00:04:06] is no longer available for us to judge those suggestions by.

[00:04:12] Suggestions that have done a lot of good for developers in helping them achieve

[00:04:16] what they were trying to achieve like do not repeat yourself or all of the many principles

[00:04:22] that great developers who have come before me have helped establish.

[00:04:27] These things that we kind of all generally agree on these patterns of software development

[00:04:33] and even anti-patterns, ways of not doing things.

[00:04:38] And these are some of the things that we want to talk about on the show because

[00:04:42] As it turns out, they are quite useful and useful in many different contexts.

[00:04:48] But the truth is that there is no single piece of advice that you will receive, especially

[00:04:54] in the context of software development, that is universally applicable.

[00:04:59] We’re going to talk about how to hear and apply advice right after we talk about

[00:05:04] today’s sponsor, Linode.

[00:05:07] Today’s episode is sponsored by Linode.

[00:05:10] Linode is a longtime sponsor of developer T and they keep coming back because Linode

[00:05:15] invests in the developer community.

[00:05:18] Linode is not only going to continue sponsoring developer T for more episodes, but they’re

[00:05:23] also giving developer T listeners credit to use on their services.

[00:05:28] What does Linode provide?

[00:05:29] They provide Linux in the cloud at the industry leading price point.

[00:05:34] That’s starting at $5 a month.

[00:05:36] You can get a gigabyte of RAM on an all SSD server with Linode.

[00:05:41] You can get started in just a few minutes.

[00:05:43] Linode has things like 24-7 customer support and a wide range of open source projects

[00:05:50] that Linode supports to build their services.

[00:05:54] So it’s not just a black box of services, it’s actually developers on the other end

[00:06:00] of this that are working to make Linode better for you, developers.

[00:06:05] Go and check it out.

[00:06:06] Head over to Linode.com slash developer T to get started today.

[00:06:11] Use the code developer T 2018 at checkout for $20 worth of credit.

[00:06:17] By the way, we mentioned that 20 worth of credit can get

[00:06:21] you four months on Linode services.

[00:06:24] Head over to Linode.com slash developer T to get started.

[00:06:27] Thank you again to Linode for sponsoring today’s episode of developer T.

[00:06:32] So we’re talking about whether or not you can trust advice.

[00:06:35] And we’ve already kind of proven, hopefully you recalled some advice that wouldn’t

[00:06:39] necessarily be applicable in your teenage years or your young life in your grade school

[00:06:46] years or perhaps even 10 years from today, that advice may not apply at all.

[00:06:51] And so it’s important to understand that advice is given within a context.

[00:06:56] And we should be able to realize that this is true for all of our best practices

[00:07:01] as developers.

[00:07:03] A very good example of this is writing maintainable code.

[00:07:08] Now there’s some really good argumentation about this, some great conversations online,

[00:07:13] civil disagreements between people about whether or not it makes sense to always

[00:07:18] write maintainable code.

[00:07:20] And the short theory of the side that says that it’s not always necessary to

[00:07:25] write maintainable code and in fact may even be wasteful to write maintainable

[00:07:29] code every single time.

[00:07:32] The theory essentially says that if you know for a fact that this code is going

[00:07:38] to be disposed of, it will be used once and then gotten rid of, or for

[00:07:44] whatever reason it’s going to be locked and never touched again, then the

[00:07:47] point of writing maintainable code no longer exists.

[00:07:52] And maintainable code costs more to develop than non-maintainable code.

[00:07:59] And you’ll notice here that the core concept that the advice puts forward,

[00:08:04] that maintainable code is good, is not being challenged by this new context.

[00:08:12] Maintainable code is good, however, in some contexts, it is also too expensive.

[00:08:20] In other words, maintainable code may still continue to be a good thing, but

[00:08:27] it’s also not necessarily the best choice in this particular context.

[00:08:33] Naturally, our brains don’t really like to think about our beliefs in this

[00:08:38] manner because it requires us to re-evaluate what we believe is the

[00:08:44] right course of action.

[00:08:45] And so when we walk into a given project, we bring with us our

[00:08:50] experiences and therefore our assumptions about the world and about

[00:08:56] this project.

[00:08:58] And as we move forward into a project and we apply advice that we’ve

[00:09:02] received in the past, very often we do so through the lens of some

[00:09:08] assumption.

[00:09:09] One of these assumptions that I personally have experienced in the past

[00:09:13] was the assumption that the thing that I was making needed to be

[00:09:18] profitable, that the users who came to use this product would find it

[00:09:25] useful enough to pay for it.

[00:09:28] Now, this seems like a reasonable assumption, especially if you worked

[00:09:32] in a startup world or if you worked on a product for a young company

[00:09:36] and they’re trying to build a viable product.

[00:09:39] But in this particular case, I was working with an established

[00:09:42] company and they were developing a product that they wanted to provide

[00:09:47] to their existing customers purely as an improvement to their customer

[00:09:53] experience.

[00:09:55] The product was not intended to drive some major amount of revenue.

[00:09:59] Now, this was a counterintuitive thing to encounter as a developer

[00:10:03] because most of the time my assumptions don’t line up with that

[00:10:08] view.

[00:10:09] And so the advice of always looking for expensive black holes of

[00:10:15] complexity, for example, that may not necessarily apply in the same

[00:10:20] way in that kind of project.

[00:10:23] So it’s important to evaluate your context as you’re moving through.

[00:10:28] Ask yourself, what assumptions am I making?

[00:10:31] And therefore, what advice?

[00:10:34] What best practices?

[00:10:36] What am I bringing into this project that hasn’t explicitly

[00:10:40] been validated as necessary?

[00:10:44] This is truly the birthplace of so many costly mistakes that we

[00:10:48] make as developers, not as necessarily the birthplace of bugs

[00:10:54] that we bring into the software, but instead of things like over

[00:10:59] optimization.

[00:11:00] And so as we move into episodes where we talk about things like

[00:11:03] anti-patterns, I want you to understand that these episodes are

[00:11:09] intended to assume kind of an average context.

[00:11:15] That average context is that you’re working as a developer in a

[00:11:19] professional atmosphere for a company that relies on whatever

[00:11:24] you’re doing as some kind of profit center.

[00:11:26] In other words, the code that you are writing will be iterated

[00:11:30] on, and it matters to the company that the code is high quality.

[00:11:36] This is a specific context.

[00:11:38] It’s a very common context, but it’s a specific context that

[00:11:43] some of the things that we may discuss, if we were not in that

[00:11:47] same context, they may not apply in the same way.

[00:11:50] But hopefully, as you’ll see, there are some things that really

[00:11:55] apply quite broadly that we’re going to discuss in these

[00:11:58] episodes.

[00:11:59] So a very simple takeaway, a piece of homework for today’s

[00:12:02] episode, as you work today, identify maybe a list of three

[00:12:08] assumptions that you make.

[00:12:11] Don’t necessarily have to change them.

[00:12:13] Don’t necessarily have to do anything different.

[00:12:15] Just identify them as assumptions, things that somebody

[00:12:19] hasn’t necessarily told you about that project, but that you

[00:12:24] went ahead and kind of filled in the blank.

[00:12:27] Thank you so much for listening to today’s episode.

[00:12:29] Thank you again to Linode for sponsoring today’s episode with

[00:12:32] Linode.

[00:12:33] You can get an SSD server in the cloud for only $5 a month,

[00:12:38] and you’re going to get $20 worth of credit just for being

[00:12:42] a developer T listener.

[00:12:43] Head over to lino.com slash developer T, and use the

[00:12:47] code developerT2018 at checkout.

[00:12:50] Thank you so much for listening, and until next time,

[00:12:52] enjoy your tea.

Visão de gráfico