New blog post: Stripe's monorepo developer environment
This one started as a Slack thread at work, outlining some salient decisions that Stripe's developer productivity team had made in building out the standardized developer experience there. I decided it was interesting enough to expand into a public post.
This one kept growing during the writing, clocking in at nearly 4000 words. I suspect it might benefit from harsher editing, but I've decided to cut myself off and ship.
I want to call attention here to one of my favorite little pieces of technical implementation we did: Our implementation of synchronization barriers in developer tooling. Stripe used a model of "edit code locally, sync to a devbox in the cloud," which has a number of advantages and I've seen at many places. One major problem with this approach is communicating to the human user whether synchronization is up-to-date; you risk running an older version of code without realizing it, and thus majorly confusing yourself.
Stripe implemented a feature where most development commands also ran on the laptop, and coordinated with the synchronization process to ensure that the devbox was up-to-date before continuing. We made use of watchman's logical filesystem clock in order to do so without adding unnecessary latency.
I really love this model, and I'm sad I've never seen an open-source tool which implements it. I'd also love for someone to explore taking this model further: Could you implement a mode where *the entire shell runs locally, and just plumbs individually commands over a persistent ssh connection? With awareness of synchronization s.t. commands never saw old code? That feels like it could be very powerful…
Thanks for reading this far! As is my custom, here's a photo of Ranger looking fabulous at the golden hour:
