Making Dnote

I am making a product called Dnote. It is a tool to spontaneously capture what you learn while coding without leaving the command line. In this post, I am going to share why and how I have been bootstrapping this product.

Dnote provides a way for developers to solidify their everyday learning. On a daily basis, developers come into contact with various bite-sized knowledges about certain languages, frameworks, and domains. Those tidbits are not only useful for the immediate problems that developers are facing at the time, but also can make developers more proficient and creative in the long run.

In spite of the long term benefits, we merely treat our microlearnings as if they were only as good as the solution for the problem at hand, and rarely make attempts to retain the knowledge. Many times, we are too quick to assume that a new knowledge has completely become ours, because our memory is the freshest at the time we acquire the knowledge. In reality, our grasp of the new wisdom fades away rather quickly:

According to the forgetting curve, we forget what we learn at an exponential speed unless we try to retain it. In this light, we are misguided in assuming that what we just read on Stack Overflow or watched on YouTube becomes completely ours instantaneously.

Meet Dnote CLI

What if we can capture our learnings at almost zero cost? Last Thursday after work, I made a proof of concept program that stores users’ learnings as a YAML file in a home directory. Each microlessons are ‘notes,’ which are stored under ‘books.’ The command line interface has the following interface:

# Choose a book
$ dnote use javascript

# Make new notes
$ dnote new ".bind() creates a new function"
$ dnote new "You cannot make a synchronous result out of an asynchronous operation"

# List all books
$ dnote books
* javascript

When a new ‘note’ is created, they are categorized under the current ‘book’. All data is written to $HOME/.dnote as YAML like the following:

- .bind() creates a new function
- You cannot make a synchronous result out of an asynchronous operation

- Rename stuff using `rename -n "s/ /_/g" *`
- SIGHUP stands for 'signal hangup' and is sent to a process when its controlling terminal is closed

No Context Switching

Using the command line interface, developers can capture tiny bits of new useful information they come across without switching context. In my opinion, the cost of context switching is the main deterrent to keeping track of what we learn when we code. It takes time to get our brains invested in a problem, and the last thing we want to do is opening up a notebook or some application to jot down our microlessons.

As an example, I have a notebook called ‘Coding’ in Evernote, and it contains notes like this:

When I am coding and my mental faculty is deeply invested in a problem, I do not want to go to Evernote, create a note, and come back to my command line. By the time I am back at my terminal or IDE, I need to reestablish the context in my mind.

Effortless Reinforcement

Even when we do make a conscious effort to record our new knowledge, we stand poor chance of making them our own because retaining new knowledge can take even more effort. For instance, the above example shows that I created a quick note on what I learned about Unix permission numbers more than a year ago in February, 2016. I am pretty sure I have never opened that note until this moment to take a screen shot. And yes, I still do not know chmod numeric permission notations by heart.

Dnote can help developers retain their newly acquired knowledge by reminding them of what they have learned. In the future releases, users will be able to sync their local Dnote data with the server, and set up a regular email digest of their microlearnings. That way, we can achieve a true mastery of our newly acquired knowledge through spaced repetition. We will not have to go out of our way to retain what we learn; Dnote will simply remind us.

This automated reinforcement can be a premium feature that can be monetized, making Dnote a sustainable product in the long run. Dnote CLI will always be open source and free for anyone to run.

Learn What Others Learn

Once users can sync local Dnote data with the server, Dnote community can transform into a collaborative learning environment. Users will be able to subscribe to a book and see popular notes by other developers around the world. In other words, we will be able to learn not only what we learn, but also what others learn.

Users will also be able to follow other respected developers to take a peek into what they are learning every day. Such experience will be both educational and motivational.


Our newfound wisdoms need a safe, nurturing home. Otherwise they quickly perish and die, bereaving us of the opportunity to grow as developers. I am making Dnote to illuminate a passage for our everyday microlearnings to a safe place, where their seeds can be planted and watered, and their potential can bloom.

We maximize our potential as developers by remembering more of what we come to learn every moment, not by simply doing and learning more. A Korean proverb says of “pouring water into a bottomless jar.” Without an effort to capture and retain the little things we learn, we might be hopelessly pouring our serendipitous rendezvous with a brand new knowledge into an abyss of forgetfulness.