Skip navigation

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?

01

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 doing these things well). Each line is a predictive relationship between constructs. When you see a line, you can generally read it as “predicts” or “affects”. Colored lines are positive relationships, and gray lines are negative. For example, detailed code reviews positively affect a sense of making progress -- that means they help developers feel empowered and make progress on their work. But detailed code reviews negatively affect software delivery performance -- that means they can slow down delivery and teams should pay attention to the tradeoff.

Work
Open source
Graph about developer productivity in Work
02

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:

Increases the number of merged pull requests by
36%
Shrinks the time to merge by
33%

Percent of repositories, contributors using GitHub Actions

> 100 contributors
> 1000 contributors
Heavy users
18.77 %
Moderate users
9.68 %
Light users
15.87 %
Have tried Actions
4.08 %
Open source
Heavy users
30.34 %
Moderate users
10.56 %
Light users
13.32 %
Have tried Actions
4.7 %
Open source at work
Heavy users
17.89 %
Moderate users
4.97 %
Light users
5.93 %
Have tried Actions
2.71 %
Work
03

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

49,593Total packages632,170Contributors215Countries
04

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?

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
05

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 pandemicWhere respondents expect to work after the pandemic
41%
C
10.7%
28.1%
H
47.6%
26.5%
F
38.8%
4.4%
N
2.9%
C
Collocated
In an office all the time or part-time
H
Hybrid
Some team members in an office and others remote
F
Fully remote
All team members working remotely
N
Not applicable
Where respondents in companies worked before the pandemic
46%
Collocated
54%
Others
Where respondents in companies expect to work after the pandemic
20%
Fully remote
26%
Hybrid
54%
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.

06

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?

Pull requests are merged almost
2X
faster at work than open source
Pull requests at work are merged
25%
slower than last year

Median hours to merge pull requests

Pull requests with at least 1 reviewer

111311101314545201920202021WorkOpen sourceOpen source at work
07

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.

Open source
Open source at work
Work
Open source
30
Open source at work
48
Work
16
A day or less to merge
Open source
26
Open source at work
28
Work
9
Up to 2 days and >1 day to merge
Open source
16
Open source at work
30
Work
9
Up to 3 days and >2 days to merge
Open source
65
Open source at work
62
Work
15
More than 3 days to merge

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!)

08

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.

Open source
Open source at work
Work
Open source
4
Open source at work
4
Work
3
A day or less to merge
Open source
3
Open source at work
3
Work
1
Up to 2 days and >1 day to merge
Open source
2
Open source at work
8
Work
1
Up to 3 days and >2 day to merge
Open source
7
Open source at work
6
Work
2
More than 3 days to merge

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.

09

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.

03

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

17%

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.