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

61–70 of 91 posts

Re: 1,145 pull requests per day

#61

Post by Scramblejams »

smadge wrote: post #53
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.

Maybe! Perforce (standard in AAA gamedev) speak is littered with CLs, too.

Re: 1,145 pull requests per day

#62

Post by qznc »

cuttothechase wrote: post #7

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.

There is research (DORA/Accelerate/DevOps report) that makes a good case that throughput (like number of pull requests) contributes positively to company performance. More precisely the DORA metric is deployment frequency.

Re: 1,145 pull requests per day

#63

Post by qznc »

cesnja wrote: post #60
xeromal wrote: post #6

PRs merged is the LOC count. Completely useless measure of anything really.

Based on DORA research it's correlated with the engineering team/company being a high-performer.

The "Accelerate" book claims it is not just correlation but even causation: Higher deployment frequency causes better company performance.

Re: 1,145 pull requests per day

#65

Post by [deleted] »

SchemaLoad wrote: post #34
AdamJacobMuller wrote: post #12

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

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

[deleted]

Re: 1,145 pull requests per day

#66

Post by arghwhat »

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…

In finance, not making mistakes is not at all critical, and mistakes happpens all the time. Regulatory compliance is critical, as it provides a thorough legal defense even in case of failure.

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.

Re: 1,145 pull requests per day

#67

Post by netsharc »

eviks wrote: post #51
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 do…

I thought the article was going somewhere, it ended up being a very vapid "Impressive, right? Reflect what you can do to accomplish this in your organization".

Well the actual ending is, "Subscribe to my newsletter!".

Re: 1,145 pull requests per day

#68

Post by eviks »

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…

Just a tiny modification and it would work - do one letter increments only for comments

Re: 1,145 pull requests per day

#69

Post by [deleted] »

tonyhart7 wrote: post #46
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=…

wow, so like Asian company culture???

[deleted]

Re: 1,145 pull requests per day

#70

Post by eviks »

sailE wrote: post #58
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…

Because you've put so much emphasis on this stat and imbued it with value without justification, so it makes it very easy to refute (also, the refutation of your central claim isn't a nitpick - this one is)

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

Post reply on HN