GitHub Insights
github.com
github.com
We basically built these metrics with Prometheus and grafana because our review queue kept growing. Now we keep everyone accountable, and make these metrics part of our stand-up meetings.
Our PR queue is now smaller, and review time is shorter. We use these metrics not to point fingers, but to ensure people are not overcommitting, overworked, and that people know how many things they have on their table.
I'm quite glad something like this is now available off the shelf
Perhaps people have little faith in most management, and expect that tools like this will be used to point fingers.
You're not wrong about misuse of these tools being a symptom of bad management, but if 90% of the management in an industry is inclined to misuse such tools, it's reasonable to be dismayed when those tools are made more widely available.
Feels like we, as an industry, already had this conversation in infosec - abot security by obfuscation - which has some parallels here. The conclusion was that hiding things is generally a bad solution to the underlying problems.
When I took a hiatus from my startup a year and a half ago, I learned a lot about code metrics and how it is misused and why there is such a desperation for it. There is a reason why, GitPrime was acquired for about 180 million USD. I don't think it (GitPrime) serves developers well, but it does highlight how desperately management wants to know what is going on.
Since the details on "GitHub Insights" is pretty much hidden (unless you are willing to pay for it), I can't speak much for how "developer centric" it is, but if the focus for "GitHub Insights" is to appeal to developers as well, then I think it will go a long way to make software metrics a good thing for the industry as a whole.
Right now I'm keeping things under wraps, but I've attached some screenshots of what kind of metrics you can surface that can help developers. Note, the screenshots are not the final product, as the product is still being heavily refined. And what makes my solution unique is, everything can be validated. That is, if you want to have a conversation around why a piece of code (or codes) had such a high churn, you can drill down to the source code level to see how the changes were derived.
As I mentioned early, I've been studying code metrics for a while and I strongly believe you will need developer buy in, if you want any chance of success with code metrics. So in my opinion, how positive/useful "GitHub Insights" is, will depend heavily on how developer friendly it is.
Maybe fear for even more corporate bullshit interfering with the already difficult job a developer has to do?
> confusing bad management with metric visibility
Hmm not so confusing IMO. And what is your definition of 'bad management'? Most management I've worked with as a developer have no clue about coding and the complexity we're working in. These metrics could be valuable for someone who knows more about the complexity of the underlying technology and what is needed to actually make the PR happen.
To each their own, if your team likes it, fine. If they just tolerate it because the decision came from above, yikes, what a nightmare, more management surveillance.
I would look for another job.
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!
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 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.
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.
They gotta find a reason compelling to executives for the crazy costs.
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.
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.
Developers are rarely in control of a product's features.
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.
What we've seen is that engineers inherently want to be productive, and are happiest when they can work friction-free. Unfortunately, it can be quite difficult to get visibility into roadblocks that slow down developers (e.g. overly nitpicky code review, late changing product requirements, slow/flaky CI), especially for managers who are one or two levels removed from programming. These are situations where data-backed insights can be helpful for diagnosis.
After diagnosing issues, with data or simply qualitative insights from a retrospective or 1:1, we also see teams sometimes struggle to set goals and achieve desired improvements. A common theme is the recurring retrospective item that people agree is important but doesn't seem to be resolved. When it comes to implementing improvements, data can be useful to make objectives concrete and make progress visible to the entire team.
It’s important that metrics do not become the objectives themselves, but rather serve as a way to demonstrate the true outcome was achieved. Metrics also are not a strategy, and quantitative data cannot be used alone to understand performance of teams.
When quantitative data is used properly in combination with qualitative information, strong communication, and trust, we’ve found the results can go beyond what can be achieved without metrics.
How do you achieve that?
I've always seen the exact opposite.
It is very tempting to measure things, use more data to better understand the world, and in this case, the state of a project.
But you can't. The world is too complex, too rich, too noisy.
https://en.wikipedia.org/wiki/The_Treachery_of_Images
https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation
https://hbr.org/2017/11/many-strategies-fail-because-theyre-...
Their top recommendations are: A) Communicate the logic behind what you are trying to achieve; B) Make strategy execution a two-way process, not top-down; C) Let selection happen organically, through systems that cause strong initiatives to rise up to to the top; D) Find ways to make change the default, to help move beyond the status quo and existing habits
Am I paranoid?
For me this the signal that it's time to opt-out from vscode and github.
I was really impressed with the work done on vscode, the performance was really good for a hosted web-app.
Devs complain about exec picking irrelevant metrics to evaluate them (and they're right), but what I see even more often is teams full of inefficiencies that like being a black box and don't want to make an effort to introspect and self-improve. Often they're barely teams, they are just a collection of devs working on the same thing
I'm happy this tool exist and I'm sure my team will be better off because of it.
There is currently no way to get notifications when you're assigned as a reviewer or when someone reviews your code.
I have the Github app on my phone and they don't alert me! I want a slack integration that feeds my activity to me.
It's nuts. Absolutely bonkers. How is this not a thing.
Can new users and organizations still sign up?
Pull Panda is no longer accepting new sign ups.https://github.blog/2020-04-21-stay-on-top-of-your-code-revi...
https://help.github.com/en/github/setting-up-and-managing-or...
- Bill Gates
I feel like I'm the guy in the comics who takes advantage because they tried to roll out something like this in my work and I figured out you could get more points by sinking other teams than actually writing code.
After voicing it in a meeting, it magically went away.
It's currently in beta, but it looks really cool!!
Kindest regard Founder of Sigmetic ;p