> few nuggets scattered on the internet regarding how Stripe does things (ex. #1, #2, #3) and in general the conclusion is that they have a very demanding but very advanced engineering culture
The comments so far are surprising. Yea counting PRs and lines of code isn’t impressive, and yes you may also do them at your own company. Any engineer will tell you, if you push code often and continuously move it to production, regression is inevitable. In finance, at a scale that stripe operates, not making mistakes is very critical. Being able to do what the articles describes is very impressive in any engineering organization. Being able to do that as Stripe is even more impressive.
My previous company averaged 2 PRs (and deploys) per engineer per day across a small team. At my current company I'm averaging about 2.5 CLs per day (they're a bit smaller changes). Stripe is good at this, but this is very achievable.
Often the problem is that we put too much into a single change. Smaller changes means easier reviews, better reviews, less risky deploys, forces better tooling for deployments and change management, often lower latency, and even often leads to higher throughput because of less WIP taking up head space and requiring context switching. The benefits are so compounding that I think it's very undervalued in some orgs.
The article seems surprised that you can do so many changes at scale, but IMO that's the wrong perspective. The larger the scale you have, the easier it must be to ship a change.
Yes, regressions will be more painful if you manage trillions of dollars, but it also means shipping a fix for such regressions needs to be easy and fast, which you can only do if you have a good and frequent CI/CD pipeline.
See also "The Infallible five-tier system for measuring the maturity of your Continuous Delivery pipeline". You should live on "Friday".
Having minute of downtime per year is quite a big tradeoff.
It makes sense for Stripe, they would lose lot of money when not operating. But in smaller companies you can choose to take more downtime to reduce engineering time.
Instead of skirting around doing gradual data transformations on live data, you could take service offline and do all of it once.
Diminishing returns at some point, but, I think the counterpoint to this is companies who are doing a single huge manual deployment every month (or less) which is scheduled into a 4-hour outage window where many if not all services will be down for this period.
I do agree there isn't a lot of delta between a company doing 2 or 10 deploys a day and a company doing 1,200, but, there's a huge engineering gap between companies who do approximately .03 deploys per day and those doing multiple.
It is undoubtedly very impressive. But once you're set up for it, it's probably easier than saving up the changes and doing a big release at the end of the month, because the amount of change and the amount of risk, per deployment, then is also a lot higher.
Like other commenters here have said, it doesn't mean that I can say "(scoff --) we're doing the same" if I'm doing the same relative number of releases with my tiny team. But it is validating for a small team like mine to see that this approach works at large scale, as it does for us.
This sounds like how PMS sometimes tout the number of tickets per sprint. It's not a relevant metric, and it's easily gamed
How many of those prs were small fixes? How many went to low used services, or services only used internally?
They clearly have strong set of tooling for dev ops stuff, and I do believe that stripe has strong technical chops, but this number does not show that they are delivering value. It just shows they are delivery something... Somewhere
> The goal is not 1,145 deployments per day. It's removing the friction that makes that pace impossible. What's really stopping you from rapidly shipping value to users?
But you haven't identified any value, just mindless cited some throughput stat.
Merge your code changes in 1-letter increments and you can juke the stats even higher!
I don't know if it's jusst me, but a company with 8000 devs having 1000 PRs per day doesn't look impressive at all? That means...a dev is producing a PR less often than a once a week on average? That's not only underwhelming but downright bad. Their uptime is much more impressive here, but it still doesn't strike me as anything exceptional.
If you use tooling like renovate/dependabot and run them daily over a large list of repos, you already get your 1000 PRs automatically, without humans even looking at the codebase.
Conventional "dev" wisdom says that LOC and PR count don't matter but I think its very easy to combine this data point with the nature of a dev's work to come up with a great heuristic on productivity.
Something to question though: does the A/B test system generate a changeset when an engineer flips a feature flag or changes the cohorts or percentage it’s rolled out to? Those are very safe changes generated by a template and with easy (maybe even automated) rollback, so they can happen all the time without really risking downtime.
There’ll still be plenty of changes made by humans. But some of those 1145 per day are so low-risk that they’re almost better off making more of them.
It's hard for outsiders and novices to fathom what an assembly line feels like. Elite performers are often cranking things out at a scale that normal people wouldn't believe.
More is not always better though. The simplicity of Stripe that made its success is not there anymore, ask anyone that had to build a stripe integration recently.
I hope they're not using GitHub; my inbox is unusable from GitHub talking to itself and choosing to stand next to me at the party, and we're not [currently] doing anywhere near that volume
I've gotten some handle on it by some gmail filters but holy hell if you want to make sure I don't see something, smuggle it in a From:github.com email
With the new Copilot makes PRs, I could easily imagine getting to 1145 PRs per day, of which 45 will actually make it across the line and not be filled with horseshit
1,145 pull requests per day
(saile.it)115 points by sailE 22 May 2025 | 84 comments
Comments
#3 is "What I Miss About Working at Stripe" (https://every.to/p/what-i-miss-about-working-at-stripe) reminiscing about 15-hour days, missing vacations, and crying at work.
discussed here; https://news.ycombinator.com/item?id=32159752 (131 comments)
Often the problem is that we put too much into a single change. Smaller changes means easier reviews, better reviews, less risky deploys, forces better tooling for deployments and change management, often lower latency, and even often leads to higher throughput because of less WIP taking up head space and requiring context switching. The benefits are so compounding that I think it's very undervalued in some orgs.
I'm sure most people are working on some settings UI, fraud or risk tools, etc.
Yes, regressions will be more painful if you manage trillions of dollars, but it also means shipping a fix for such regressions needs to be easy and fast, which you can only do if you have a good and frequent CI/CD pipeline.
See also "The Infallible five-tier system for measuring the maturity of your Continuous Delivery pipeline". You should live on "Friday".
https://qntm.org/cd
It makes sense for Stripe, they would lose lot of money when not operating. But in smaller companies you can choose to take more downtime to reduce engineering time.
Instead of skirting around doing gradual data transformations on live data, you could take service offline and do all of it once.
I do agree there isn't a lot of delta between a company doing 2 or 10 deploys a day and a company doing 1,200, but, there's a huge engineering gap between companies who do approximately .03 deploys per day and those doing multiple.
Isn't it more like a BS counter that keep incrementing and that is indicative of churn but nothing else reliably.
One of the most low effort, easily to game metric that can be skewed to show anything that the user wants to show.
Like other commenters here have said, it doesn't mean that I can say "(scoff --) we're doing the same" if I'm doing the same relative number of releases with my tiny team. But it is validating for a small team like mine to see that this approach works at large scale, as it does for us.
How many of those prs were small fixes? How many went to low used services, or services only used internally?
They clearly have strong set of tooling for dev ops stuff, and I do believe that stripe has strong technical chops, but this number does not show that they are delivering value. It just shows they are delivery something... Somewhere
But you haven't identified any value, just mindless cited some throughput stat. Merge your code changes in 1-letter increments and you can juke the stats even higher!
If you use tooling like renovate/dependabot and run them daily over a large list of repos, you already get your 1000 PRs automatically, without humans even looking at the codebase.
There’ll still be plenty of changes made by humans. But some of those 1145 per day are so low-risk that they’re almost better off making more of them.
https://web.archive.org/web/20250523000025/https://saile.it/...
I've gotten some handle on it by some gmail filters but holy hell if you want to make sure I don't see something, smuggle it in a From:github.com email
With the new Copilot makes PRs, I could easily imagine getting to 1145 PRs per day, of which 45 will actually make it across the line and not be filled with horseshit
No, unit tests do not count.
Basically, they're bragging about how busy their engineers are making themselves look.