Most developers have had the experience of struggling with something all day, leaving work frustrated, and then solving it in the first five minutes of the next day. This is a perfect example of using focused and diffuse thinking to solve a problem.
Focused thinking is what the developer utilized when they were working on the problem during the first day. This involves creating a mental framework for the problem while ignoring all extraneous information. The developer is laser-focused on the problem they are trying to solve, ignoring all distractions.
After this framework is fully built out during focused thinking, diffuse thinking comes in to save the day (and the developer’s sanity). Once they go home and stop focusing on the problem, their brain can relax and transfer the bulk of their problem-solving to their subconscious. This is where their brain will make connections that their focused brain couldn’t. When they walk into work the next day the connections they need have been made, and they are able to solve the problem.
This is a great method to leverage when you are debugging or getting past obstacles in your own work.
Focused vs diffuse thinking
Focused thinking is like staring at the blueprints of a house, diffuse thinking is like looking down at the house from 30,000 feet.
A lot of the time, you’ve just been staring at a problem too long. Go on a walk. When you look at the problem again after giving yourself some time to utilize diffuse thinking, the solution will probably seem obvious. If this isn’t the case for you, and you don’t understand how this helps other people, you may not be using focused thinking properly before you use diffuse thinking.
A key part of leveraging diffuse thinking is having properly focused thinking beforehand. There are lots of ways to do this, but a few guidelines are listed below.
Be able to frame the question
You can’t solve the problem, be it a bug or another obstacle, without first understanding what the problem is.
- If there is a bug, replicate it.
- If there was a bug that you can’t replicate, look at the context of the bug from that time (logs, user, etc.).
- Look at the history of that project or codebase. Do they often have data integrity issues? Are their users untrained? Do they have multiple versions of the software out? All of this knowledge can help to point you in the right direction.
Having trouble framing the question?
Do you not know what you don’t know? If you were to jump on a call with someone and ask them how to solve your problem, what would you ask?
- Rubber ducky your problem to help with properly defining your blocker or obstacle.
- Once your blocker is defined, you have something you can start googling
Now that you have the question, google it
Throw your clearly defined blocker or bug in google. A lot of the time, someone else has had your problem before. If you don’t see any results applicable to your situation, reframe the question and try again.
Some really good places to keep an eye on when you’re looking through search results:
- The repository of the technology you’re working on
- The source code is a hugely valuable resource
- The issues section also has lots of bugs that people have solved or found workarounds for
- Stack Overflow
- The documentation written for the technology you’re working with
- Blog posts or articles written by other developers experiencing similar problems
Google didn’t solve my problems – now what?
There are lots of problems too complex or rare to be immediately solved with a google search. That doesn’t mean you’re out of options, though. There are tons of resources out there, including whole communities of developers that love solving interesting problems.
A few great resources when Google isn’t helping:
- Write a post on Stack Overflow.
- Stack overflow is slower but you’ll usually get a very good answer if you’ve written a good post
- To learn more about writing good Stack Overflow posts, look here
- Don’t get bogged down in writing the “perfect” post, or in worrying that your problem has already been solved and you can’t find it. The worst case scenario when you write a Stack Overflow post is that no one responds, in which case you have already framed your problem better by writing the post – so you’re still farther along.
- If your problem is specific to a technology, reach out to a community of developers who use that technology. Like the Ruby on Rails discord for Ruby on Rails problems.
- Figuring out when to talk to someone or reach out to someone
Other developers are a huge resource. Stack Overflow is so popular for this exact reason, people love to be nerd sniped if you present them with an interesting problem. You can learn so much in a short period of time.