Software Engineering Tip #1: Agh it still doesn't work

[jack]

I was hoping this was going to be a bit more technical, but there you go. The idea is to write inspired by whatever I'm doing at the moment.

This is not so much debugging as, when you're sure the problem is fairly simple but it still sucks you in for ages and you can't tell if you're getting it fixed, how to avoid being dispirited. Which is a problem I used to have a lot. What has helped?

1. Talking to other people! Partly for a second pair of eyes, partly to just ground yourself and get someone else to share the situation and agree you're doing the right thing.

2. Take regular breaks.

3. Work through the problem step-by-step. This should be appearing here. It isn't. Check each intermediate step.

4. Decide if (often), it's worth making the step-by-step tests ones that can be saved in the test suite against future failures, rather than ad hoc "step through in debugger".

5. If you can, maybe work on something else for a bit.

6. Be realistic if this is still the most important thing to do or if you should be doing something else.

7. Be realistic, do you know as much as anyone else about fixing this? If so, seek to keep your spirits up and bring in second pairs of eyes as necessary. If not, don't be shy, seek out advice on how to debug the problem.

8. Take heart. I've faced a LOT of problems that have seemed simple but intractable, and looking back with the benefit of hindsight a few were beyond me at the time, and many would have benefited from a fresh perspective, but none were actually black magic, there was always a sensible way to proceed, and I usually found one.

Comments

[angelofthenorth]

That's really helpful. I'm learning to code in R, and SQL, and that's such useful advice. Thank you

[jack]

*hugs* Thank you.

[mtbc]

Today I had a wrong value ending up in a variable and in searching through relevant code, etc. couldn't at all find where this wrong value was getting set. (It's getting passed among many Java classes and over RPC.) In the end I plugged in the debugger and used it via stacktraces at breakpoints to work backward instead of forward and then I found the culprit. So, your (3) can work both ways!

[jack]

Yes, that. I didn't necessarily mean follow the steps of the program sequentially (although that's often a reasonable thing to try first) but of consider the smallest thing you could possibly check (either a simpler version of the program, or checking one step forward or previous in the debugger is what you expect, etc), and so on.

Indeed, it's not usually this simple, but I often think of it as a binary chop: if I *wrote* the code the way I expect, but at some later point it does what I *don't* expect, then there must be a point somewhere between where it goes from "what I expect" to "not what I expect" so if I start in the middle, and then the middle of one half etc... Debuggers mean it's usually easier to step forward, but it can help me think *what* I want to think.

[mtbc]

Not really what your point was but this is partly why frequent commits help: git bisect and its like.

[green_knight]

I've found that isolating the problem often helps me - I write a new application with Just That One Thing and see whether it persists. And I try to write the solution from scratch, because very often having to think my way through it again helps me see where I went wrong last time.

[jack]

Yes! Test smallest thing possible, often there's a problem I didn't realise could be hiding there