3 ms·

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

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 1y ago
I think better tooling for deployments allows small changes. Not the other way around.
- danpalmer 1y 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.
smadge 1y ago
> CL Googler identified.
- Scramblejams 1y ago
  Maybe! Perforce (standard in AAA gamedev) speak is littered with CLs, too.
- solumunus 1y ago
  What is a CL?
  - Balinares 1y ago
    Change list. It's a Perforce term approximately equivalent to "PR", but also, perhaps more familiarly to the HN audience, the term used at Google with the internal fork of Perforce that powers its gigantic monorepo.
    - danpalmer 1y ago
      Further to this, CLs are essentially a single commit, which means that they are often (but don't have to be) smaller than a PR that might contain a stack of commits. You don't generally do as much rework in later CLs like you might with git commits, generally you'd do all your development iteration on the same CL, rewriting it until it's ready, rather than stacking many commits like in git.

polishdude20 1y ago

I think better tooling for deployments allows small changes. Not the other way around.

danpalmer 1y 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.

smadge 1y ago

> CL Googler identified.

Scramblejams 1y ago
Maybe! Perforce (standard in AAA gamedev) speak is littered with CLs, too.
solumunus 1y ago
What is a CL?
- Balinares 1y ago
  Change list. It's a Perforce term approximately equivalent to "PR", but also, perhaps more familiarly to the HN audience, the term used at Google with the internal fork of Perforce that powers its gigantic monorepo.
  - danpalmer 1y ago
    Further to this, CLs are essentially a single commit, which means that they are often (but don't have to be) smaller than a PR that might contain a stack of commits. You don't generally do as much rework in later CLs like you might with git commits, generally you'd do all your development iteration on the same CL, rewriting it until it's ready, rather than stacking many commits like in git.