Mastodawn

Two different approaches to debugging a software problem:

The Sudoku approach: stare at the limited set of clues you have, and think harder and harder about them until you find a way to deduce something useful.

The Minesweeper approach: don't even try to figure out the solution from only the clues you have right now. Instead, focus on finding a way to acquire another clue, and then using that to get another, and so on. Eventually you've collected so many clues that the answer is obvious.

Sometimes the Sudoku approach is necessary, because you've got all the clues you're ever going to get. But I think my new motto is "Never Sudoku a problem when you can Minesweeper it."

Show thread

scmbradley 1d ago

@simontatham I think this is true if you're debugging something on your machine. But if you're trying to help a client with an issue, where each round of minesweeper can take days of back and forth emails to get your new clue, sometimes you should sudoku a problem you could, in theory, minesweeper.

Show thread

Simon Tatham 1d ago

@Scmbradley true, you have to interpret "can" with a certain amount of pragmatism. I agree that there are situations in which Minesweepering is technically possible but prohibitively expensive.

In this situation I generally try extra hard to get the client to provide a reproducible example. Sometimes they still can't, or won't, but sometimes they just haven't thought of trying, so in my experience it's worth a shot.

Show thread

James Wells

@simontatham
And there is the problem... It is almost impossible to get the "client" to give you the answers you need and when they do, it is often like pulling teeth to get the second question answered.

Often in that situation, I will start with sudoku until the client gives me enough that I can re-create their failure myself and then switch to minesweeper to do the actual troubkeshooting.

@Scmbradley