7 ms·
> "What should we measure to improve developer productivity?" How about nothing? Honest question. I am sick and tired of being treated like cattle. I've never
by Cardinal7167 4y ago
> "What should we measure to improve developer productivity?"
How about nothing? Honest question. I am sick and tired of being treated like cattle. I've never seen a single convincing argument that any metric of my outputs has mapped to some productivity metric in a meaningful way, but I have absolutely seen them weaponized against me and others to punish and fire engineers. All of these metrics have only ever boiled down to a negative reinforcement mechanism, in my experience.
- yamtaddle 4y agoBut if you don't measure them—or if, god forbid, you give them their own offices with doors—they might start to think they're in the professional/upper-middle class, not the middle class!
- hcarvalhoalves 4y agoThis doesn’t work, because then your company would have to measure your value by the value you deliver. That would probably mean having to compensate people like you way better, because software engineers can create immense value. Of course this can’t happen, as we apparently live in a universe where only management have bonus based compensation.
- astrange 4y agoWho’s we? FAANG engineers have bonus and stock compensation.
- geekjock 4y agoI'm a developer and am right there with you. But if you're a decades-old corporation with 10,000 engineers, you need some set of signals to help guide improvements to tools and processes, right? This benefits developers, and there should be a set of signals to enable this.
- closeparen 4y agoYou need objective, measurable signals if you are concerned that developers might be confused or lying. Otherwise you can just ask us. Most people are happy to tell you what the pain points are in their workflow and how they compare to last year's. Maybe you need metrics to quantify specific complaints like "slow" or "crashes a lot." But I feel like most organizations doing this kind of measurement are looking for some kind of Freakonomics "developers think they want X, but what makes them better is actually Y" when they haven't even bothered to ask about, let alone implement, X.
- impute 4y ago> You need objective, measurable signals if you are concerned that developers might be confused or lying. Otherwise you can just ask us In an organization with hundreds or thousands of developers, there will be people either lying about how productive they are or genuinely think they are performing above average when they are not. It's like how 80% of people think they're above average drivers. On the other hand, you may have excellent developers that are overly modest or not loud enough to sell themselves. They are truly exceptional and above the curve and should be rewarded for that. Some of the 20% of drivers that don't think they are above average may actually be above average. Objective, measurable signals help to find the outliers at the ends of the curve that may otherwise be missed.
- closeparen 4y agoIt doesn't matter what percentile developer you are to guide improvements to tools and processes. It matters what slows you down.
- dalyons 4y agoIn healthy orgs you are collecting such metrics to help advocate for investing in tooling, automation, infrastructure, process improvements etc. It can give the business case for building/expanding dev tooling and cloud teams. I’ve found it helpful in past jobs… fully weighted dev salaries are so high, at a moderate sized org a little bit of rough efficiency math can make for obvious investment cases.
- Kamq 4y ago> In healthy orgs... This is, so far as I can tell, ~5% of them.
- senguidev 4y agoIMO some ~objective feedback of reality is good though. Probably not easy to set up without having it quickly turn into a negative reinforcement loop indeed. But let's not forget that, with the right supporting culture, it can be helpful (pleasant?) to the dev to have some metrics. I admit "how to do that?" remains unclear.
- pixl97 4y agoSo how do you deal with bad developers? How do you even measure if they exist in your organization. And as much as many of us on HN are developers and like to toot our own horn, some of us suck and don't get better with time. I mean in small organizations this is typically easy to figure out, but in larger organizations it's a problem that can persist for long periods of time.
- Cardinal7167 4y ago> So how do you deal with bad developers? The same way we deal with good developers? With managers, of course. That's the whole point of their role. Every developer productivity metric I've seen speaks to some disparity between engineering and the C-suite. I don't understand where these products originate that seek to do the manager's job for them but worse. I've been in management roles before, the numbers don't and can't always tell you the full story, no matter the size of the team or the quality of the data. As always, good people are hard to find.
- impute 4y agoWhat if the manager is bad? Metrics can help other people identify that a bad manager may not be identifying very good developers.
- ajmurmann 4y agoIf the manager is bad, we should address that by discussing metrics to measure manager success and identify three bad managers, work with them on improving and fire them off it doesn't help.
- naasking 4y ago> So how do you deal with bad developers? How do you even measure if they exist in your organization. Ask the developers that work with them? Who likes working with someone that isn't pulling their own weight, or worse, that is just making your own work harder?
- lylejantzi3rd 4y ago