[delhanty]

>Some caveats: It’s been nearly five years, and I have no doubt that I have misremembered some of the specific details, even though I’m confident in the overall picture. I’m also certain that Stripe has continued evolving and I make no claim this document represents the developer experience at Stripe as of today.

Are there any more recently ex-Stripe folks here willing and able to comment on how Stripe's developer environment might have evolved since the OP left in 2019?

[nkohari]

I spent 4.5 years at Stripe, and left in March.

The biggest difference not mentioned is the article is that code is no longer kept on developer machines. The sync process described in the article was well-designed, but also was a fairly constant source of headaches. (For example, sometimes the file watcher would miss an update and the code on your remote machine would be broken in strange ways, and you'd have to recognize that it was a sync issue instead of an actual problem with your code.) As a result, the old devbox system was superseded by "remote devboxes", which also host the code. Engineers use VSCode remote development via SSH. It works shockingly well for a codebase the size of Stripe's.

There are actually several different monorepos at Stripe, which is a constant source of frustration. There have been lots of efforts to try to unify the codebase into a single git repo, but it was difficult for a lot of reasons, not the least of which was the "main" monorepo was already testing the limits of the solution used for git hosting.

Overall, maintaining good developer productivity is an extremely challenging problem. This is especially true for a company like Stripe, which is both too large to operate as a "small" company and too small to operate as a "big" company. Even with a well-funded team of lots of super talented people putting forth their best efforts, it's tough to keep all of the wheels fully greased.

[cynicalpeace]

Glad to see that they moved to code living with the execution environment. The code living separate from the execution environment seemed like too much overhead and complexity for not enough benefit.

Especially given VSCode, or Cursor ;), work so well via ssh.

To the engineers that don't want to use those IDE's it might suck temporarily, but that's it.

[jcmfernandes]

Thanks for this. Can you share the experience of those who don't use VS Code?

[tail_exchange]

IntelliJ is also supported. If you want to use something else, like VIM, then you need to ssh into the remote devbox machine. They have support for custom dotfiles, so you can set up your cool VIM environment for all your remote devboxes.

If you don't want remote devboxes, the regular devboxes still work. You just need to deal with the additional pain for syncing the files.

[bhuga]

Some important differences from 2019:

* Code is off of laptops and lives entirely on the dev server in many (but not all) cases. This has opened up a lot of use cases where devs can have multiple branches in flight at once.

* Big investments into bazel.

* Heavier investment into editor experiences. We find most developers are not as idiosyncratic in their editor choices as is commonly believed, and most want a pre-configured setup where jump-to-def and such all "just work".

[eikenberry]

That last point has long been a red flag when interviewing. A developer who doesn't care about their tooling also tends to not care about the quality of their work.

[mvdtnz]

I'd rather work with developers who are flexible and open minded about the conditions they can work in than those who get notoriously pissy if things aren't set up exactly the way they like it. Especially when that way is ridiculously elaborate and non-standard.

[ParetoOptimal]

Its also a red flag for me when a company mandates an IDE.

[cynicalpeace]

I'm glad to see that first bullet point. The code living separate from the execution environment seemed like too much overhead and complexity for not enough benefit.

[artyom]

Not ex-Stripe but in "close relationship" with them since its inception and there's a clear mark in my calendar circa end of 2018 when their decisions and output started to become... weird, or ill-designed.

I don't think it has to do with the dev environment itself, but I'd blame such thing for allowing to deliver "too fast" without thinking twice. Combine that with new blood in management and that's an accident waiting to happen *

They're the best in business still, but far from the well-designed easy-to-use API-first developer-friendly initial offering.

* Pure speculation based on very evident patterns

[rattray]

Ex-Stripe ('17-'20) here. Agree.

Though I am under the impression that things have gotten more sensical internally over the last year or so.

Note also that the devprod team has largely been shielded from the craziness, and may still be making good decisions (but I don't know what they are in this realm personally).

[chaosphere2112]

I was only there in 2022, but at that point there were in fact three or more monorepos (forked roughly based on toolchain - go and scala in one, primarily Ruby in the one detailed here, and there was one for the client stripe api libs that was JS only. There may have been more.