Note Driven Development (NDD for short) is my take on the rubber ducky debugging technique with an added bonus. Before I begin explaining NDD let me describe what rubber ducky debugging is:

In software engineering, rubber duck debugging or rubber ducking is a method of debugging code. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck.

The rubber ducky technique actually works and gets to the same outcome of explaining your problem to a co-worker or friend. But I see it as short lived and comes in only after you’ve already written code. With NDD it solves the same problem and takes it steps further by starting earlier in your process, adding documentation to your code, adding tests before you begin, and can be used for reference at a later date.

Instead of talking out-loud in the office to a rubber duck and looking like a crazy person, write down your task breaking it down into single sentences, similar to a check list.

Let’s take the following task and break it down to give you an idea of how to use NDD.

Goal: Create a pop-up that asks the user to confirm deleting a note.

Steps:

1. User clicks on a delete button
2. User is presented with a pop-up
3. User clicks a button to delete their note in the pop-up
4. Note is removed

Pretty simple, but this is just the first draft. Now let’s dive deeper into what’s really needed to complete this pop-up. The goal is still the same, but notice how the steps are fleshed out with specific detail, using sub-tasks.

Goal: Create a pop-up that asks the user to confirm deleting a note.

Steps:

1. User clicks on a delete button
2. User is presented with a pop-up
   1. Create a pop-up that is centered on the page
   2. In the pop-up it has a header text that says: “are you sure you want to delete your note?”
   3. Button 1: “cancel”
      1. to not delete the note, which closes the pop-up
   4. Button 2: “delete”
      1. to confirm that you want to delete the note
3. User clicks a button to delete their note in the pop-up
   1. Removes your note
   2. Closes the modal
4. Note is removed

We still have the same 4 steps, but now fleshed out to what is actually needed during development.

Here are the benefits:
1. From here you can create a new file in your programming language of choice and paste in these steps, turning these steps into code comments. Now you instantly have documentation for what your feature is doing.

2. When you’re building your feature you can now focus on doing one step at a time, ensuring that each part of your code does one thing, and that one thing extremely well, while matching to your code comment.

3. This is a great way to kick off Test Driven Development(TDD for short). You know how the code should function and can write pseudo-code for your tests before a single line of your feature is actually written.

4. During any part of the development phase while coding, you can always look at your code comments and know exactly what needs to be done, or at what area you may be stuck in.

Everything together:
Now when your feature is complete you will have clean documentation, tests to run your code, and if you get stuck along the way, you can look at the steps again while debugging and make sure that your code is still following and is executing how you outlined above.

And that’s it, the idea is very basic and I’m sure many of you are actually doing this without truly knowing. Now that you know how this technique helps you become a better developer, use it to your advantage, and help teach others so that they don’t get stuck in the black hole of debugging.