Hacker News Reader

Comment by jrib | Hacker News Reader

I'll add two more that I find important to the "Strategies" category:

1. Write things down. Have an assumption? Write it down. Then write down how you will test your assumption and the results.

2. Being able to systematically enumerate possibilities and rule them out one by one, often times indirectly. Yes, one needs to understand the system but one also needs to have a good strategy to use that knowledge. By "indirectly," I mean being able to reason like so: If P, then Q. Not Q. Therefore not P.

View on HN

That reminds me of the Mikado method [1]:

  - Set a goal
  - Experiment
  - Visualize
  - Undo

[1] Ellnestam, O. Brolund, D. (2014). The Mikado Method. Manning Publications Co.

Or as written by George Pólya in How To Solve It

  1. See
  2. Plan
  3. Do
  4. Check

“OODA loop" also can be applied here:

- Observe

- Orient

- Decide

- Act

I always see these types of acronyms and check lists and wonder why they exist. Is this something that human beings use?

Completely irrelevant to debugging, but the "OODA loop" concept is one that's applied often in martial arts and close-quarters combat.

- Observe: observe bug.

- Orient: check code that maybe involved, check in environment related variable values.

- Decide: decide what you will change in your code to try to fix bug.

- Act : implement fix.

Repeat all steps until you found fix.

Of course you can use different approach to debugging but this one works quite well too.

https://en.m.wikipedia.org/wiki/OODA_loop

Reply on news.ycombinator.com