Development Guidelines (updated)


  1. Isolate
  2. Simplify
  3. Materialize.

These are the steps you should take to help you implement new features or fix old ones.

rubber duck debugging

Isolate the problem

It’s hard to figure out what exactly is causing the issue and how if you have multiple variables floating around. Try to distill the problem as much as possible so you’re only working with one independent variable.

If you’re having trouble isolating the problem, move to the next step then restart the cycle until the problem is solved.

Simplify the problem

If you know what is causing the problem, it will be easier to figure out the how and why if you simplify it. Get the most simple version of the feature working on it’s own in an isolated environment and then slowly keep adding back everything else that is needed to work with the environment at large. It’s best if you do this one by one; as time consuming as you think that might be, you’ll probably waste more time in the long run trying to figure out what broke and where if you don’t.

If you’re having trouble simplifying the problem, move to the next step then restart the cycle until the problem is solved.

Materialize your thought process

In a nutshell, rubber duck debugging. It works. Sometimes it’s hard to organize all of your thoughts and ideas by only thinking about them in your head. When you materialize your thoughts (ideally though voice and with a colleague) you’re forcing a narrative and inherently giving them structure. This does two things:

  1. The new structure lets you more easily reason about the problem and apply new/better thinking to the situation in general.
  2. The new structure frees up some of your brain resources which in turn can be reused for thinking about the problem and more often lets you look at it from a new perspective.

With these materialized powers combined, the rubber duck debugger often achieves that satisfying eureka moment where all the pieces fall into place and knows how to progress with the problem.

Doing this with a colleague often has the added benefit of an alternative perspective, however if you work alone or for some reason are unable to verbalize your thoughts, writing them down should work just as well, maybe just a little slower.

That’s it! Have fun coding :)

By the way, this framework can be applied to a lot more than just software development. This is a general process for troubleshooting and could be applied to all sorts of problems you might have. Go try it out!

UPDATE: 1 Apr, 2020

I recently came to the realization that even if you do follow these steps, you might still get stuck (which is what happened to me), so here's some more advice.

Don't get stuck up on the specific implementation

I started learning a new framework and came across two ways of making web requests. One was old and deprecated and the other was new and reactive. Given the fact that this new method wasn't deprecated and I already had an interest of the reactive paradigm I obviously chose the latter.

However, no matter how I tried to isolate, simplify and materialize, I couldn't get it working. Then it hit me. Why don't I just try the older deprecated method instead? Sure enough it worked the first time. So if you come across something similar, don't get hung up the same exact method and explore alternatives. Especially if getting the functionality out the door is a priority.

#softwareDev #troubleshooting #debugging #rubberDuck