Remix.run Logo
danpalmer a day 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 a day ago | parent | next [-]

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

danpalmer a day ago | parent [-]

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 19 hours ago | parent | prev [-]

> CL

Googler identified.

Scramblejams 19 hours ago | parent | next [-]

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

solumunus 11 hours ago | parent | prev [-]

What is a CL?

Balinares 10 hours ago | parent [-]

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.