> 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
>Web sites prove their identity via certificates, which are valid for a set time period. The certificate for saile.it expired on 26/04/2023.
Does an expired cert count to a downtime?
darth_avocado · 3h ago
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.
danpalmer · 6h ago
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.
polishdude20 · 5h ago
I think better tooling for deployments allows small changes.
Not the other way around.
danpalmer · 5h ago
That's sort of what I mean by small changes being a forcing function. The tooling we have available rarely makes this level of small changes untenable, it's just clunky. When you send 1k PRs a day though you'll notice things that are too clunky and fix them, and then that makes it easier to get to and maintain that level of productivity.
sverhagen · 1h ago
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.
coolcase · 45m ago
Yeah I get itchy if the pipeline to prod ain't working for more than 24h for one microservice. I love continuous deployment.
cuttothechase · 4h ago
Is counting the number of pull requests a useful measure of engineering performance ergo product performance and company perf?
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.
JimDabell · 36m ago
> With some napkin math assuming a similar distribution today, that would mean on average each engineer ships at least 1 change to production every 3 days.
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.
panstromek · 46m ago
By itself not, but combined with the rest of DORA metrics it's a pretty good indicator.
chhs · 4h ago
In my org they count both the number of pull requests, and the number of comments you add to reviews. Easily gamed, but that's the performance metric they use to compare every engineer now.
supportengineer · 48m ago
I’m going to write myself a new mini van this afternoon
darkmarmot · 2h ago
good god, i would quit in a heartbeat.
nitwit005 · 2h ago
How many of those people are actually working on the core payments flow that they're measuring the uptime of?
I'm sure most people are working on some settings UI, fraud or risk tools, etc.
xeromal · 4h ago
PRs merged is the LOC count. Completely useless measure of anything really.
hellojimbo · 4h ago
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.
coolcase · 37m ago
It is good for ballparking. PR count is more interesting as if it is high it means you must have a good CI CD pipeline. I worked places where there were limits on commits a day due to monolith plus master CI/CD taking an hour. You then end up thinking of strategies like "I'll do that in the afternoon and get it to that state and it gets merged at this time" and so on. Which is inefficient.
AdamJacobMuller · 4h ago
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.
SchemaLoad · 1h ago
Open source projects can be the worst at this stuff. I realise it's all volunteer run so I'm not complaining too much. But so often they end up pushing a versioned release once a year. So you end up finding a bug, going to report it and see it was fixed 8 months ago but still broken in the published package. And then they get afraid to push a new version because it's been so long since the last one that everything has changed.
TowerTall · 1h ago
Why do they need to change their software that much that often?
phtrivier · 40m ago
It completely depends on what they call "a change", and the article does not make that clear.
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..)
coolcase · 41m ago
Not every PR is a feature. There will be lots of laying groundwork. Stuff going in but not yet activated as a feature flag. Small changes often make roll back easier. Regressions easier to detect. You can blue green your little change and auto detect if it is causing latency or availability issues on 1% then 10% etc. of traffic. This means you can early detect and do easy roll backs as nothing much has changed.
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.
dgrin91 · 4h ago
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
metalrain · 2h ago
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.
madduci · 2h ago
Is there any description of Stripe's architecture and infrastructure somewhere published?
We do a lot of PRs as well. Most are automatically created and pushed.
sandspar · 30m ago
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.
Sytten · 3h ago
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.
revskill · 1h ago
Non engineers stop that from reality.
mdaniel · 4h ago
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
superblas · 2h ago
FWIW you can go to settings on GitHub and select what you get emails about. There may even be a digest option such that you get one email per day with all the stuff you would’ve received individual emails about IIRC.
burnt-resistor · 3h ago
Impact is what matters. Not PRs/diffs or LoC. These are PHB KPIs.
Basically, they're bragging about how busy their engineers are making themselves look.
ijidak · 2h ago
PHB? Pointy haired boss? My first time seeing this.
aaronax · 2h ago
Yes, Dilbert comic reference.
xena · 4h ago
404
mudkipdev · 4h ago
Working fine for me
m3kw9 · 4h ago
I would think they have elite testing and QA team to make that happen
webprofusion · 4h ago
Lol, yeah but a PR won't fix that expired cert.
compumike · 33m ago
... but a small PR might warn you when your renewal automation breaks, before the cert actually expires: https://heiioncall.com/blog/barebone-scripts-to-check-ssl-ce... (a small blog post I wrote with example scripts for checking SSL cert expiry from Bash, Python, Ruby, more) ;)
scripturial · 1h ago
It will if your certs are managed via a git repo.
m3kw9 · 4h ago
Sure, looks cool but really means nothing without looking at the type of changes. I could think of many tricks if I wanted to chase this stat
userbinator · 3h ago
How often and how much you change your codebase is not something to brag about.
#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)
Does an expired cert count to a downtime?
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.
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.
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.
I'm sure most people are working on some settings UI, fraud or risk tools, etc.
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.
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.
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
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.
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
Basically, they're bragging about how busy their engineers are making themselves look.