Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Measuring developer productivity with the DX Core 4

getdx.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Measuring developer productivity with the DX Core 4

#21

Post by Cthulhu_ »

pipes wrote: post #15
lbriner wrote: post #11

Developers don't like being measured for good and bad reasons. The good reason is that there is lots of effort that we expend that isn't always captured in metrics like long pieces of design or training others etc. The bad is that we don't being told that we aren't as productive as other people even if we are! My experience is that these are only useful over a long enough period and across enough people that we can s…

Also trying to reduce productivity to some thing as silly as pull requests per hour etc ignores valuable contributions else where. Design, push back, quality, mentoring, leadership. I thought that is why meta had the "coding machine archetype" and other archetypes, recognising that just PRs aren't the only measurements.

From my limited experience with this tool / DORA metrics, it's not so much about performance (PRs per hour) but more about whether you can act fast if you need to. But I'm not sure what the other metrics are about.

Re: Measuring developer productivity with the DX Core 4

#22

Post by tripledry »

BoxOfRain wrote: post #19
brabel wrote: post #14

Earlier quoted context omitted.

I think metrics can be used for good. For example we are constantly try to improve our dev experience, but how do you know if you are improving anything? Developers are notably inaccurate in reporting efficiency. Unfortunately flying blind is not really an option when you need to justify paying for tools that claim to improve productivity.

Surely no data is better than bad data? What's the point of a metric that doesn't measure anything tied to the objective reality of what it is that you're measuring? All I see tools like this doing is getting people to manipulate the metrics, while at the same time producing enormous amounts of worker alienation. I'd even speculate the demoralising effects of workplace surveillance schemes undermine the alleged produ…

I see more of people using data and bad metrics to justify whatever they want to push rather than genuinely trying to improve conditions.

I don't have any data to prove this :)

Re: Measuring developer productivity with the DX Core 4

#23

Post by tripledry »

pipes wrote: post #15
lbriner wrote: post #11

Developers don't like being measured for good and bad reasons. The good reason is that there is lots of effort that we expend that isn't always captured in metrics like long pieces of design or training others etc. The bad is that we don't being told that we aren't as productive as other people even if we are! My experience is that these are only useful over a long enough period and across enough people that we can s…

Also trying to reduce productivity to some thing as silly as pull requests per hour etc ignores valuable contributions else where. Design, push back, quality, mentoring, leadership. I thought that is why meta had the "coding machine archetype" and other archetypes, recognising that just PRs aren't the only measurements.

And if you start measuring amount of commits or PR's I'd bet money on there suddenly being smaller PR's and more commits. As soon as the metric is tied to peoples livelihood, it will be gamed.

Funny anecdote: I had a large company selling their LLM tools with a slideshow starting with a mention of Goodhart's Law, and then proudly present number of PR's as a metric in the next slide.

Re: Measuring developer productivity with the DX Core 4

#24

Post by Anonyneko »

stiray wrote: post #10

I would like to present DX team another metric. It is called "not wanting to work in a company that is insulting me with measures like metrics, spying on screens, squeezing every drop of sweat and exploiting its workers for already huge profit. My last job change was exactly due to company acquisition by USA company that started to exploit everything work related, removing wfh, ruining life-job ballance,... And who l…

That's exactly what they're introducing all of that crap for, to make people quit voluntarily, layoffs are more expensive...

Re: Measuring developer productivity with the DX Core 4

#25

Post by data-ottawa »

jcarrano wrote: post #6

Did anyone here ever worked under these sorts of "metrics"? I can't even imagine what a torture it would be.

Basically every company I’ve worked for has had some sort of rubric like this. I don’t think that’s inherently bad, it can be quite good for consistency.

I have quit companies that made their performance review systems too onerous/frequent/intense. It’s exhausting to constantly be justifying your existence and having to sell yourself instead of doing the real work.

At one point I was at a 50/50 ratio of time spent documenting/justifying my work vs doing my work, and that was miserable. My level of anxiety reduced my job performance, which created a very unhealthy cycle. Pressure creates diamonds but it also suffocates and crushes most things.

That’s why seeing things like in-context sampling in the article make me suspicious. I don’t think I would be happy at all being interrupted as I’m in flow state to be asked if I could be more productive. I also feel some of this like speed (“time to 10th PR”) or working on new stuff is creating bad incentives.

Fundamentally the most important metric is how hard your boss will fight for you. The second most important metric is whether you can meaningfully discuss areas of improvement honestly and safely with your boss.

If either of those two are out of whack you should question whether to make a change. If I’m missing those I’m not going to be able to do my best work, so it cuts both ways.

Re: Measuring developer productivity with the DX Core 4

#28

Post by greenchair »

zeroc8 wrote: post #13

The problem is that there are so many people involved in software development who have never developed anything but still somehow are in the position to manage others who do. That's why there are so many stupid ideas floating around.

Probably also related to the fact that many devs don't want to switch to the mgmt track.

Re: Measuring developer productivity with the DX Core 4

#29

Post by [deleted] »

stiray wrote: post #10

I would like to present DX team another metric. It is called "not wanting to work in a company that is insulting me with measures like metrics, spying on screens, squeezing every drop of sweat and exploiting its workers for already huge profit. My last job change was exactly due to company acquisition by USA company that started to exploit everything work related, removing wfh, ruining life-job ballance,... And who l…

[deleted]

Re: Measuring developer productivity with the DX Core 4

#30

Post by aevv »

my current place uses DX and it's well received, if done transparently and for the right reasons. there's a lot of very interesting research in these areas (e.g. EngThrive) where the focus is on measuring things that if gamed result in better outcomes

there's strong correlation when onboarding an engineer between the time to first/tenth/fiftieith PR and their PR throughput two years later, so the answer is make it really easy to do PRs when onboarding, and they saw the same outcome even if those initial PRs were trivial

through DORA/SPACE/DevEx they also found that asking your engineers if they feel productive is generally as useful and reliable than trying to measure every possible dimension - which is why DX is based largely around the survey with subjective responses. if you actually use those responses to address friction and frustration, from my experience you end up with more, better, easier work getting done

it's possible to work in a team that cares about measuring their effectiveness, and using those measurements to understand how to be more effective. most/all engineers will have an idea of how they could improve their work, but the reality when you actually spend time to measure often shows a lot of different things you might not have been aware of

Post reply on HN