Writing and shipping code faster
Fast is better
A great developer experience is on everyone’s mind. At work developers, managers, and organizations want tools and processes to be fast, delightful, and easy. In open source, project leaders and maintainers look for ways to make communities welcoming and sustainable. So how can we all make that happen?
Developer productivity is about making work better for developers
Better coding and automation is about more than speed and productivity - it also improves collaboration and culture.
What the data shows: Good automation helps teams communicate better and more clearly, and the research shows that better information flow is key to a better culture. Having better tools also helps developers feel empowered to do their work and feel fulfilled.
Using the data: Use these charts to identify one thing you can work on to improve your work! Pick something on the bottom (at the end of an arrow), then work backwards to see what has a significant effect. For more details about each construct, head to the companion repository for the survey items we used.
Improving productivity with code
Each box in the model is a construct (either a practice of development work, documentation, or healthy communities; or outcome of ...[show more]
Automation helps teams go faster at scale
Developer patterns on GitHub reflect that automating software delivery is a key enabler in open source and helps teams go faster at scale. We see large repositories use Actions proportionally more than small or medium-size repositories.
What the data shows: Once large repositories start using Actions, teams merge almost 2x more pull requests per day than before (61% increase) and they merge 31% faster. Across all open source repositories, using Actions increases the number of merged pull requests by 36% and shrinks the time to merge by 33%.
Using the data: Automation helps teams. Try implementing automation around your pull requests to improve your team’s productivity.
Across all open source repositories, using actions:
Percent of repositories, contributors using GitHub Actions
Frictionless code reuse makes developers more efficient and productive
In GitHub’s open source community, projects built with code and toolchains from the community are thriving. We build better together and help each other grow stronger. Communities such as Docker rely on tens of thousands of repositories, hundreds of thousands of contributors, and draw from hundreds of countries and regions.
What the data shows: Entitlement procedures, access restrictions, or information fragmentation can introduce friction that discourages developers from reusing code. However, developers’ performance at work can increase by up to 87% when reusing others’ code is easy and doesn’t introduce friction. The benefits of frictionless code reuse are striking for open source projects too --projects see 2x performance compared to those with more friction, like slow processes or multiple approval layers.
Using the data: Identify sources of friction when you and your team reuse code from other teams and repositories. Are there barriers such as lengthy access approvals, poor indexing, or undocumented dependencies? What can you simplify, or influence others to streamline?
The community that builds Docker
Ease of search is underestimated
An efficient search algorithm is great, but searchability is also a product of consistent code standards and naming conventions
What the data shows:
Developers are almost 60% more likely to feel equipped to do their job when they can easily find what they need. Plus, they can get an 11% productivity bump simply by having a team repo that is easy to search -- a finding supported by earlier research as well.
Using the data:
Think about your team practices; do they support easy indexing and cross-referencing so information is easier to find?
Development work is all about collaboration--with the right tools
In this year’s survey, we’re seeing shifts in where work happens and what that means for collaboration--now and moving forward. Developers around the world expressed a clear expectation to work in a hybrid or fully remote environment moving forward.
What the data shows: Only about 11% of respondents expect to go back to working collocated, a 30% drop from 41% working in an office before. As a result, we see hybrid and remote work gaining traction as the expected way of working.
Using the data: Think about your own team, and where you work now, and where you’ll work in the future. How can you support yourself and your teams? Are you using processes and tools to support efficient collaboration? Merging pull requests, deploying code through pipelines, and organizing work become especially important when some or all of our team works remotely (all or some of the time). Our colleagues in open source have done this for years, so they can teach us a thing or two about shipping software in distributed teams.
Work before and after the pandemic
We present one decimal for simplicity; there may be a rounding difference of 1%.
Where respondents worked before the pandemic | Where respondents expect to work after the pandemic | |
---|---|---|
Collocated In an office all the time or part-time C | ||
Hybrid Some team members in an office and others remote H | ||
Fully remote All team members working remotely F | ||
Not applicable N |
In an office all the time or part-time
Some team members in an office and others remote
All team members working remotely
Collocated
Others
Fully remote
Hybrid
Others
When drilling down into the data we found the difference was more pronounced for folks in companies. Of those respondents working in companies, 46% who previously worked collocated now expect to work in a fully remote (20%) or hybrid (26%) environment.
Pull requests are how development teams coordinate and build software together
What the data shows: This year, pull requests are merged the fastest at work, almost 2x faster than open source. We also see that pull requests at work are merged 25% slower than last year. When we compare the previous two years, we can see signs that work rhythm is returning to pre-pandemic levels.
Using the data: Think about your own work. What have you noticed about your team’s or community's speed of completing work this year? If your own team’s merge time has changed, what contributed to that?
Median hours to merge pull requests
Pull requests with at least 1 reviewer
Teamwork is important, but coordination is hard
When we look at the time to merge pull requests by the number of contributors, we see that we work faster when others share the work, but too many contributors adds to coordination costs and slows work down.
Average number of contributors by a repository’s most common speed to merge a pull request
For repositories with more than 3 pull requests and that have at least 60% of all their pull requests in a single merge group.
For example, open source repositories with an average of 30 contributors close their pull requests in a day-or-less while those with an average of 65 contributors take three days or more to close a pull request.
Proportion of pull requests, by merge time (hours)
Percentage limited to 1% values or less.
What the data shows: Most pull requests are closed well within the first two weeks; our chart cuts off at two weeks, but the pattern of early merging is clear. Looking at merging by hour, we see that merging drops off on weekends, but some development is still happening.
In development done at work, most pull requests are also closed within the first few days. We see similar patterns to open source merging, except development
Using the data: Look at your own teams’ pull request merge times (or ask around) - how quickly do you typically merge? Are there opportunities to improve? (If yes, keep reading!)
New contributors affect time to merge
What the data shows: As new team members are onboarding or getting to know the codebase, it affects the time to merge a pull request.
Using the data: Look at your own team’s pull request merge times. Do new contributors affect pull request merge times? Think about how your team uses pull requests to train new contributors or how you share pull requests among the team, and how this affects overall pull request times as well as team culture.
Average count of new contributors in repositories by speed to merge pull requests
For repositories with more than 3 pull requests and that have at least 60% of all their pull requests in a single speed group.
The number of new contributors can affect the time to merge pull requests, for example as new team members are onboarding or getting to know the codebase.
Day-or-less Club
How can we improve our ability to merge pull requests quickly? Our data has some hints!
01 Assigning no more than three reviewers to a pull request in an open source repository increases the chances it will get merged within 24 hours.
02 At work, pull requests with just one reviewer are often merged within an 8-hour workday.
Automation and community help us build better, together.
With each additional reviewer, the chance to merge it in a day or less goes down by about
An extra reviewer is an extra pair of eyes checking for bugs or inconsistent logic. At the same time, with each additional reviewer on a pull request, the chance to merge it in a day-or-less goes down by about 17%. The number of reviewers on a pull request can be a tradeoff between quality and speed, and teams should exercise judgement.
Using the data: Identify some opportunities to join the Day-or-Less Club by limiting the number of reviewers in your own team. This may include rotating reviewers, or sharing responsibilities across teams.