Heya <@U037K9CG84A> - Solid gold wisdom - we've ha...
# developer-productivity-engineering
j
Heya @Adam Woods-Mccormick - Solid gold wisdom - we've had a couple of requests to reiterate from the live session some of the most important metrics that Meta uses to determine developer productivity. Could you list a few of them here when you get a moment! Thanks!
🙌 2
thank you 1
a
Sure. First and foremost, it's worth reiterating that we goal on company health metrics more than productivity so these are measures we try to improve but not independent of those. Sad Users , time spent, and Daily actives are the kings Some big metrics we look for: • Focus time: how much time do people spend in flow versus meetings or fighting tooling. This can get really big-brothery if you look at it individually, but it's healthy to improve on aggregate. We also surface this to each person for their own planning and scheduling. • Daily fragmentation: how much of people's day is in usable blocks of time. problem solving (and therefore writing software) requires a bit of spin-up to be effective so short blocks aren't useful. We even suggest meeting schedules based on optimizing for the least focus-block-reduction. • Diff Lifecycle: we measure how long diff's spend in draft, in published without review, accepted but not shipped, shipping before landing, and feedback cycles. There's no "right" timing for every diff, and it's more art than science. In general the less time code spends between publishing and landing the better everything goes. We also use this to "nag" about diffs that aren't getting review.
A few popular metrics I would suggest staying away from: • Time spent in Draft: This ends up being a nonsense metric because everyone approaches the dev cycle differently. Some folks create diffs as placeholders before the code is written, some always publish immediately, neither one is better • Number of diff comments (received or given): The complexity and bug rate of code doesn't correlate with the number of comments on the code reviews. There's a real bikeshedding problem with less complex diffs because people want to show contributions where some diffs that need scrutiny are often approved on trust • Code volume/velocity: It's always better to focus on the rate that value is delivered than the speed or volume of code. Sometimes the most impactful thing a dev can do is done with very little code changed.
m
@Adam Woods-Mccormick How do you concretely actually measure focus time?
a
@Max Kanat-Alexander In our case, a big chunk of that is that all of our internal tools are instrumented and work together to give us a full picture. We (and by we I mean teams specifically targeted at productivity) can see how much time a given user spends on each of our internal tools (IDEs, Internal Web tools, Company Social media, Scheduling, VCs) and that gives up a picture that's quite clear as to how our people work. I want to be very clear that we absolutely never surface this as part of managing people, only in terms of driving aggregate increases. Goodhart's Law rules in the productivity space.
m
Great, thanks! For the IDE, is it being done with a plug-in for each IDE? Like, for Xcode for example, I don't know how you would measure IDE usage.
a
@Max Kanat-Alexander I'm not intimately familiar with the technical specifics here, but our customization of the IDEs is quite deep.
m
Okay, that makes sense. So people are using your builds of IDEs, basically.