• Thursday, 10/12/23 ** 08:39 Lately, I've been solving difficult software problems by permuting the solutions until I find the best one that fits.

Yesterday I stuck the problem in my head, went for a walk, then came back and specified a solution. ** 20:49 From debugging experience today - Code walkthroughs - in front of a group or just one person - can be really helpful, but you need to know where to start.

Narrow down the problem in your own head and on paper as much as is reasonable; don't consider code coverage so much as the aspects in which your program could fail. "I've narrowed it down: the bug is with this behavior (in this case, a refresh issue), and that issue could be caused within this scope."

Then allow the user to assume what's outside the scope - you've used good function names and left good comments, so this shouldn't be a problem - and ask them to identify problems or things that look off, starting from 'the top' of the problem surface and working our way down - just like Matthias taught. (That was two years ago now... wow. I'm just reaching that point in 'my career' now. That's kind of sad. Work faster!)

We would have found the problem instantly if I'd done that at work today!