Ep 31: Tales Of Derring-Do Bad and Good Luck Tales

Or: Duck Tales, Woo-oo
Or: Rubber Duckie, you’re the one

Which children’s tv show to pay homage to? Such a tough choice!

You know the rubber duck debugging thing, right? The idea that you should explain a problem, or some code to an imaginary or otherwise rubber duck on your desk and that forces you to think about the problems, out loud, and explain your thinking and suddenly you realise you’ve missed something and things fall into place, there’s a chorus of angels etc.

I do not have the rubber duck. I have the unfiled bug report. So many bug reports get closed half way through typing when I realise I’m being an idiot, or maybe I should try x first instead to see if the issue isn’t that it doesn’t work, but that it works in a way I wasn’t expecting or needs better help/UX text. These discoveries may well be filed as bugs but, importantly, they’re very different to the bug I was in the middle of filing.

Sometimes I think out what I’ll say to a developer if I go over to ask – I tend to plan out my half of conversations in my head anyway, so I generally have a ‘well, if I do this and this, this doesn’t happen (or does happen)’ and that 1) makes sure I’ve got my steps down – especially if there’s a weird or complex issue (or issue on a complex feature) and 2) makes sure what I’m saying makes sense.

Forcing yourself to formulate your thoughts into full sentences means your brain is getting information in a different way. It’s why you can say something and only realise what you’ve said after you’ve said it. You have to hear the words for your brain to click, as it’s a different way of getting the information. Your brain is great at smoothing over cracks when it’s made the leaps subconsciously.

Typing words out is a similar exercise. You’ve got to slow down to write out the connecting bits your brain doesn’t specify, so you get the information slower, in a different format, and with all the details, even the unnecessary parts (which may turn out to be necessary). I often go through the steps that caused the bug again but stopping to write each step down as I go. Again, this forces me to consider why I’ve done that step and whether that could be the issue rather than the system itself.

The issue with your brain, is that occasionally it lets you get away with your own bullshit, or manufactures bullshit and you end up in a mess. The duck or a similar proxy inanimate object means you can clear it out without having to actually get up or make too much of an arse of yourself.

I prefer to use a computer or mythical brain!developer at start as real people are unpredictable and derail into all sorts of possibly unrelated issues, plus also I am distracting them from what they should be doing, or if they’re in the zone.

Of course, there are times where I do all this and I still have to go over to a dev or file a bug, but at that point I am prepared and can explain/file a good bug so the developers know what’s going on as easily as possible.

Its also good for documenting tests, so the test session has notes about what I’ve done. I often reference the AC in the bug/test session, so it’s laid out in a As then, when this, then this, which is a fairly clear way to write out issues in a cause and effect kind of way.

Leave a Reply

Your email address will not be published. Required fields are marked *

Tags: , , ,