If Rubber Ducks Could Talk!

While reading up on the Rubber Ducking technique (the act of describing your problem to a toy rubber duck in the hope of finding the solution), I thought to myself, "What if the rubber duck could talk back." What kind questions would it ask, to help me find and fix bugs in my code"?

I decided to come up with a list of things I do when trying to debug code. The things that could be overlooked during those tense moments when systems fail or during long coding sessions when you tell myself, "Just 10 more minutes, and I'll go to bed", only to realise that its 3am and you have to wake up at 6am for work the next day.

So, in no particular order, here's my list questions you should ask yourself and things you should do when debugging code:

Isolate the problem

Is it possible to test the failing code in isolation?

Removing unnecessary calls to modules and stubbing out external network calls could make it easier to locate the bug.

Change one thing at a time

Has the bug been introduced as a result of changes to multiple parts of your code (e.g. during a massive refactor)?

If so revert those changes and make them in smaller increments, testing as you go.

Baby steps

Can the offending code be broken down into smaller, logical steps?

Doing so will allow you to test smaller chunks and make it easier to locate the issue.

Common errors

Have you ever come across this error before, if so, what did you do to solve it in the past?

Maybe it's time to add some unit tests that cover common errors, to help prevent them from creeping back into your codebase.


Have you been working on this bug for longer than 30 minutes?

If so, take a 5-10 minute break and go for a walk or grab a coffee. Don't be stubborn. You'll be amazed how much more productive and focussed you'll be after a short break.

Error messages / Stack trace

How well have you read the error message?

Error messages and Stack traces generally have important information as to the root cause of an issue, so make sure you read them carefully and understand them. Google terms you don't understand and learn how to correlate different types of errors with possibly solutions.

How well do you understand the problem?

Do you fully understand the problem you're attempting to solve and can you fully explain the problem to someone else?

Attempting to fully explain a bug can help you find the solution to fixing it. It's much harder to fix a bug when you don't fully understand what the code does. See 'Rubber Ducking'.


Is there, and have you read the documentation for this codebase?

If not, you might want to do so! Documentation is there for a reason and might have vital information about common errors, dos and don'ts, unstable functionality etc.

Check your unit tests

Are your unit tests passing?

If not, then this might be a good place to start. The failing unit test(s) might relate to the bug you're trying to fix.

It was already broken

When was the last time this code actually worked as intended? Is it possible that the bug was already there, before you made your changes?

If you use Git, use the git bisect command to find the commit in your project’s history that introduced the bug. Once located, you could also use the git blame command to find the culprit, who might be able to give you some background information on fixing the bug.

External issues

Could this bug have been caused by issues with an external service, component or module that you don't control?

Try bypassing external services with the use of fake data and stubs, that have a similar data structure to what your code expects. Also, think about adding some unit tests that test the system fails gracefully when supplied malformed or missing data.

Process of elimination

Start commenting out or disabling parts of the codebase until the application start working again. Then slowly reintroduce chunks of code until the bug manifests itself.


Have you checked the logs?

You might be able to garner some information that could bring you closer to the source of the problem.

Recreate locally

Can you recreate the issue locally?

If this issue is happening on a remote server, it's important that your development environment mirrors your remote environment as much as possible.


Have you checked Googled for a solution?

Someone else is very likely to have had a similar problem and might be able to give you some clues about fixing it.

Ask a colleague

Have you asked for help from a colleague?

Don't be shy! You could save yourself an hour, or two!

It works on my machine!

Have you tested the issue on another machine?

Get a colleague to check the bug on their machine, to help eliminate possible hardware or configuration issues. If they get different results, you should start investigating how your machines differ.


Does this bug always coincide with certain events, e.g. a specific time of day, only during deployments, user load etc?


Are you linting your code?

If not, you could be saving yourself a world of pain.

Fine tooth comb

It might be time to bite the bullet and start at the bottom and work you way up. Fire up your debugger and start stepping through the code, line by line, function by function, from beginning to end, tracing the flow, making sure that each stage does what you expect.

Silver bullet

Have you switched it off and switched it on again?

Don't hate on this tried and tested method of fixing issues!

If rubber ducks could talk, these are the types of questions I'd want it to ask me. Hopefully, asking yourself these questions the next time you encounter a bug, will bring you closer to the solution.

If you have any comments or suggestions, send me a Tweet @icodejs.