Simon Tatham1d ago

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 threadDiane Bruce1d ago
@simontatham FWIW the Sudoku approach was pretty much how all debugging had to start in the days of punch card and core dumps. It's still of use IFF you have the source code as you can trace through the source and figure out what it should be doing. Too much minesweeper and you end up with code peppered with printfs. 😀​
Show threadMike P1d ago
@DianeBruce @simontatham Debugging ASICs and FPGAs is very Sudoku-heavy too - and when the Minesweeper approach does come in to it, you start by playing a game of Sudoku to work out how you're going to look for that next clue!
Show threadDiane Bruce1d ago
@FenTiger @simontatham Oh we furiously agree both tactics are useful! I do worry that the "kids" overuse the spray and pray method of debug.
Show threadMike P1d ago

@DianeBruce @simontatham Well, in both approaches you have to start by thinking about what your next move will be.

Experts might be able to do the thinking bit very quickly - but they still do it.

"Spray and pray" suggests to me that they're skipping over the thinking part and going straight for the printfs ...

Show threadDiane Bruce1d ago
@FenTiger @simontatham Ideally yes. One should know what the code should be doing and hopefully be able to unit test each piece before putting it together and testing after it's put together. I find testjigs very handy for that.
Show threadChris L1d ago
@DianeBruce @FenTiger @simontatham printfs, or debug logging, can set the stage for faster Sudoku debugging, as you have more concrete constraints on what must be true at each log line. Important to include the value of the variable affecting program flow.
Show threadDiane Bruce
@jayalane @FenTiger @simontatham We are furiously agreeing!
May 23 at 6:44pmWeb
Show threadChris L1d ago
@DianeBruce @FenTiger @simontatham maybe I feel defensive since my last commit was removing a bunch of prints from this “memoize python functions into SQLite” module I use (I had to bump it from one column to ten due to max width in SQLite, and so I had to debug it for the first time in ten years. Usually I always keep all prints I add for debugging at least in some lower log level, but it wasn’t worth it to me since this is really supposed to:be invisible infra that just works.
Show threadDiane Bruce1d ago
@jayalane @FenTiger @simontatham Hey guilty as charged as well. One problem with debug prints is the debug lines can obfuscate what you are trying to grok! Even if they are hidden from the output with a log level.