Vox

Leitura de 18 min

Intentional Problem Solving: How To Work It Out, Without Google

Summary

This episode of Developer Tea focuses on the critical skill of intentional problem-solving for developers. Host Jonathan Cottrell argues that while tools like Google and Stack Overflow are valuable for immediate productivity, relying on them too quickly can hinder deeper learning and the development of true problem-solving abilities. He emphasizes that becoming a better programmer requires more than just learning new syntax; it requires practicing how to think through and understand problems independently.

Cottrell introduces the concept of “experiencing a problem”—deliberately facing coding errors or challenges without immediately seeking external solutions. He references Charles Kettering’s quote, “a problem well stated is half solved,” to underscore the importance of understanding a problem’s root cause before looking for answers. The host acknowledges that failure is inherent in coding and presents a constant opportunity for learning if approached correctly.

To cultivate this skill, Cottrell proposes a practical challenge: developers should keep a notebook and, for three problems each day, spend five minutes trying to solve them without using Google. This 15-minute daily investment forces a deeper engagement with error messages and code, encouraging developers to read source code, hypothesize causes, and struggle productively. The goal is to build the mental muscle for problem-solving, which is as core to development as knowing any programming language.

He clarifies that this practice isn’t about abandoning collaborative tools or existing knowledge entirely, but about balancing immediate fixes with long-term skill development. By intentionally subjecting oneself to hard problems and resisting the gut reaction to search for answers, developers can overcome imposter syndrome, understand the tools they use more deeply, and ultimately become more effective and self-reliant problem solvers in an industry that constantly changes.

Recommendations

Quotes

  • Charles Kettering’s quote — Referenced by the host: ‘a problem well stated is half solved.’ Cottrell uses this to emphasize the importance of understanding and articulating a problem before seeking a solution.

Tools

  • Hired.com — Sponsored in the episode, Hired.com is presented as a job platform where software engineers and designers can receive multiple job offers with upfront salary and equity details. A special link offers a doubled signing bonus for Developer Tea listeners.

Topic Timeline

  • 00:00:00 — Introduction to continuous learning and personal process — Jonathan Cottrell welcomes listeners and introduces the episode’s theme: becoming a better programmer through continuous learning. He discusses the agile methodology of trying, measuring, and adapting, and emphasizes that everyone has a different optimal learning process based on their personality and work style.
  • 00:02:06 — The problem with immediately Googling solutions — Cottrell argues that the instinct to immediately Google an error message or search Stack Overflow, while productive, often prevents deeper learning. He shares his personal experience of having to re-Google the same errors because the solutions didn’t stick, questioning whether this habit truly makes someone a better programmer or just a more immediately productive one.
  • 00:03:55 — Charles Kettering quote and the value of stating the problem — The host recalls a quote by Charles Kettering: ‘a problem well stated is half solved.’ He applies this to programming, suggesting that if developers only Google the syntax of a problem, they miss the learning opportunity of understanding and stating the problem itself. This segment frames the core issue of skipping the problem-solving process.
  • 00:06:22 — Why learning is a core pillar for developers — Cottrell reiterates that learning is a major theme of the podcast and essential for developers because the industry is constantly changing. He connects learning to failure, stating that coding inherently involves failure, and that developers can learn from these failures if they know how to ‘fail properly’ and extract lessons from the experience.
  • 00:09:16 — The challenge: practicing intentional problem-solving — Cottrell presents a concrete challenge to listeners. He asks them to keep a notebook, write down problems they encounter, and for three problems a day, spend five minutes trying to solve them without using Google. This practice is designed to force developers to read error messages carefully, hypothesize causes, and engage with source code directly, building their problem-solving muscle.
  • 00:11:41 — Managing expectations and overcoming discomfort — The host addresses potential discomfort, noting that trying to solve problems without Google may trigger imposter syndrome, especially when reading complex source code. He encourages persistence, clarifies that the goal isn’t to solve every problem alone indefinitely, but to delay the instinct to search and to struggle productively for a set period to foster deeper understanding.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2015-08-10T07:00:00Z
  • Duration: 00:13:54

References

Podcast Info

Transcript

[00:00:00] Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today we’re

[00:00:06] going to be talking about learning again. Of course, one of the most popular questions

[00:00:16] I get through Twitter and through developertea at gmail.com and through the contact form

[00:00:24] on developertea.com is how to become a better programmer. What are the things that I need

[00:00:28] to do to become a better programmer? The easiest answer and perhaps the best answer

[00:00:34] is always learn. Always learn more. Set yourself up for a continuous learning process that

[00:00:42] is constantly feeding itself. This is the spirit of the agile methodology. That is to

[00:00:49] try something, measure it, look at what you’ve measured, gain some insights about how well

[00:00:56] that thing went, and then try something.

[00:00:58] Try something else and then compare. You go through that process over and over and

[00:01:03] over. And the truth is, everybody has a different process that works the best for them. As different

[00:01:12] as we are, as different as our personalities are, there’s different things that we respond

[00:01:17] well to and there’s different things that we respond awfully to. Whether or not you’re

[00:01:22] an introvert or an extrovert, for example, you might work well when you’re surrounded

[00:01:27] by people.

[00:01:28] You might work well in isolation. Now, of course, there are quite a few studies that

[00:01:33] talk about the general public or statistically what helps people work the best, what types

[00:01:40] of situations are people most productive in. But it comes down to trying these things out

[00:01:46] for yourself. So I want you to set yourself up for a constant learning process, always

[00:01:52] feeding back into your process, always feeding back into the way you do things.

[00:01:58] So part of this process building experimentation technique that I’m asking you to try out,

[00:02:06] I think it’s important that you learn how to experience a problem. Now, I’m not talking

[00:02:13] about intentionally failing in order to try to fix something. I’m talking about experiencing

[00:02:19] a problem that you don’t have a solution at your fingertips for. And it’s very hard to

[00:02:26] do this because our first instinct is to try to fix something. And that’s what I’m talking

[00:02:28] about today.

[00:02:29] And the reason we try to do this is because the second we try to fix something we fail

[00:02:30] to fix what we’re trying to do in order to fix.

[00:02:31] That is to try and make it more open and more even.

[00:02:32] So what I’m really talking about is something we test. Now, you might have heard of a very

[00:02:33] common question that people have. That’s that there’s a lot of mistakes in the process

[00:02:34] of fixing something and how to fix that.

[00:02:35] One of the things that I always do is that I find as I’m on a business I kind of see

[00:02:36] myself as a problem maker because otherwise I’m not something that’s going to get rid

[00:02:37] of, I’m going to go ahead and fix it.

[00:02:38] And we can do that, but we have to find a way to fix it.

[00:02:39] And if you want to fix it, you can do it by teaching your students how to fix it.

[00:02:40] of coding where, you know, I was on Stack Overflow, every error that I encountered, and

[00:02:46] typically somebody has encountered that error and they help me figure it out. And that usually

[00:02:53] makes me productive in ways that I wouldn’t be productive without Google or without Stack

[00:02:59] Overflow. But the truth is, a lot of those Stack Overflow posts I have actually visited multiple

[00:03:06] times because none of the information really sticks. When I go and Google my error message

[00:03:12] and immediately put the fix in place, so many times I’ve had to re-Google the same exact error

[00:03:19] messages that I’ve Googled in the past, and the thing is at my fingertips and it helps me

[00:03:24] solve the problem immediately and it makes me more productive. Now, does that make me a better

[00:03:29] programmer? Arguably, I would say no. Some people would say yes. Some people would say that

[00:03:36] Stack Overflow is a good idea, but I would say no. I would say no. I would say no. I would say no.

[00:03:36] Stack Overflow is a perfectly fine tool to use. And again, this is not a Stack Overflow bashing,

[00:03:42] but instead, this is a way of saying, how do you learn? How do you actually make your mind better?

[00:03:49] How can you become a better problem solver? Quite a few episodes back, I mentioned a quote

[00:03:55] by Charles Kettering. The quote is very simply, a problem well stated is half solved. Now,

[00:04:03] if you don’t know how to state your problem, in other words,

[00:04:06] if you’re just simply Googling the syntax of the problem, then how are you actually learning? How

[00:04:13] are you actually solving that problem? You are actually just using code from someone else who

[00:04:18] has gone through the process of solving that problem. So how can you go through the process

[00:04:23] of practicing problem solving? How can you choose to stay away from Google and intentionally solve

[00:04:31] problems? I’m going to take a quick sponsor break, and then I’m going to come back and give you kind

[00:04:36] of a challenge for you to try out over the coming weeks, perhaps a month or two. Try it and see if you

[00:04:43] feel like you are becoming a better learner, and see if you are solving problems more effectively,

[00:04:48] if you have a better way of approaching each and every problem you encounter. I’m going to take a

[00:04:54] quick sponsor break, and we’ll be right back. I’m so excited to tell you about today’s sponsor

[00:04:59] because there’s opportunity for almost anyone with today’s sponsor, and that is Hired.com.

[00:05:06] On Hired, software engineers and designers can get five or more job offers in a given week. Now,

[00:05:12] each of these offers has salary and equity built in up front, and there are both full-time and

[00:05:18] contract offers and opportunities available on Hired. Users can view the offers from over 2,500

[00:05:25] companies of all sizes, from startups to large public companies, and then they can accept or

[00:05:32] reject the offers before ever talking to any company. So there’s no need for you to be a

[00:05:36] and it’s totally free to use. It’s 100% free to use. Now, normally, if you get a job through Hired,

[00:05:44] they’ll give you a $2,000 thank you bonus, but if you use the special link for Developer T

[00:05:49] that will be in the show notes, Hired will double that bonus to $4,000 if you accept a job.

[00:05:55] That’s Hired.com slash Developer T. Now, even if you aren’t looking for a job,

[00:06:01] but you know another engineer or a designer who is,

[00:06:06] send them to Hired, and if they accept a job on Hired, you will get a $1,337 bonus.

[00:06:13] That is a huge opportunity pretty much for anyone. So go and check it out, Hired.com slash Developer T.

[00:06:22] If you’ve listened to Developer T for very long, you of course know that learning is one of the

[00:06:28] major pillars of this show. We talk about learning all the time. In fact, there are

[00:06:33] multiple other episodes that we talk about. So if you’re interested in learning more about

[00:06:36] learning is kind of a core subject of that episode, and that’s true for this episode as well.

[00:06:43] Now, the reason learning is so important is very simple. This industry changes all the time.

[00:06:48] All of our code is changing constantly to adapt to the changing industry, to adapt

[00:06:54] to the technological advancements that are happening all the time around us. Smaller chips,

[00:07:00] faster bandwidth, et cetera, et cetera. There are so many things that are growing

[00:07:06] in the industry. There are so many new features and new languages, new ways of thinking,

[00:07:10] new ways of organizing data. All of these things require us to acquire new information, to take

[00:07:17] new information from what somebody else is spending their time developing and learning

[00:07:22] that information, understanding what that information means to what we do on a day-to-day

[00:07:29] basis, taking new things to implement into practical projects each and every day.

[00:07:35] The great thing about learning as a developer is that the opportunity to learn is presented to

[00:07:41] you all the time because learning happens when you fail, and failure is just an inherent part

[00:07:47] of coding. We are quite bad at coding perfectly the first time, so we’re going to fail

[00:07:52] very often, and we’re going to learn from those failures if we know how to fail properly,

[00:07:58] if we know how to deal with failure and learn from it. And that’s exactly what this episode is

[00:08:04] about.

[00:08:05] I’m challenging you to stop reaching for the quickest answer, stop reaching for the easy

[00:08:11] solutions, and instead experience the problem and try to find those solutions yourself as if you

[00:08:19] could not Google the error message, as if you couldn’t have access to Stack Overflow.

[00:08:25] Once again, I am not saying that you should try to act out your entire career without using the

[00:08:31] solutions of people who have come before you. Obviously,

[00:08:35] that’s the whole spirit of programming languages in general, abstracting what other people have

[00:08:41] learned and implemented in order to kind of stand on their shoulders. That is the spirit of

[00:08:46] programming and computer science at its best. We do best when we work together. Absolutely.

[00:08:53] But there are occasions where the solution for a problem is not as simple as Googling it.

[00:08:59] And in fact, there are many problems that we face each and every day where the answer is

[00:09:05] not absolutely available to us, either through Google or another means.

[00:09:10] So I believe that developers should make practicing problem solving a part of their

[00:09:16] continuous practice of learning. We need to learn how to problem solve as much as we need to learn

[00:09:22] the syntax of a given language. Problem solving is a core piece of what we do each and every day

[00:09:29] as developers. So here’s the simple challenge that I want to give you. I want you to keep some

[00:09:34] kind of notebook. It can be digital. I like keeping a written notebook by the side of my

[00:09:40] desk so that I can’t hide it. It’s always visible to me. Keep that notebook available to you as you

[00:09:47] are going through the process of a given day. And each and every day, when you experience a problem,

[00:09:53] write it down in that notebook. Now, I want you to take three problems a day and think about them

[00:10:00] for five minutes before you Google them. Now, that’s 15 minutes of investment,

[00:10:04] a day in learning how to solve problems more effectively. Now, what this is going to do is

[00:10:10] it’s going to force you to look and read what is happening in front of you. You’re going to have

[00:10:16] to read the error message and avoid the immediate reaction of Googling or asking someone else. I

[00:10:22] want you to write it down and then sketch out what you think could be the problem. Now, maybe you’re

[00:10:27] going to dig into some source code. Maybe you’re going to find yourself on GitHub looking through

[00:10:32] the issues. That’s fine.

[00:10:34] But I want you to look through the code, look at that problem, and try to dissect it without

[00:10:41] looking for a verified solution to that problem. Now, this might work for some of you. For some of

[00:10:47] you, it may not work at all. This is one of those things that you have to experiment with. But

[00:10:52] subjecting yourself to hard problems, subjecting yourself to a situation where you have to use your

[00:10:58] brain to solve those problems is an essential practice for developers. You can’t skip problem

[00:11:04] solving. You can’t skip problem solving. You can’t skip problem solving. You can’t skip problem

[00:11:04] solving. You can’t expect to become a world-class developer without knowing how to solve problems,

[00:11:11] without knowing how to read source code and understand what’s going on in that source code

[00:11:16] that may be causing your problems. Now, am I saying that you should stay on it until you

[00:11:22] solve the problem? No, not necessarily. I think there comes a time where Googling that problem,

[00:11:28] Googling that error message is necessary in order to, for example, make the necessary progress in

[00:11:34] the budgeted system.

[00:11:34] amount of time that you have on a given project. What I am asking you to do is deny your gut

[00:11:41] reaction to immediately jump to Google for an answer, immediately jump to the IRC chat where

[00:11:48] the team that built that particular tool is waiting to answer questions. Don’t jump directly

[00:11:53] to those places. Instead, struggle for about five minutes with whatever that problem is,

[00:11:59] trying to solve it on your own. Try to find the root cause for that problem. Now, if you’ve

[00:12:04] never done this before, if you have never solved problems without Googling them first, this is going

[00:12:09] to feel a little bit uncomfortable and you’re going to probably experience a little bit of

[00:12:14] imposter syndrome when you go and read source code of the favorite tools that you use each and every

[00:12:19] day and you can’t understand half of it. That is a very normal scenario to find yourself in. Don’t

[00:12:26] be discouraged. Keep on learning by subjecting yourself to hard problems. Now, once you’ve done

[00:12:33] this for two or three weeks, you’re going to be able to do it. You’re going to be able to do it

[00:12:34] I’d love to hear from you. I’d love to hear the types of experiences that you’ve had that were

[00:12:40] enlightening and perhaps the things that you didn’t expect to learn that you ended up learning. I would

[00:12:45] love to hear those stories. You can email me at developer T at gmail.com. Of course, you can reach

[00:12:50] out on Twitter as well at developer T. Thanks so much for listening to today’s episode of developer

[00:12:56] T. I appreciate each and every moment that you spend with me here on the show. I don’t take you

[00:13:01] for granted. The audience is what makes this show.

[00:13:04] Thank you so much for listening to this episode. If you or someone you know is looking for a job

[00:13:11] as a designer or a developer, go and check out today’s sponsor, Hired.com. Incredible opportunities

[00:13:17] from over 2,500 companies offering salary and equity, both contract and full-time,

[00:13:24] just so many opportunities there. Make sure you use the special link, Hired.com

[00:13:28] slash developer T, which will actually double your signing bonus if you do end up getting a

[00:13:34] job through Hired. And don’t forget that Hired also gives out a referral bonus if you refer

[00:13:39] somebody else. So refer them to Hired.com slash developer T. Thank you so much for listening to

[00:13:45] today’s episode. And until next time, enjoy your tea.

Visão de gráfico