cborenstein

Hey, I'm Cara - one of the founders of bytebase.io. Thanks for your question!

Currently we don't have a roam style overview graph.

While a graph can be satisfying to look at, it also encourages striving for "perfection" in your notes. The graph wants you to create a masterpiece.

That's not what Bytebase is about. Bytebase is for the scratch notes core to your daily work - some of which you'll want to refine and organize later. Getting things down is messy and that's how it should be. After the "jot down", Bytebase helps you stay just a little more organized over time by making it easy to organize/categorize in small steps (and giving you flexibility through multiple parents and infinite hierarchy).

Re: navigating around - our approach uses keyboard shortcuts to quickly jump to and hone in on the bytes you need. One way we do this in Bytebase is with Speed Dial (https://www.youtube.com/watch?v=N3lS5J71HEM) - which lets you jump to a location in one keystroke.

It sounds like you and your team are taking a great approach to knowledge sharing. Thanks for sharing! The promotion requirements from the top communicate that knowledge sharing matters. And the way your team shares knowledge focuses on creating content people want. It's not just documenting because you "should."

This is totally in-line with what I've learned about effective knowledge sharing. People tend to ad-hoc share knowledge as needed instead of thoroughly maintaining a wiki. This isn't bad. With ad-hoc sharing, like with your Loom video, you have a clear recipient in mind. Your effort is valuable.

(I'm building an app to help you keep your private notes better organized so this ad-hoc sharing is easier. In bytebase.io you write your notes like you're texting. "Texting" lets you be fast and messy. It also adds modularity to your notes. Modular notes are easier to organize).

Do you do those activities for the joy of it or for self-improvement/another goal?

The way the book talks about leisure is that it's time you spend not striving for things. An example she gives is going for a walk without focusing on how many steps you're taking.

Design docs are great because writing them is aligned with the author's best interest, not just a future reader. (This is different from docs that are written after the project is complete).

Design docs help you understand the project, identify dependencies, and avoid repeating work. Then they leave a trail for future engineers of the thought process that went into the code.

I agree - choosing a tool that makes jotting stuff down most convenient is key.

I believe that there hasn't been enough innovation in the jot-down phase of notes. Most people use Apple Notes, Google Keep, or raw text files. They're convenient for jot-down. But painful when it comes to organizing.

Notes are easier to organize when they're modular. You can add modularity, without losing convenience or speed, by writing notes like you're messaging yourself.

Fast jot-down + easy to organize in small steps = more likely to stick with it.

(I'm one of the creators of the modular, messaging-like notes tool bytebase.io)

Very much agree with this. The idea of separating the "dump" phase from the "organize" or "refine" phase has been an inspiration for what we're building at Bytebase: https://medium.com/@bytebase/an-iterative-approach-to-notes-....

I surveyed 50 engineers a little while ago on how they take notes. This is what I learned.

Most people's notes have two phases [0]:

1) Jot-down

2) Organize

In the jot-down phase, you write down thoughts and gather any raw resources that are useful to you (code snippets, links, etc.). These notes are messy.

In the organize phase, you pull notes from your jot-down that are worth keeping and refine/categorize them. These become your reference notes.

Usually people use two different tools - one for jot-down and one for organize. This leads to lots of copy-paste and things being more difficult to find later. Working on a tool [1] for fast jot-down and organize in one place,

--

[0] over 90% of people surveyed used Apple Notes, Google Keep, or raw text files for their notes.

[1] https://bytebase.io

The goal of product documentation is that new devs (and future you) are able to get the info they need.

This doesn't mean that it needs to be entirely from a wiki.

In my experience, wikis are rarely up-to-date because 1) shared ownership === no ownership 2) too high expectations --> people publish less

I recently surveyed a bunch of devs on their knowledge sharing and learned that for most devs, private notes are actually more useful than wikis.

Private notes are easier to keep up-to-date because they can be messy and because they have a clear owner. You can then share them as needed.

Working on a product to help devs write better private notes and share as needed. The difference is that you write notes like you're texting yourself. This lets you be fast and loose. But then your notes are modular. Modular notes are easy to organize/share granularly.

[https://bytebase.io]

"The main thing is to keep the main thing the main thing." - Stephen Covey

> Getting people to contribute can be a problem This is so spot on. and I don't think it even has to be a problem.

The way people actually work is they 1) write a ton of private notes 2) share a small amount of these notes ad-hoc 3) publish a tiny amount of this to a wiki

To make knowledge more available, the key is to streamline these steps.

Building an app that's grounded in this workflow. Would love to hear the community's feedback on it.

[0] https://bytebase.io

One of the most important pieces looking at this history is that yellow indicates to writers that these pads are low-pressure to write on. They’re substandard and cheap.

So you can write freely.

Glad it was helpful!

I also recommend this related article by a psychologist that explains:

"When a person fails to begin a project that they care about, it’s typically due to either a) anxiety about their attempts not being “good enough” or b) confusion about what the first steps of the task are. Not laziness."[1]

[1] Laziness doesn't exist: https://humanparts.medium.com/laziness-does-not-exist-3af27e...

My favorite quote from this is:

"When a person fails to begin a project that they care about, it’s typically due to either a) anxiety about their attempts not being “good enough” or b) confusion about what the first steps of the task are. Not laziness."

Thanks for explaining! It sounds like you have a strong process going.

> I do create a new text file each time, although it's sort of arbitrary what I group. It's great that you do what works for you without obsessing. Too often people chase after a rigid/"perfect" system and that's just not realistic.

In my experience, the more modular you can go (without it stopping your flow), the better. Because it'll be easier in that organize step.

I've found that by thinking about my raw notes as a chat with myself, I'm able to increase the modularity without hurting my flow.

Awesome. Glad to see that separating the "getting stuff down" from organizing has worked for you too.

Do you create a new raw text file for each note? How long does it typically take you to do the organizing process?

> trying to establish your system upfront is a mistake. Things inevitably leak through your categories and then you lose faith in your system.

I don't know if it's a mistake. I think you need to embrace the fact that your current system won't be perfect, and you'll need to adjust as you go. It doesn't mean you shouldn't start with something.

> 1. If we have time to enter something into a knowledge base of any kind - then we have time to just jot it on a piece of paper.

Great point. I often see people sharing strategies for organizing notes but I rarely see people discussing how they get stuff down in the first place. And there's a lot of improvement we can make here.

I wanted to add more modularity to my jot-downs so that it would be easier to organize them later, one small step at a time. I found that I can get this modularity by writing my notes as if I'm texting myself.

(Working on a tool [1] that has this sms-style interface with keyboard shortcuts for purging my notes and organizing. would love your feedback).

[1] https://bytebase.io

A strength (and weakness) of async is that it comes with a higher expectation of writing quality.

When the expectations are too high, it's likely that people won't get things down in the first place.

My team has noticed an unintuitive approach to communication that seems to work better than alternatives. Write better private notes.

Private notes are low-friction. You know what's worth writing. You don't need to worry as much about if it's a mess.

Our approach is to help you make your private notes a little better organized. And to make it fast to share these notes when they might be helpful to someone else too.

It's bytebase.io. Would love the community's feedback.

I'm also a startup founder and I try to stay disciplined in keeping a can-do attitude all week. The main principles I try to stick to are:

* Uplift with gratitude

* Take breaks

* Breakdown overwhelming tasks

* Celebrate small wins

* Be clear on your motivation

Breaking down tasks is one of the most important ones for me. I find that if a task isn't well-defined or small enough, I dread starting it. I've started doing "braindumps" on any task that isn't small and actionable until I get there.

Post for more details: https://link.medium.com/PSWM5I8Vo6

Great to hear! Currently Bytebase is free to use.

When we move out of Beta, we'll have both free and paid tiers.

My goals for my personal knowledge base are that it's comprehensive (i.e., it has a lot of stuff) and it's accessible.

To achieve this, I need a way to support these two different phases of notes:

* The first phase is "get-it-down."

* The second phase is "refine."

The "get-it-down" phase needs to be fast. It's important for me that I don't need to think about where to write. The "refine" phase is where you can delete, organize, edit, and build off of what you've written. It should also be fast.

I always had to use two tools to satisfy these needs. I needed one place where I could write fast/loose, and one place that's more organized and structured. This resulted in me writing to the "organized" knowledge base less. So I was less likely to get the most out of the things I was learning.

That's why I built bytebase.io.

With Bytebase, you jot things down into a temporary space called "No Man's Land." Then you organize your notes using keyboard shortcuts. If you want to check out our closed beta, email me at cara@bytebase.io. Would love any feedback.

Awesome piece, thanks for sharing. I agree that the key to effective communication is to lower the barrier to writing things down.

In that vein, this piece is missing one thing. It is inherently easier to write something private than to write something shared.

Think of how often you jot things down in Apple Notes, Sublime, etc. as opposed to in your shared space with your team.

A culture of written communication starts with personal (un-shared) notes.

I'm one of the creators of bytebase.io, a notes app that helps people write low-friction, private notes and quickly share with teammates when relevant.

This project looks awesome. I created bytebase.io, a notes app that shares much of the same philosophy - flexible hierarchy, simplicity, user control.

We'll definitely consider supporting import/export to Margin.

Bytebase (I'm one of the creators) is built for keeping track of notes and snippets on your own or with your team.

Everything you create is one short snippet or "byte" and these snippets can be grouped into different "collections" using tags.

Would love any feedback.

https://bytebase.io

It sounds like you do a great job communicating regularly in your typical in-person environment.

I previously worked at an "old-school" company where everyone on the team would work remote 2-3 times a week. We'd also collaborate closely.

One thing that we naturally did was pair off on projects, so on a given week (or month), two people on the team were working on closely related things. On days when we'd work remote, it was easy to switch to talking to your partner on video chat / slack /email. I found that coordinating with just one other person for most of the meetings is easier and more dynamic than trying to bring in everyone.

I like https://coolors.co/ for color palette generation. Not sure what their algorithm is.

For remote meetings, having a process for writing down and sharing meeting notes is especially important.

As compared to in-person meetings, it's easier for someone to miss a key point and not be caught up on it.

When considering tooling, I'd recommend looking at ways to:

1. Enable live access to the shared notes during the meeting. This gives teammates the chance to clarify things that may have been misunderstood right away.

2. Make notes easy to find after the meeting - whether it's 2 days or 2 months later.

3. Highlight and keep track of the action items that result from the meeting.

We created https://bytebase.io for low-friction team notes. It's currently in closed beta - ping me for access.

+1 that Why matters most.

My teammate recently wrote a blog post on how we document Why in git commits and PR descriptions.

https://medium.com/better-programming/daily-habits-to-turn-y...

Would also recommend checking out a related talk by a tech lead at StitchFix: https://confreaks.tv/videos/rubyconf2018-documentation-trade...

Thanks for your thoughtful reply.

What do you to accommodate people who aren't natural writers?

Really interesting idea, thanks for sharing.

I think encouraging people to ask for clarification is super important.

One thing that's helped me receive more clarifying questions is adding pauses while talking. This gives an opportunity for someone to ask questions without interrupting.