I was surprised to see such a negative reaction to this exchange - but I think I see something pretty useful here, and it seems worth sharing while it is fresh - so at risk of further derailing my day...
Why I said "No" to Roadmaps
And why the right response was [[Yes and]]
Throughout my life, I've had a lot of people tell me that they think I should have different priorities, or do different tasks (Go to college, get a job etc)
An important shifts in my life was realizing that it was almost never the right move to ARGUE with those folks
However..
I can see from the reaction that a few things happened there that probably didn't need to.
I read the thread as a demand to do something unreasonable
To either A) know things I did not know already, or B) Shift our priorities to things more legible
Anyway - notice I'm doing the thing I was seeking to avoid initially -- arguing the point, and spending time on here rather than collaborating with a guest
Real point
It does not matter that there were places @Roamhacker might have been wrong, just as many places they are right
I still think my original tweet (emphasizing that I care about the person, but think they are wrong about timing and walking way) is better than jumping into a hostile argument...
but it still was a confrontational NO, when a [[Yes And]] sent tomorrow would have been more useful
One thing @roamhacker probably doesn't realize is that I spend hours and hours every week working on trying to clearly articulate the maze of questions that go into some of our prioritization decisions - and that my number one, two and three goals for product is creating this map
This thread took time I didn't want to give now - and certainly can't give everytime someone asks why X is not done yet, or when Y is expected
Sometimes - answer is much much sooner than I thought - often, it takes longer than I hope.
Instead I could have said something like...
Creating a "Roadmap" into unknown territory is harder than you might think
agree it is important, but from my experience creating something that I actually think is useful and not just wild guesses would take weeks of my full time attention and right now I can only give 1/5 time
If you want to try writing out all the questions that YOU think Roam will need to answer (on design, engineering, and operational side) I would love to hear them - and I can tell you which ones we're already working on - which ones we're actively testing hypothesis on
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
Iβm probably even worse at managing and recruiting than design or engineering!
A better CEO would almost certainly have grown our team faster, and managed the great staff we have more effectively
In that world weβd have even better collaboration and βTrust No Oneβ security
As it stands, we have best in class security, but the class includes folks like Google, Facebook, and every run of the mill tech company that wants to mine your data to serve you ads.
Weβre explicit in our terms of service that Roam will not read your notes, but code beats law.
So @phonetoroam is probably the @RoamResearch js extension that has had the biggest impact on my workflow so far.
Uses a simple and elegant "hack" to do things I had not imagined possible
If you've been waiting for our backend API, you'll want to know about this
Quick thread
The problem:
Roam is still running off the local first architecture I developed in 2017 to optimize for rapid iteration and a snappy editing experience
The backend is an event stream of edits, all logic of the graphs is on the frontend
There isn't a server in traditional sense
This is one of the reasons large graphs in Roam can be slow to load initially, but consistently have snappy editing -- we optimized for the writing and collaboration experience at the expense of being a great tool for publishing your ideas (at this stage)