Live data from Hacker News

1,145 pull requests per day

saile.it

71–80 of 91 posts

Re: 1,145 pull requests per day

#71
post #13

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.

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.

It will be gamed soon if it isn't already

Re: 1,145 pull requests per day

#72

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.

One PR every three days, while interesting for what it says about their development, has nothing to do with performance.

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.

Re: 1,145 pull requests per day

#73
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.

Re: 1,145 pull requests per day

#75

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

Incorrect, shipping a fix quickly is relatively irrelevant, being able to roll back a busted change to a working configuration is critical.

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.

Re: 1,145 pull requests per day

#78
post #49

Lol, yeah but a PR won't fix that expired cert.

I get this comment sometimes and also other comments saying it 404s. The site has been up for years but seems there's still some old DNS floating around. Or some misconfiguration on my side.

This is due to one of your AAAA records: ::ffff:157.245.83.16. (The other one is fine.)

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/"
GUI:

- https://www.ssllabs.com/ssltest/analyze.html?d=saile.it

- https://toolbox.googleapps.com/apps/dig/

Re: 1,145 pull requests per day

#79
post #10

I would think they have elite testing and QA team to make that happen

Maybe counterintuitively, most big tech companies have no dedicated QA & tester roles, rather, they encourage engineers to think about software quality while developing product.

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

Re: 1,145 pull requests per day

#80

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…

exactly.
Post reply on HN