The Feynman Algorithm: A Developer’s Guide to 'Thinking Very Hard'

Source: Dev.to

The Feynman Algorithm

If you search for Richard Feynman’s methods, you’ll likely stumble upon the famous Feynman Technique, a framework for learning new concepts by explaining them to a child.
But there’s another, lesser‑known Feynman method, jokingly coined by his colleague Murray Gell‑Mann, who said that Feynman’s process for solving problems looked like this:

1. Write down the problem.
2. Think very hard.
3. Write down the solution.

At first glance, this sounds like a meme, but it actually outlines the lifecycle of debugging and writing software.

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” – Albert Einstein

In programming we often skip the thinking phase. We see an error log and immediately start changing variables and refreshing the browser. “Writing down the problem” forces you to define exactly what is going wrong.

Bad vs. Good Problem Definition

• Bad: “The login page is broken.”
• Good: “When a returning user tries to log in with Google OAuth, the API returns a 500 server error, but only on mobile Safari.”

When you write the problem down clearly, the scope narrows. Half the time, simply defining the problem accurately reveals the solution.

How Developers “Think Very Hard”

• Rubber Duck Debugging: Explain the code line‑by‑line to an inanimate object (or a patient coworker).
• Isolate: Comment out chunks of code to see if the bug still happens, narrowing down the variables.
• Step Away: Take a shower or go for a walk. Your brain’s “diffuse mode” continues processing the problem in the background.
• Resist Quick Fixes: Avoid copy‑pasting the first Stack Overflow answer without understanding why it works.

Writing the Solution

In the context of coding, “writing down the solution” means three things:

1. Write clean code – ensure the solution isn’t just a hacky workaround, but a readable, maintainable piece of logic.
2. Write tests – prove that the solution actually works and guard against future regressions.
3. Write documentation – leave comments explaining why you did what you did.

// Using a Set here instead of an Array because checking for duplicates
// was causing a massive performance bottleneck.

Your future self (and your team) will thank you when they read such comments.

Conclusion

The Feynman Algorithm might have started as a joke among Nobel‑prize‑winning physicists, but it’s remarkably practical for software engineers. Next time you’re stuck on a nasty bug, don’t just start mashing the keyboard:

1. Stop. Write the problem down.
2. Take a walk to think very hard.
3. When you solve it, document the solution.

Adopting this disciplined approach can turn frustrating debugging sessions into structured, repeatable successes.