Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1,145 pull requests per day

saile.it

Post reply on HN
Print view View original

51–60 of 91 posts

Re: 1,145 pull requests per day

#51

Post by eviks »

darth_avocado wrote: post #22

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 engineerin…

If it's not impressive why is the article so impressed (it's even in the headline)?

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

Re: 1,145 pull requests per day

#52

Post by smadge »

eviks wrote: post #48

> 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!

One letter increments wouldn’t work because each commit has to leave the program correct. For example committing the first f of a for loop would leave the code with a syntax error. But you often should break up changes into as small as possible commits that leave the code correct. E.g. make one commit that refactors the code (no change in program output), then another change which implements the change in program behavior that motivated the refactor. This generally makes commits easier to review, less likely to contain defects, and easier to attribute bugs and roll back.

Re: 1,145 pull requests per day

#53

Post by smadge »

danpalmer wrote: post #2

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 chang…

> CL

Googler identified.

Re: 1,145 pull requests per day

#54

Post by koliber »

eviks wrote: post #48

> 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!

That would be clearly malicious with the goal of gaming stats and not bringing any value. I doubt that such dumb behavior would go unnoticed for any considerable time.

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.

Re: 1,145 pull requests per day

#55

Post by tough »

thewisenerd wrote: post #42

> 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 #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=…

patio11 is a great read

Re: 1,145 pull requests per day

#56

Post by riffraff »

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".

https://qntm.org/cd

Re: 1,145 pull requests per day

#57

Post by tough »

supportengineer wrote: post #36
chhs wrote: post #13

Earlier quoted context omitted.

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.

I’m going to write myself a new mini van this afternoon

YES! YES! YES!

Re: 1,145 pull requests per day

#58

Post by sailE »

eviks wrote: post #48

> 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'm not sure why the stat is nitpicked that much. Of course you can completely fake this stat. I have no idea if Stripe does or how much LoC or actual functional changes these deployments do. It's just that they are very confident in shipping changes, all with minimum downtime. Constantly, every day. For a company which does a major part of the financial infrastructure of the web, that's impressive.

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.

Re: 1,145 pull requests per day

#59

Post by riffraff »

smadge wrote: post #52
eviks wrote: post #48

> 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!

One letter increments wouldn’t work because each commit has to leave the program correct. For example committing the first f of a for loop would leave the code with a syntax error. But you often should break up changes into as small as possible commits that leave the code correct. E.g. make one commit that refactors the code (no change in program output), then another change which implements the change in program beh…

I forgot who coined the expression but it's a good rule "first make the change easy, then make the change", my top recommendation for incremental changes.
Post reply on HN