The title says it all, really.

I keep all my notes, plan most of my projects, and keep a diary in one big Google Doc. It’s been going on for about two years, and it’s grown to about 110 pages.

It’s been the most useful way to gather my knowledge about things I learn on the job, to keep track of projects, and even help me debug stuff!

In this post, I’ll outline why I’ve decided to do this, how I’ve structured my doc over the years, and how it may benefit you!

What problems does this solve?

Over the years, I’ve searched for the perfect note-taking system. I want to have the knowledge I have organized and readily accessible. But that’s not all I want from my note-taking system.

When choosing a note-taking system, I want:

  • To be able to easily find a place to put something.
  • To be able to easily guess the place where I put something.
  • To be able to add visual resources (images, tables, links…).
  • To be able to organize it easily.
  • To do that from any device, from anywhere, without having to invest in infrastructure.
  • To be able to set reminders to do things.
  • To be able to write a diary (very important to keep track of the important points at meetings!)
  • To be able to put all the context around a single project, and easily archive that when I’m done with it.
  • To do all of that for free, or at least with a one-time payment.

I’ve tried many systems before settling on this one, but they all had their flaws. One Big Google doc, however, fits these perfectly.

Let’s see how:

How I structure my Google Doc:

My google doc's outline

As you can see, I rely heavily on Google Docs’ header structure to keep my content ordered. Headers give you a clear outline, and make things easy to find.

My philosophy is: As long as the headers are organized, the content inside can be as messy as I want.

I find this approach very flexible, as it allows me to focus on the content most of the time, without being worrying about structure.

Let’s dive deeper into each section:

Open Threads

These are things that I’m expected to comment or act on, but haven’t gotten around to yet. Things like:

  • Code I need to review.
  • Design documents and tickets I should read and give input on.
  • Comments I should address on my own code.
  • Actions I have to take as a result of a meeting.

Ideally, this list should be empty at the end of each day. Doesn’t always happen, but it’s a great goal to have.

If an item stays in this section for a week or more, it probably means it takes more time than I thought, and thus it has to become a real project. More on projects later.

Cool? Cool. Moving on.

The Diary (and Archived Diary)

Every day is full of learning moments, and the diary allows you to not miss any.

This contains a daily record and summaries of the meetings I’ve had and the things I’ve done during the day.

Here is an example entry about a very interesting conversation I had with one of my tech leads about a project. The meeting ran for 30 minutes, but I was able to synthesize it in a few sentences:

Example Diary Entry

Keeping these records has three goals:

  • When I’m focusing on leveling up a big skill (e.g. “Code Review”, or “Leadership”), I can note everything that I see related to that skill during the day, in order to absorb it better.

    A colleague published a great code review? I think about what makes it great, and note down my learnings here.

  • I can note any verbal and non-verbal red flags I see during meetings. If I notice someone is being shy, or cut off, or not having a good time, I note it down to follow up later.

  • When the time comes to ask for a promotion, I have a detailed record of my contributions that I can use as argumentation that I’ve been contributing a lot of value.

Now, that said, I’m not always diligent about keeping a diary. It’s a lot of work, and I think I rarely miss many important things at meetings anymore.

However, it’s something that helped me greatly when I started, and I pick it back up whenever I’m having a particularly tough time at work, or I want to level up.

Archived diary

Every week, I move all entries from that week’s diary into the diary archives so that only the most recent entries are immediately visible.

Like What You Read?

    We won't send you spam. Unsubscribe at any time.
    Built with ConvertKit

    Ongoing, Completed, and Frozen Projects

    This is the section where I gather all the information about projects in flight. Typically, I’ll have 2 to 3 projects open at a time.

    I use the word “project” very loosely here. In this context, a project is a task that will require at least one day of work to accomplish. It could be as small as a refactoring ticket, or as big as a new feature.

    Each project gets a header, with links to every place with relevant information (Design docs, tickets, documentation…).

    As long as the headers are organized, the content inside can be as messy as I want.

    It will also contain my thoughts on the project, a stream of consciousness if you will. Whenever I’m stuck or I don’t know where to go next, I just start writing in the project’s section. This is usually called rubber-duck debugging:

    Here is an example of a project section. Notice how messy it is!

    Example Project Entry

    Completed Projects

    Whenever I’m done with a project, it goes into “Completed Projects”. These are projects that I’ve completed successfully, and thus can be part of a promotion packet.

    Frozen Projects

    Sometimes, you don’t get to finish a project.

    It gets deprioritized, or it was an experimental project that you didn’t have enough time to finish. In those cases, I move the corresponding entry to the “Frozen Projects” list.

    Notes on Content

    This is the section where I note the important things I’ve learned.

    I tend to learn in one of two ways: Either I do ad-hoc learning when I’m working on a ticket (also known as frantically googling for information), or I sit down to learn something from the ground up.

    This is the section I use to do the latter.

    Whenever I say “this is getting confusing, let’s sit down and really learn this”, that’s when I open a new section here.

    The point of writing my findings here is not to contain copy-pasted excerpts from the documentation of whatever I’m learning.

    Rather, this section is for me to explain things in a way that make sense to me, making the connections to other things I know.

    Just to show that it only has to make sense to me, here are my notes on Python Imports:

    Example Notes Entry

    It’s tailored to how I understand information, which is not necessarily how the documentation is written.

    This section is long-term storage for digested content.

    Conclusion

    That’s it! That’s all I use!

    Google Docs are deceptively powerful note-taking tools.

    They provide all the features and flexibility I need, and I think they can help you too!

    If you’re looking for a place to keep all your notes, but none of the existing solutions work for you, I suggest you give them a try.

    If you do, I’d love to hear about it at Twitter @BeyondLoop!

    Have a great day,

    Borja