Vox

Leitura de 15 min

Asking “Dumb” Questions

Summary

In this episode of Developer Tea, host Jonathan Cottrell explores the value of asking simple, fundamental questions that are often perceived as “dumb.” He argues that overcoming the fear of judgment and letting go of ego are essential for personal and professional growth as a developer.

Cottrell shares that his perspective comes from mentoring self-taught developers and his own experience, noting that everyone has blind spots. By asking basic questions—even internally—about concepts like JavaScript variable declarations or team terminology, developers can uncover gaps in their understanding and assumptions they didn’t realize they held.

The episode emphasizes that asking for clarity in collaborative settings can reveal whether terms are well-defined or just accepted without scrutiny, ultimately increasing collective knowledge. While this practice can feel uncomfortable, especially with long-used terms, the benefits of improved clarity and better work outcomes outweigh the initial awkwardness.

Cottrell encourages listeners to explain their reasoning for asking such questions and to foster environments where fundamental questioning is welcomed. He concludes by connecting this practice to the show’s broader theme of finding purpose and avoiding burnout through continuous learning and challenging assumptions.

Recommendations

Tools

  • Linode — A cloud hosting provider offering Linux servers starting at $5/month, with scalable hourly plans and 24/7 customer support. The host recommends it for developers needing reliable infrastructure.

Topic Timeline

  • 00:00:00 — Introduction to the value of simple questions — Jonathan introduces the episode’s theme: the best developers ask simple, supposedly “dumb” questions. He connects this to the show’s goal of helping developers find purpose and overcome ego, setting up a discussion on humility and learning.
  • 00:02:42 — Sponsor message from Linode — The host promotes Linode, a cloud hosting provider, highlighting their developer-friendly plans, 24/7 customer service, and scalable infrastructure. He offers a $20 credit for listeners via spec.fm with the code developerT2018.
  • 00:05:03 — Defining a ‘dumb’ question and self-taught blind spots — Cottrell defines a ‘dumb’ question as one about fundamentals you ‘should’ already know. He relates this to self-taught developers’ common blind spots and suggests using internal dialogue to question basic concepts in programming, like the difference between let and const in JavaScript.
  • 00:08:12 — Asking for clarity in collaborative work — The host advises asking for definitions of terms like ‘customers’ or ‘stakeholders’ in group settings. He explains this can reveal either that the group lacks clear definitions or provide you with new information, both of which increase understanding and improve collaborative outcomes.
  • 00:09:58 — Overcoming discomfort and the benefits of questioning — Cottrell acknowledges that asking fundamental questions feels unnatural and may invite judgment. He encourages explaining your reasoning and notes that once you experience the benefits of increased clarity and better work, the initial discomfort fades, and the practice becomes valuable.
  • 00:10:57 — Conclusion and call to action for listeners — Jonathan thanks listeners and the sponsor, Linode. He reflects on the podcast reaching over 500 episodes and asks listeners to support the show by subscribing and leaving reviews on iTunes to help reach more developers who could benefit from these ideas.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2018-02-26T10:00:00Z
  • Duration: 00:12:42

References

Podcast Info

Transcript

[00:00:00] you’ve heard the phrase there’s no such thing as a stupid question and unfortunately we tend to not

[00:00:11] practice this as truth we avoid asking questions that we feel will be judged for and this is

[00:00:19] something that’s really difficult to overcome because the reality is it’s very hard to not

[00:00:26] judge other people based on the questions that they ask but in today’s episode I’m going to

[00:00:31] present why I believe that the best developers ask the most simple and perhaps the dumbest

[00:00:40] supposedly the dumbest questions out of a given group and we’ll talk about why that actually

[00:00:46] leads them to a more enlightened state of development you’re listening to developer

[00:00:52] team my name is Jonathan Cottrell my goal on the show is to help you become

[00:00:56] a better developer but not just for the sake of becoming a better developer

[00:01:00] I want to help you become a bit better developer by first helping you

[00:01:04] understand what you care about understand what your personal purpose is to be a developer

[00:01:12] that’s the entire point of this show and by connecting you to that purpose hopefully I’m

[00:01:18] triggering something inside of you that acts as kind of a renewable resource right something that

[00:01:25] kind of

[00:01:26] you can return to whenever you’re feeling burnt out whenever the work gets boring or you run into

[00:01:31] you know one of a hundred thousand a million different problems that you could possibly run

[00:01:36] into as a developer that you know kind of make you want to throw in the towel you can return to

[00:01:43] this kind of underlying sense of purpose but this comes with a degree of understanding how we should

[00:01:52] be practicing our jobs right

[00:01:56] I’m for us to really connect to that purpose for us to really

[00:01:59] uncover what it is that we care about we may first have to let go some bad

[00:02:05] habits rate in this show one of the kind of underlying themes that you’ll hear on

[00:02:11] this show over and over and over is that ego really isn’t going to help you out

[00:02:15] and that’s what today’s episode is about we’ve talked about humility directly

[00:02:20] before in today’s episode is kind of an indirect way of talking about humility

[00:02:24] we’re talking

[00:02:25] about letting go of your ego so that you can ask really simple questions. Very straightforward

[00:02:32] questions that might even make you or even the person that you’re asking uncomfortable because

[00:02:37] they’re so simple. So I’m going to give you a few examples of these kinds of questions right after

[00:02:42] we talk about today’s sponsor, Linode. Today’s episode is sponsored by Linode. Linode has

[00:02:48] continued to be one of the most important sponsors that we’ve had on the show, not only because

[00:02:54] they’ve come back over and over and over to continue investing in this community,

[00:02:58] but also because they actually truly care about the developers who are listening to the show right

[00:03:04] now. They want to create an excellent product for you, and it’s visible right on their service

[00:03:09] offerings. You can go and see everything that Linode provides. You can see on their website,

[00:03:14] but you can get started with as little as 20 credit

[00:03:20] just for being a developer tea listener. Now, this isn’t just

[00:03:24] a server that you go and you, you know, interact with some software and you spin up a server and

[00:03:30] you’re left on your own and you’re kind of out in the cold. And if you screw it up, then too bad

[00:03:36] for you. That’s not the way that Linode operates. They have an excellent customer service team,

[00:03:41] and it’s a 24-7 customer service team as well, by the way. So it’s not, it’s not just, you know,

[00:03:47] some odd hours that are in one time zone. If you live anywhere in the world, really,

[00:03:54] you can access this customer service. So I want you to go and check it out. If you are either

[00:03:59] considering moving from a existing service provider in this area, or if you don’t have one yet and you

[00:04:05] would like to start, you know, spin up your own servers that have Linux running on them, you can

[00:04:11] do so many things with these servers. It’s not just about hosting a website. You can do pretty

[00:04:17] much the sky’s the limit with a Linux server. So go and check out what Linode has to offer.

[00:04:22] Head over to spec.fm.

[00:04:24] And get started today. By the way, all of the plans are hourly. So if you wanted to scale up

[00:04:29] and solve, you know, really computationally intensive problem, you could do that for a

[00:04:35] short period of time and then scale back down. And Linode is going to respond to that scaling.

[00:04:41] Again, spec.fm. And that will automatically apply the code developer T2018. But if for some

[00:04:49] reason it doesn’t, use that code developer T2018, all one word, and you’ll get $20,

[00:04:54] worth of credit applied to your account. Thank you again to Linode for sponsoring today’s episode

[00:04:58] of developer T. So we’re talking about humility. We’re talking about letting go of your ego.

[00:05:03] More specifically for today’s episode, we’re talking about what constitutes a dumb question.

[00:05:09] What is the makeup of a question that is, you know, not good enough? How can we judge this?

[00:05:17] And usually the answer is something that you should have already known, right? Something that,

[00:05:24] you know, is very basic, something that is fundamental, that, you know, is an easy

[00:05:29] question to answer for anyone that is even reasonably experienced, right? I came to this

[00:05:35] conclusion as the result of some mentoring and a lot of experiences with developers who

[00:05:42] ultimately were self-taught. They didn’t have any formal education. And this was true for me too,

[00:05:48] because I am a self-taught developer and there’s a lot of excellent resources out there. And in

[00:05:53] fact, there’s a lot of excellent resources out there. And I’m going to talk about that in a

[00:05:54] minute. But for a lot of people like me and a lot of people that I’ve mentored or that I’ve

[00:06:09] otherwise encountered as developers, there’s a lot of blind spots that you wouldn’t expect to be

[00:06:16] there. So for example, let’s say that you are learning a programming language. You can actually

[00:06:23] employ a programming language that you’re familiar with. And you can actually employ a programming

[00:06:24] language that you’re familiar with. And you can actually employ a programming language that you’re

[00:06:24] familiar with. And you can actually employ a programming language that you’re familiar with.

[00:06:24] This concept with yourself. There’s something that we as humans, we have this unique ability

[00:06:30] to have an internal dialogue. In other words, you can ask yourself questions. You can ask yourself

[00:06:37] even these very simple questions and practice that non-judgmental hearing of that question and

[00:06:46] then the answering of that question. But as you’re learning a new programming language,

[00:06:51] start asking yourself,

[00:06:54] at a fundamental level, at a very simple kind of basic level, understanding what you’re looking at.

[00:07:02] So for example, if you’re writing JavaScript and you write maybe a variable name and you set it

[00:07:10] equal to something, ask yourself, which are new ways of declaring different types of values in

[00:07:17] JavaScript. And if you’re using things like let and const, ask yourself questions like,

[00:07:23] do I know the difference? Do I know what the differences are between the behaviors of these

[00:07:29] two types of declarations? And when you start asking yourself these questions, what you’ll

[00:07:34] realize is that the things that you assumed that you knew are actually not as clear to you as you

[00:07:41] may have thought. You might uncover new ways of thinking about data types or thinking about

[00:07:48] algorithms. Or you might uncover new ways of thinking about design or thinking about

[00:07:53] operation by simply asking fundamental questions about how things work. Asking fundamental

[00:08:01] questions about the definition of various things. You know, this is another thing that you can do in

[00:08:06] your workplace. If you ever have a lack of clarity when you’re talking, especially in a collaborative

[00:08:12] group, even if it seems that everyone else in the group is clear on a given thing. For example,

[00:08:21] maybe there is a word or a technology that you’re using that’s not clear to you. And you’re not

[00:08:23] clear about the terminology that someone is referencing. Or maybe there is a group of people

[00:08:27] that someone is referencing and they’ve kind of collected them into a single signifier, a single

[00:08:33] label. Maybe they talk about customers or stakeholders and you’re not really clear on

[00:08:39] what those groups actually are, who those people actually are. This is the kind of thing that once

[00:08:46] you ask for clarity, you may uncover, you may uncover to one of two main things. The first one

[00:08:53] is that that group actually isn’t well defined. And that the words have been kind of accepted by

[00:09:00] the group without actually unpacking them, right? That’s one thing that you may uncover. Another

[00:09:05] thing that you may uncover is real information that you didn’t have before. You may actually

[00:09:10] get that clarity that you’re seeking. And in both scenarios, you’re increasing the knowledge

[00:09:16] and you’re increasing your understanding about that given subject. Now here’s the reality.

[00:09:22] This is not good. This is not good. This is not good. This is not good. This is not good. This is not

[00:09:23] going to be an easy thing to do. Especially if you’re asking for clarity around a term that has

[00:09:30] been used for a long time, for example. Or if you’re asking someone, you know, something that

[00:09:37] you really, they believe that you really should have already known the answer to that, right? You

[00:09:42] very well may run into a sense of judgment. Now what I encourage you to do is to explain why

[00:09:50] you’re asking these questions and encourage,

[00:09:53] others to ask the same types of questions. This is not an easy thing to do. I want to

[00:09:58] kind of reiterate that over and over because it’s going to feel unnatural to ask questions

[00:10:03] that you believe have obvious answers. But once you start down this road, once you actually start

[00:10:09] asking these, what seem to be kind of audacious questions or otherwise, you know, unnecessary

[00:10:16] questions, once you actually benefit from asking a few of these, then you aren’t really going to

[00:10:23] care what you’re asking. You’re going to be able to ask the same types of questions. And so,

[00:10:23] you’re going to start asking questions that you’re not going to care what it looks like anymore,

[00:10:24] right? And your coworkers aren’t really going to care what it looks like anymore,

[00:10:27] because once you start actually increasing the level of clarity and knowledge within the work

[00:10:34] that you do within the company that you’re working for, or, you know, within the collaborative group

[00:10:38] that you’re working on, once that increases, then you’re not really going to care how it happened

[00:10:44] as much as you’ll care that things are going better, right? You’re actually producing better

[00:10:50] work as a result of these questions.

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

[00:10:57] continue to, you know, kind of push that boundary of what’s acceptable and what is normal and

[00:11:03] how you learn. It’s important to continue pressing into new ways of learning and questioning your

[00:11:10] assumptions every single day. Thank you again for listening. Thank you to Linode for sponsoring

[00:11:15] today’s episode. You can get started on Linode today and get a $20 credit by heading a respect

[00:11:21] out of him.

[00:11:22] Thank you again to Linode. Thank you so much for listening to today’s episode. We have over 500

[00:11:29] episodes of the show right now, which is kind of mind boggling to me. I hope that some of you

[00:11:35] have listened since day one. I hope you continue to listen for the next 500 episodes. And I hope

[00:11:41] that I can continue providing value through this show to the people who listen to this podcast.

[00:11:47] It really is a joy to hear from you and to see things like iTunes reviews.

[00:11:52] And that’s actually one way that you can help the show continue doing what we do.

[00:11:56] If you go to iTunes and leave a review, subscribe in iTunes. Of course, iTunes is kind of like the

[00:12:01] central hub for podcasts. So if we’re doing well on iTunes, then that really helps us reach more

[00:12:08] developers every day who are looking for content like this. There are people who need to hear

[00:12:14] these kinds of ideas and who need to start questioning their assumptions.

[00:12:18] They need that same validation that you’re getting from,

[00:12:22] this show. So I encourage you, if you want to help us out a little bit,

[00:12:26] go and subscribe and rate and review through iTunes. That’s a huge help.

[00:12:31] Thank you so much for listening. Until next time, enjoy your tea.

Visão de gráfico