Day 274: Judge, Jury, and Executioner

If you want to go fast, go alone.
If you want to go far, go together.

- supposedly an african proverb but who really knows

on some days, when i’ve been possessed by the slug spirit and am melting into my bed, i think about how nice it would be to have teammates. someone who can say “hey dk, take it easy; i got this”. when you’re a team of one, nothing happens unless you make it so which can be a pretty fat burden when you don’t feel like doing anything.

on other days, like today, i feel exhilarated at being able to move as fast as i want. i just finished implementing the entire flow for sharing and importing flows with hella smooth transitions between the browserflow extension and the browserflow website, and i feel incredibly satisfied. it was a very productive day.

when i make design decisions, i write them down in the relevant issue that i create on github because i want to spare future me from the suffering of not remembering why the heck i did something a particular way. here are a few of the decisions i resolved today in the course of designing the share flow:

should a description be required when a flow is shared?
what should the url for a share flow be?
should sharing a flow create a copy of the flow so that there’s a shared copy and a working copy or should there only be a single copy?
what should the share dialog look like?
where should the share button go?
should the website use static generation or server-side rendering to pre-render the shared flow pages?
what should happen when someone clicks the button to import a flow? should the focus stay on the website or should the extension popup be opened and focused?
etc. etc. etc.

while working with a team has many perks, one of the downsides is that you can waste a lot of time debating things that don’t matter. the decisions i made above are pretty low-stakes — most of them can easily be changed/reversed, and generally, taking an iterative approach where “good enough” becomes better over time is way more important than trying to figure out the perfect color or copy for a button. but oftentimes that’s what ends up happening when you work with other people, especially if you have overlapping skillsets.

one of the features i shipped when i was a pm at google was the ability to share reviews on google maps. it was a simple feature that only required three pieces:

a button on the review to share it
generating a URL for the review
creating a destination for the review URL

shipping that feature took like half a year aka AN UNREASONABLY LONG TIME. one reason is that google maps is ridiculously complex and pieces 1 and 3 required consulting with the teams on all the different platforms because maps has a ridiculous number of clients: ios, android, desktop web, mobile web, search web (which is different from maps.google.com) and it was a nightmare trying to figure out how we can ship an experience that worked for everyone, everywhere, on all devices and platforms. the price of working at google-scale is going through many, many reviews with many, many teams to make sure everything was done correctly and all the appropriate stakeholders have signed off.

in contrast, i implemented the entire sharing flow for browserflow in a single day. obviously, i don’t have billions of users to support, but being able to move quickly and experiment with a bunch of approaches without having to wait for permission is so, so nice

(quick aside: oh man, when i decide to write an actual blog rather than the stream of word vomit that is road to ramen, i have so many stories from google i want to share)

anyway. while there are certainly drawbacks to working solo, the freedom of having full creative control over the process and no barriers can be intoxicating