#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)
The lack of efficiency in finance (or pharma for that matter) is not driven by a wish for quality, but purely from a fear of stepping outside regulatory compliance with no individual wanting to be responsible for any process optimization that could later be seen as non-compliant.
Younger companies on the other hand might realize that compliance controls are, in fact, something the company defines themselves and can structure and optimize however they'd like, allowing for both high throughput and compliance. It's just hard to implement in older companies where half the staff would fight back as their role exists purely due to poor processes and their overhead.
And no, not making any mistakes isn't critical, ... some are. You can have a million of UI mistakes and regressions (where is the stat for how many regressions there are?) and what not in the UI of you Stripe Dashboard app without any of them being critical. The "finance" aura doesn't permeate literally everything a finance company does, raising it to the critical level
Well the actual ending is, "Subscribe to my newsletter!".
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.
Googler identified.
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".
The exception is security issues. But these usually require actual thinking to be fixed, so no, you're not getting volume in the first place.
Preferably not breaking things while doing your mostly cosmetic or preparatiry changes rather than patching afterwards limits the scope of this kind of fix churn. And how to know you didn't? Proper functional and integration tests is how.
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.
This is the important metric. It means there is very little divergence between what’s being worked on and what’s in production. The smaller the difference, the quicker you deliver value to users and the less risky it is to deploy.
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!
The article states that this comes out to be one deployed PR per 3 days per developer. That is clearly doable and does not require any dumb moves like parent suggests.
In my opinion the goal isn't getting to some arbitrary number, it's making this possible. That there are no process/technical/cultural impediments not allowing you to do changes every single day.
And you're doing it in this comment again. No, it's not impressive without some actual knowledge on what the changes are about their value. It may very well be that people are heavily pushed to make changes for the sake of making changes, and most of them are not that useful. Or it may be that, as is common with overworked people, they make a lot of mistakes that require further changes to correct them (ok, not the types of mistakes that affect reliability stat much, but then that's not the only category). Or they experiment way too much with those experiments leading nowhere, so it's just wasted effort. Or...
The daily goal is just as artificial. There should be little impediments to implement valuable changes, not to do something daily
If they're doing some sort of strict continuous integration, then, a "change" could be a 25 lines function with a 100 lines of unit tests, in the frame of a large project where the function will be used later in a UI component that will only be merged in two weeks.
The fact that it's "deployed" does not mean it's "used" in production as a final thing ; it might very much be "a step in the development".
And, even if they're shipping "feature" (that is, they're deploying the last commit in a project), it does not mean that all millions of users are seeing the change (they could use feature toggles, A/B testing, etc...)
Seen this way, about 2 PRs per day per eng is not unreasonable, and with enough devs, you can reach it.
Finally, they might very well have some automated PRs (i18n, etc..)
Downside: your code is always a Frankenstein monster of feature flags that need to be cleared up! But hey that's more PRs to boast about.
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 had a day last week where I put up ten small PRs. It'd be a bit silly to say I was especially elite that day. I was just making small semi-related PRs for a routine task.
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
See the book "How Google tests software" (by James A. Whittaker, 2012) and the Pragmatic Engineer blog has a good post on how big tech does QA: https://newsletter.pragmaticengineer.com/p/qa-across-tech
No, unit tests do not count.
Basically, they're bragging about how busy their engineers are making themselves look.
CLI:
dig aaaa saile.it
curl -v --resolve "saile.it:443:[2a04:4e42:2::775]" "https://saile.it/1145-pull-requests-per-day/"
curl -v --resolve "saile.it:443:[::ffff:157.245.83.16]" "https://saile.it/1145-pull-requests-per-day/"