>Most self-styled experts on developer productivity seem more interested in selling something rather than painting an accurate picture of how devs really work.
Says a blog post from a CTO who sells a product to track software productivity.
Says a blog post from a CTO who sells a product to track software productivity.
We do have a feature (https://about.sourcegraph.com/code-insights) built around code search that lets devs define their own metrics around things like progress of big migrations and anti-patterns + code smells. This tweet is a good summary of my philosophy around code-related metrics: https://twitter.com/beyang/status/1524259425451577344.
Insights from treating code as data are best discovered by the people who know the dataset through and through—i.e., developers. Another project we've released in this vein is https://codestat.dev, built on top of Comby (incidentally also on the HN front page right now), which was created by a member of our team, Rijnard, as part of his PhD thesis on automatic program transformation.
We're developers by trade and by heart, and are motivated by making tools and mental models that devs actually find useful and that boost the creative spark of coding. If there's something we can improve about our product or message to further this mission, I'd love to hear your feedback!
Most orgs kill productivity and creativity with lack of compensation, treating them like a code farm, or mediocre peers.
Devs choose to be productive in different environments, most of the time it’s simple, step aside and let the dev do more than code. Talk to a client (yes! It’s not as crazy as it sounds). Show appreciation with bonuses not a seasonal holiday themed ham.
I think your headed in the right direction!
For what it's worth, I don't think that's accurate. I've worked closely with the team that builds Code Insights, and at pretty much every point they've been vehemently opposed to exposing any metrics that could ever be used to track/monitor devs.
On the contrary I've actually heard most use cases of it in companies are actually devs themselves showing leadership/management clear graphs of "look, code quality here is getting worse, we need more time in sprints to improve this"
Anyway, just my take, not commenting in any official capacity.
Quality of user stories and product cycle would be interesting to see as it has a direct impact on dev quality (ie how much do they have to guess versus cleanly mapped out).
It's pretty cool and I see where you are going with it.
"Sourcegraph is a web-based code search and navigation tool for dev teams. Search, navigate, and review code."