Pitching Dnote

Recently, I pitched my latest product Dnote to a live audience and panelists at Fishburners. The pitch is followed by panelist and audience questions. In this pitch, I focus on the problem, the solution, and the personal narrative of how I am making Dnote, much based on my article Making Dnote.

Fishburners has a very scientific tradition of determining the winner of the pitch by measuring the loudness of the audience cheer by the ear at the end. Through the cutthroat algorithm, my pitch was determined as the winner of the night. Below is the whole recording and a transcription.

Hi, everyone. My name is Sung and I am a frontend engineer at Dgraph, but I am not here to talk about Dgraph tonight. I am here to talk about my product, called Dnote.

Dnote is solving a problem that developers forget what they learn every day.

This is what everyone thinks that developers do. Developers write code to make things work.

However, real workflow of developers looks more like this. We don’t know everything. And so we have to go on the Internet to look up things on Stack Overflow, which is like Yahoo Answers for developers, or on GitHub. That’s the workflow.

But the problem with that workflow is that we forget a lot of stuff. We don't actually retain our knowledge.

Here's "forgetting curve" from psychology. Unless we do something to retain our knowledge, we forget our newly acquired knowledge at a exponential rate.

One obvious solution is to take notes. But note is not a good solution, because you have to switch your context every time you want to take notes. Also, there's no reinforcement. You don't ever go back and look at your notes.

Dnote is a notes program right in your terminal.

So, developers spend a lot of time on a terminal like this.

If you can write a note right within your terminal, that means there's gonna be no context switching. If you are solving a problem, and you learn something new, you can create a note within seconds, and get back at your problem.

Dnote categorizes your lessons by book and note. You can choose a book using this command line interfaces and write a line within that book.

Dnote solves the problem of reinforcement by doing email digest. Everything you write in your notebook automatically gets synced with an API server, and there's a cron job that runs every week to remind you of everything you learned.

Now, your forgetting curve looks more like this. You don't actually forget what you learn. You constantly reinforce your learning until it actually becomes a part of you.

So, Dnote is a program that I wrote in 3 hours. 200 lines of code. And I am working on it on free time. About four weeks ago, I started. It’s completely open source under MIT licence, meaning everyone can look at the code base and make modifications to it.

Every day, more than 800 commands are being executed. But I had to stop measuring this because my users were very concerned about the privacy. Over 7000 website visitors and 200 GitHub stars, that's like Twitter likes, but a nerdier version. And I spent no money on marketing.

These are the weekly goals that I set out to do, when I first started working on Dnote. First week, got landing page up. Second week, got 10 active users. Third week, shipped the web client. Right now, I am fourth week, and I am working on email feature that I talked about. Next week I am going to work on making the actual sale.

Can a single developer working on a product on free time make a sustainable, profitable business within a month? I guess we are going to find out next week. This is where I write. That’s my blog, and you can also follow my journey on Twitter. These slides will be available on Fishburner’s Facebook group as well as Meetup.com.

We live in a sad time when coding bootcamps costs thousands of dollars, and we happily pay for it, but that's not the right way to grow as a developer. We become better by forgetting less of what we eventually come to learn every day, rather than going out there and actively seeking new knowledge.

Thank you. Great presentation. I love the simplicity, the goals, the one, two, three, four. It was really easy to follow, and you know, enjoyable, and so that's great. My question is: how much research did you do with developers before?

To tell you the truth, I didn't do any research. Actually, this is my problem in a way that I used to keep notes on Evernote and Google Doc, and I never looked back at my notes. So, I decided to write a simple program and open source it to other developers. And as our traction shows, the problem is real, and I think I can bring good benefits to other developers, not only me.

Thank you.

Well done, on the presentation. My question is: is this one, the notes that you record, is that only for yourself to see? Or can other people see it as well?

Right now, all notes are private, but there is a plan to grow it as some sort of a Twitter, but for developers, so that they can follow other developers and see what they are learning. A lot of developers actually share their lessons and know-hows on Twitter nowadays, but I don't think Twitter is the right medium for that.

I thought that was a really good presentation. It was nice and simple. You explained what it was, and you also explained it in the context of, I think a lot of people might not understand the problem so much, if they don’t have a technical background.

I totally get it. I have had that problem a few times, and so I normally use Cabinet. Sometimes you write a comment as well, and I remember, a while ago, reading a comment, and it was in my code, and it was, like, something that was really, really smart, and I just couldn’t remember why. It was really intelligent, like that wasn’t written by me. Then, I realised it was, but I didn’t have the research to back it up.

So, like, I get it. I thought the presentation was really good. I don’t really have too many comments. You kind of went through everything very simply. The traction was good and all of that. I thought it was great.

Do we have anything, a question from the audience?

How is this different from Evernote?

One of the problems that I identified at the beginning was that Evernote requires context switching. Developers' jobs are to solve problems. And to solve problems, we have to immerse ourselves into a sort of a state of trance. Once we break out of that state of mind, it's hard to re-establish our context, because establishing context is very expensive. In short, Dnote is different from Evernote, in that it has less friction than Evernote, in terms of everyday working environment of developers.

If you look online for, sort of new information, and to refresh your memory, why do you need to take notes in the first place?

It's true that information is available out there, but we become better at our profession, we become better at our craft by making this knowledge a part of ourselves. I think that should be our goal for any kind of profession, to grow and become better. For developers, I think the underlying goal is to make this knowledge a part of you, so that you don't have to keep looking it up. Also, true hackers don't look things up.