The tooling available to extract insights from git data has flourished over the past 5 years. There are now at least 10 companies offering "Developer Analytics" or "Git Analysis" tools that combine data from git with issue tracking to surface insights that developers can apply to create improved working conditions.
In this article, we'll dive into recent research data to pick out the biggest happiness-improvement opportunities within an average dev team. Using this data as the backbone, we'll review three specific ideas that can translate data from free git tools into a more joyful working environment.
Strapped for time? Feel free to jump straight to any of these three opportunities:
link
linkOpportunity #1: Get developers their productivity fix
What single factor predicts developers unhappiness more than any other? Managers might guess "schedule flexibility" or "work/life balance." I doubt that many would guess the real top-voted answer: "Lack of productivity." But the data is sitting right here, in a recent survey undertaken by Stack Overflow in 2022, mocking our misguided intuitions:
So apparently developers hate feeling unproductive. They hate it so much that "lack of productivity" is the single most negative feeling among all 10 questions explored. There's a valuable lesson here for performance-focused managers: let your developers feel unproductive at your peril.
Why is "lack of productivity" such a common frustration among developers? The reasons for that could fill a book, but why not start with the most obvious: that most software takes weeks or months to ship. Sometimes, even after it ships, the developer still won't get to see their work in use. For these developers, their "affirmation loop" is more like an affirmation dead end.
Even if a developer is working at maximum efficiency, every day that passes between "work getting done" and "work can be observed serving benefit" weakens the potential satisfaction. Feeling productive is a lot easier when concerted effort is directly tied to some visible artifact of progress.
Enter git stats. With relatively little effort, you can coax git to visually affirm every developer's progress in real time, as code gets pushed throughout the day. Now, instead of pushed code resulting in little more than a Slack message to the #commits channel, something like a picture can emerge that embodies how much is getting done, and feeds the need to see progress:
This picture is GitClear's Commit Activity Browser, a free tool that visualizes progress across all repos in an organization. You can conjure similar results using open source tools like those mentioned here. IonicaBizau/git-stats is the most popular open source option for generating a visualization like this that can be updated daily to affirm productivity.
When GitClear built the Commit Activity Browser, we assumed it would be used mostly by new developers looking to learn best practices from their more senior colleagues. What we found instead was that the view has been used almost entirely by developers to self-review their own work. In a world where an important backend change often has no visual accompaniment to reinforce the developer's hard work , a colorful graph of what's getting done goes a surprisingly long way.
linkOpportunity #2: Review less code, more consistently
Research from 2017 entitled "On the Unhappiness of Software Developers" shows another glaring problem in many workplaces: inadequate code review, resulting in substandard code entering production. One could argue that four of the top 10 greatest causes of unhappiness all relate to inadequate controls on how code is reviewed before being merged:
Bad code quality, unexplained broken code, and underperforming teammates: improved with effective code review
The essential problem here is that developers have a lot more energy to write code than they do to review it. The former tends to imbue them with energy, while the latter drains it. Code review just isn't fun. Nor does it inspire a sense of productivity. The best solution would be to review less code, if that were possible without running headlong into issues with "bad code quality" that end up being even more deflating to happiness than code review.
But there is good news for those that hate reviewing code: empirical data that suggests only the smallest fraction of code authored is meaningful:
4.3% of lines of code are purposeful, substantive, effecting and distinct. Find the full explanation here
If "reviewing code" only meant reviewing the 4% of code that mattered, it could go a long way toward making more effective use of the limited time and willpower that exists for code review.
Enter one of git's newest features: --color-moved. Per the empirical research above, roughly 30% of code is moved. So why are developers still reading PRs that draw their attention to unchanged code? Moved code has already existed and proven itself viable, so attention is almost always better spent elsewhere. You could be reviewing 30% more code in the same amount of time if your PR visualization uses --color-moved, as demonstrated with examples in this article.
GitClear's free diff viewer automatically excludes and minimizes almost all of the types of noisy code seen in this visualization.
linkOpportunity #3: Experiments that iterate toward happiness
At any given time, most product teams that I've talked to are running at least a few A/B tests on their product. Every completed test can push a product incrementally toward higher conversion rate, more signups, or whatever else the product team can measure.
Far fewer are the teams that think to employ the benefits of A/B tests toward improving their work conditions through git data. Recall 2019, when the internet hosted numerous lively -- and data-free -- debates about whether "working from home" could be a viable way for developers to commune on a product? Opinions were divided at the time, but in retrospect, it seems obvious that the only reason this was an unsettled question was because nobody trusted their data enough to believe it when it appeared that working from home had negligible impact on productivity.
As of 2022, most would agree that the WFH experiment has been settled, but is that really the only experiment worth trying? It was sitting under our noses the whole time, yet nobody bothered to A/B test this. If you can find a git stat that reasonably approximates developer activity, you can avoid making mistakes like thinking that WFH was going to be the productivity disaster that many assumed.
What kind of experiments might you try?
git creative! There are so many ways to experiment to create a happier working environment
What git stats to use to run your experiment? There are several answers that could work, including even commits or PR count, though our empirical research suggests that Diff Delta is more likely to reflect the rate at which code is changing over time (and is freely available). The exact git stat chosen matters less than ensuring that developers know that they are not having their value assessed by this metric, because developer productivity is much more complex than any single git stat can describe.
Why not pick 3-5 interesting experiments from the ideas above and try running one experiment per quarter? The best method to avoid the groupthink that has kept us all working from the office the last 50 years is as simple as repurposing the humble A/B test idea you're already using to answer less important questions.