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

31–40 of 43 posts

Re: Measuring developer productivity with the DX Core 4

#31

Post by BearOso »

igleria wrote: post #5

> Whether you’re a C-level leader or a frontline manager, there is no denying that measuring developer productivity—whether to understand performance or guide improvement—is a daunting challenge. good Focus on the stuff that matters, not on tormenting the people that make you money.

What stuck out to me with that sentence was that a competent manager can determine productivity by looking at what the developer produced, easily and quickly. If the person has no clue what they're looking at and needs this software then they're not qualified.

Re: Measuring developer productivity with the DX Core 4

#34

Post by anon7000 »

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.

Yes, I’ve worked in companies that use DX. Generally you get a survey once a quarter, and you can see some basic stats like how many PRs/code reviews are happening.

My company leadership does not use these as a one size fits all metric. In fact, the code review & PR stats never even show up in performance reviews. Mainly, they are used to improve systems around dev productivity. Like, we see that generally, we’re shipping less PRs and the survey shows people think it’s getting slow to merge changes. That is an opportunity to look at where our systems are holding us back.

I think broad stats are also probably still useful too. For example, there have been times that I’m reviewing more code than everyone on the team combined. I WANT my manager to know that’s happening and figure out how to even the workload. Or, why is my team shipping like 2-3 times as many PRs as a similar team with similar headcount? It’s not immediately a PIP or something, but it’s highly likely something odd is happening. Could leadership improve direction & focus, make priorities more obvious?

Re: Measuring developer productivity with the DX Core 4

#35

Post by sharts »

With all of these developer productivity metrics, perhaps developer teams can also measure productivity metrics of management up to the top.

When it is decided that a management resource such as a line manager, director, or even C-level exec are causing detriment to organizations they can be put on performance improvement plans —which involves developers simply ignoring anything and everything that person says until they stop speaking nonsense.

This is the way.

Re: Measuring developer productivity with the DX Core 4

#37

Post by brabel »

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…

You are essentially saying there’s only bad data and efforts like those in this post are always bad. Ask yourself why you would hold this position regarding this topic but likely not for anything else. Hint: it has to do with that saying, it’s hard to see something when your job depends on you not seeing it.

Re: Measuring developer productivity with the DX Core 4

#38

Post by boredemployee »

aevv wrote: post #30

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 re…

honestly asking, whats the point of measuring time to first, etc. PR when it is all done by AI these days?

Re: Measuring developer productivity with the DX Core 4

#39

Post by junto »

For many countries in Europe DX is a dead product because we aren’t allowed to monitor individual contributor performance in this way, only performance monitoring at a team level, and the only if those teams are large enough that you can’t distinguish IC’s.

I think that’s a good thing, and I say that as an engineering manager.

Having been an IC, I’m acutely aware that developers, when aware of monitoring via performance metrics, will game that system.

Post reply on HN