Hacker News Reader

Comment by aupright | Hacker News Reader

For those worried about the data being used maliciously, it looks like most of the metrics they'll be introducing are focused around things that can actually help unblock teams and aren't focused on individual contributors. Eg. distribution of code reviews across team members for better load balancing, average code review turnaround times across the team.

It also looks like you'll be able to proactively set goals for some of these insights as well to improve over time. I can see where this can go awry, but optimistically this should help teams better measure and improve their process!

View on HN

I'm really happy for your sake that you've never dealt with the worst case scenario of an organization utilizing this type of product.

I also feel great pity for you knowing that you have no idea how to deal with an organization utilizing this type of product.

I hope that the industry continues to fight against these bean counter products and produce higher quality developers in the future so that we can preserve the innocence of people like you.

Nope, fuck this.

The moment a product mentions "From developer to CEO" (ie. includes the word "CEO"), this is bad news. As soon as you introduce any metrics involving "participation awards" (whether based on lines of code, commits, reviews/pull-requests, etc.), the company is doomed to fail at understanding how productivity/worth is measured in the development world.

The fact they even mention "CEO" in their tagline is all one needs to know. There is not a single CEO in the world who should give a goddamn shit about actions taken at the source control or release level. It's all marketing drivel intended to promise management that the product being sold can somehow deliver insight into a world they will never understand. The fact is developers will just waste time inflating their metrics to satisfy productivity algorithms, while costing the business time–and therefore money–developers could have spent actually improving the product.

I'm inclining on agreeing. Gaming commit counts and commit graphs on GitHub is already a thing. I've been asked by many recruiters why my commit graph on GitHub has gone stale, when I've worked at places that don't use GitHub, or if my commits are 99% of the time towards private repositories.

I can already see the resumes of developers touting their statistical brilliance from metrics gained from this tool. It's not a world I want to be a part of, to be honest.

For the past 10 years I worked for companies with NDA and exclusivity clauses in the contracts.

I can only describe what I worked on superficially, I cannot contribute to other projects because all code I produce (even off-hours) that has my name attached to it is company property.

My GitHub and BitBucket profiles are bare, save for bug reports.

Every time I get interviewed I have to explain why my résumé is not more detailed and why I don't contribute to the open source community.

Stack ranking at it's finest.

If I were a CEO of a technical company and my company did a major change, say switching release strategies or adopted microservices vs monolith, these type of global metrics could indicate the benefits, or a problem. I agree that drilling down on individual people or trying to optimise blindly is the wrong move, but I think you're taking too much of a negative view on this. Shitty people will use more powerful tools for their shitty purposes, but that doesn't mean we should keep our tooling crappy.

I mean,the feature is part of GitHub One, which itself seems to be a premium version of GitHub Enterprise.

They gotta find a reason compelling to executives for the crazy costs.

Most metrics measuring code are bad.

However, we have to try to come up with some. The idea that if you simply take away the metrics we will automatically improve the product is flawed.

Consider rewrites that burn a year of time for dubious value. Or fancy "refactors" that are really big heavy redesigns that lock you into abstractions that don't make sense in six months. Or devs that open 2000-line after 2000-line pull request...

At that point, code metrics aren't just about performance management, it's about me wanting to make sure I'm actually moving the code in the right direction.

Something I'm very interested in is if dev commit patterns line up with different types of work, and if some of those are "behavior smells" - e.g., not refactoring things one at a time, and getting your tests happy in between each move.

I'm not sure. If the majority of the metrics give a false or misleading sense of reality, then maybe taking away the metrics would be a net win. It's entirely plausible that the whole system of measurement we've come up with in this domain is fundamentally flawed and has more costs than benefits (see financial system risk ratings circa 2008). The skepticism of new metrics could very well be warranted until there's a real demonstration of success and good faith in their use.

As a profession, developers are likely more responsible for imposing mechanical, inhuman metrics and instrumentation on society than anyone since double-entry accounting was invented.

Everything from upvotes/likes/internet points to in-house fraud detection to click tracking to Captchas to facial recognition and tracking... Of course programmers are going to emit signals that those signing checks are going to take interest in.

I recommend you learn to live with it, everyone else has to.

That's like saying construction workers have been imposing bridges on everyone.

Developers are rarely in control of a product's features.

Reply on news.ycombinator.com