When GitClear users need to express "how much work got done," it's useful to pick units that convey some intuitive amount.

Software researchers would assuredly agree: it's "easier said than done" to present a relatable "how much work" benchmark. In spite of it being hard, GitClear believes it would be sufficiently useful to have a "relatable unit of developer progress," that we are doing the research/work to substantiate such a unit in this document, the "Facebook React Day." Note that GitClear is not associated with Facebook/Meta in any way, but we think the success of their React project makes it delightfully relatable as a point of comparison.

linkExisting options for relatable developer work measurement are poor

Take the "atomic unit" of change history, the git commit. A commit is a readily counted unit, and count it many managers do -- to the dismay of their dev team. Why do teams (including Senior Devs) hate this metric? Because it can mean anything from "a single line change" to "refactoring a library." It is not a sane exercise to try quantifying how much work one commit represents.

"Changed lines" are worse -- about ~96% noise, by our calculations. Nowhere to gain purchase as a relatable measurement of work.

linkDiff Delta has remained stable over half a decade

Research has suggested Diff Delta can be a more stable alternative to "commits" & "changed lines". Since it strips away the noisy code lines, and attempts to compensate for the differences in "effort per meaningful line changed" across file types, it has enough day-to-day stability that it's plausible to relate it to intuitively known software.

In fact, in our Diff Delta Benchmarks article, we related around 30 different levels of Diff Delta to various publicly-visible products. If you'd like to become fluent in "how much work does a Diff Delta number mean?", the combination of the Benchmarks article and the Industry Stats table are a great combination:

open_in_new

These numbers fluctuate somewhat from year to year, but the median day has remained stable around 100

While the exact week-to-week measurements for the largest tech companies vary, what has remained stable from 2020-2024 has been been that the median developer, across all domains, has averaged around 500 Diff Delta per week, or 100 per day.

Still, knowing that an average day yields around 100 Diff Delta of change does not connect to an intuitive, real-world object of measurement. Thus the Facebook React Week.

linkIntroducing "Facebook React Day": our recommended unit for expressing how much change is implied by a group of commits

Most people are familiar with the Facebook's React project. It is the open-source library behind a meaningful percentage of the interactive components we interact with in our web travels. React helped usher in the "declarative over imperative" era of web development, and for that (not to mention hot reloading), we are very grateful to Facebook's tech leadership. It surely was a lot of work to keep it on track, even as its developers and conventions have evolved over many years.

What has remained relatively consistent over the past 5+ years is Facebook's relentless progress evolving React:

open_in_new

Over the last three years they averaged 948 Delta per weekday, over the 3 years before, they averaged 1050 Delta. Average them.

While the month-to-month progress has had its ebbs and flows, when zoomed out, the past 6 years have averaged out to almost exactly 1,000 Diff Delta per day. Convenient!

Since people see React change over time, with the introduction of new concepts like useState, it's possible to hone something of a visceral sense for how much change work is going in to building React. If a developer implements a ticket that spans 1 Facebook React Day (FRD), it is a relatively large implementation by the standard of many teams. The default "warning" threshold for a pull request being "too large to conveniently review" is 500 Diff Delta, 0.5 FRDs.

While one FRD is a fairly large unit, we use it as the basis for many contexts where the Diff Delta of a group of commits needs to be represented in a filled bar. One aspires to choose a "filled" value that will rarely be reached, since maxing out the bar truncates the precision with which "developer change energy" can be represented.