GitHub released its community and Developer Report 2020 at the end of 2020. The report includes three sections: The World developer Work-life Balance, Empowering community Health, and the World Software Safety Report. This article is about the world developer work-life Balance, please follow me to subscribe to other sections.

preface

In 2020, due to the outbreak, the influence of such factors as many companies and teams were required to or have to work remotely as much as possible, so many developers have turned work remotely, it also requires that they must rethink their work place and time arrangement, adjustment of the boundaries between work and family, we can see may also experience to, It’s not that simple. In this report, GitHub took a look at how people used to work in the past to see how this change has impacted the developer experience and productivity.

The study found that

Through detailed and rigorous data analysis, the report identifies the following four findings:

  1. A small pull request can help drive innovation and productivity: Teams that strictly limit the amount of content changes to a pull request get faster feedback on code reviews and the like. Over the past year, developers have increased the speed and quality of their work by controlling how much content is changed in the Pull Request and keeping the time from creation to consolidation under seven and a half hours. This will give people more time to do what they want to do.

  2. Automation improves productivity and developer experience: Using GitHub actions to automate pull requests reduced the time it takes to merge them by 19% and increased the number of merge pull requests by 34%. By using automated tools in your workflow, you can minimize manual operations and free up more time for team members to collaborate on innovation, development, and other work.

  3. Open source is a great way to “relax” when everyone is at home: data analysis shows that developers are “away” from work on weekends and holidays, when open source project activity spikes. This shows that there is a difference between the way developers approach work and open source. Developers may see open source as a great channel and opportunity to learn, grow, innovate, and interact with the community.

  4. Developer activity highlights the importance of flexible and personalized solutions: This report analyzes development activity data across the four major time zones and finds that both hours worked and workloads increased over the past year in all time zones. And developers may manage their time and energy through flexible schedules, which can actually help sustain their energy. However, it is important to note that sacrificing personal time for work and breaking the work-life balance will not be sustainable in the long run.

Work proposal

Based on the analysis, the report makes the following four recommendations:

  1. Manage Your Energy: One of the best ways to manage your energy while working from home is to manage your energy, schedule your core work time and get it done, and then take a break. Use gaps or meetings when you’re not at your most focused. This can help you avoid burnout and avoid hating your job.

  2. Experiment and find what works best for you: People are very resilient. If companies allow employees to work flexibly, developers can optimize their work schedules, manage their energy, and get their work done during the time they need it. Flexible tools and workflows also help make teams more robust, allowing them to plan, track, and develop wherever they work. And moving tools to the cloud, known as cloud development, can help improve the development experience.

  3. Using automated tools and controlling the amount of content changes in the Pull Request can help improve the quality and speed of development: it can greatly reduce manual work, improve the speed and quality of code reviews, and improve development efficiency, leading to faster development delivery.

  4. Embrace and support collaboration and open source: Attitudes toward open source are changing, and many people are choosing to work on open source projects as a way to “relax” after “leaving” their jobs. Although they are probably doing similar things on the same computer 😂. Companies and organizations should review their policies and try to allow employees to work on open source projects. Recognize that open source is not just a platform, but something that matters to employees.

When and how long do global developers work

Developer productivity has many dimensions, including the ability to solve complex problems, find solutions, and fulfill requirements. Working hours and time schedule is one aspect of productivity, and understanding it can help us better manage our working time.

Data for this section of this report were obtained from accounts of paying organizations that meet the following criteria:

  1. It was created before October 1, 2018 and has been active every month from September 2020.
  2. Paid team and enterprise cloud accounts

To facilitate year-to-year comparisons, data used in the report have been normalized unless otherwise noted. The report analyzed data from more than 35,0001 organizations, with North America (41%), Europe (35%) and Asia (17%) most represented. Therefore, this report analyzes the working patterns of developers in four time zones around the world: UK Time Zone, US Eastern Time Zone, US Pacific Time Zone, and Japan Standard Time Zone.

Over the past year, while COVID-19 has changed how people work and where they work, it has not changed development itself. The best way to investigate developer productivity during a changing work environment is to use a metric that doesn’t vary from job to job. Development activity on GitHub is a good indicator of how robust it is even when work changes. While things like kanban may have moved from whiteboards to online tools, development can be observed through the same push, pull request, and issue whether we’re in the office or at home. This means that the report is relatively reliable.

GitHub’s data can’t tell you whether a developer is more or less productive at any given time, but we can look at how developers work and how those patterns change over time. These development work patterns are not a complete representation of a developer’s day, they only show us how much time a developer spends in the development section. It’s not just development, it’s meetings, planning, email, etc.

But they may shed some new light on work and how it changes, especially in the case of large-scale teleworking this year. People who work from home generally spend more time at work — more than 8-16 hours of overtime per week (Hill et al., 2010). This may be because our work extends into our lives and the lines between work and life are becoming blurred. With the sudden shift to remote working, we wondered if we would see any pattern of increased development time.

In these time zones, this report analyzes both the development window (that is, hours worked) and the workload. These time zones have been chosen for this report because they have issued strong containment measures, which may help highlight changes in working patterns. These samples were chosen because the sample size of this report is large enough not to be unduly influenced by a few tissues and to be able to obtain significant results.

A single developer’s workday is the length of time between the first git push and the last git push, known as the “push window.” This is a rough assessment of the beginning and end of a developer’s development window.

In this time frame, this report calculates the workload by push counts. Note that development is only considered here, and development is only part of a developer’s daily routine. Many other work tasks, such as planning, designing, meeting, and email, may take place outside of this window.

An overview of the global

  • Monday’s push window is relatively short in all time zones, with most operating between 4.2 and 4.7 hours.
  • All time zones work on Saturday and Sunday, with almost the same hours as Monday. On Saturdays, the time range is 3.7 to 4.3 hours. On Sundays, the time range is 3.7 to 5.4 hours. This could be people catching up on one week’s needs, or preparing for the next, or developers working on individual projects.
  • Compared to other time zones, the PUSH window in the Pacific Time zone is significantly longer Tuesday through Friday, ranging from 8 hours to 8.3 hours.

This report makes a comparative analysis of the daily push times in all time zones and finds some interesting phenomena:

  • In all the time zones studied in this report, developers are active seven days a week.
  • Of all the time zones, Japan’s standard time zone has the most balanced push per capita, which is the most sustainable way to work. The response to COVID-19 has also been muted in Japan’s time zone government, where remote working has long been supported but is not mandatory, and the impact of casualness on workflow may not be as great. Japan has also been one of the earliest and best countries to manage COVID-19, and has returned to normal relatively quickly.
  • In contrast to The Japanese time zone, the Pacific time zone in the US has the highest number of pushes per capita, which may be a result of the overtime culture (there are two core technology centers here) or the need to write simultaneously with others across multiple time zones. But this way of working makes people bored and is not a sustainable way of working.

UK time zone push window and workload analysis

First, the report analyzes time zones in the United Kingdom, which was one of the first countries to introduce a home quarantine policy. The PUSH window for UK developers until April 2020 has been shortened compared to the same period last year, however it started to increase significantly in mid-March. Since August, the push window has leveled off and increased by three minutes compared to the same period last year.

Looking at the workload, you can see that the amount of push from USERS in the UK time zone doesn’t start to increase until mid-June. And until August and September, its push volume remained at a high level compared with the same period last year. That means people in the UK time zone have been working longer hours and doing more work since June.

An analysis of the average weekly push window and workload (average number of pushes) for developers in the UK time zone shows that in this time zone:

  • The Push window is mostly between 3.9 hours on Friday and 4.4 hours on Wednesday.
  • The workload was mostly between 13 commits on Friday and 15 commits on Wednesday.
  • Saturday had the highest number of commits, up to 20.

The increase in weekend push volume may be due to fewer developers submitting code on weekends. But it could also represent an increase in personal workload, such as working on open source projects, hobbies or tutorials. Because developers are busy with work during the week, they use weekends to work on personal projects. It is worth noting that a similar pattern exists in all time zones except Japan’s standard time zone. This will be explained later when analyzing the time zone.

Us Eastern time Zone push window and workload analysis

For the East Coast, the push window for developers was relatively short for most of 2020, rising in March before leveling off in August, an increase of two to three minutes over the same period last year. The November drop was due to the Thanksgiving holiday.

Data analysis of developers in this time zone shows that:

  • The weekday push window ranges from 4.4 hours on Monday to 5.3 hours on Wednesday.
  • The workload ranges from 12 Commit on Monday to 13 commit on Wednesday.
  • On Sunday, the number of commits increased to a maximum of 16.
  • Developers work as much on Sundays as they do on Mondays, or more.

Pacific Time Zone push window and workload analysis

It can be seen from the analysis that the push window length has changed compared to the same period last year, and has been increasing since the middle of March, generally reaching 30 to 60 minutes per week. This continued into June and began to level off in early July. And through late July, it increased by five to seven minutes compared with the same period last year, before falling again in August. In addition, November’s ups and downs were caused by the Thanksgiving holiday.

Pacific Time zone developer push volume is consistently higher than last year. Since May, activity in many areas has increased by more than 50 percent over the previous year, before falling to 25 percent higher in September. The Pacific time zone consistently had the highest developer workload compared to other time zones during the year, according to code Push.

In this time zone:

  • The weekday push window ranges from 4.5 hours on Monday to 8.3 hours on Wednesday.
  • Weekly workloads range from 16 commit sessions on Monday to 17 commit sessions on Wednesday.
  • The highest number of commits was 23 on Sunday.

The analysis also found an interesting trend: activity among corporate developers drops on weekends and holidays. At the same time, however, there has been a significant increase in activity in open source projects, indicating that people are switching to open source as they leave work. Since April, the number of open source project creation has also increased by 25% year on year. Especially now that so many people are working remotely. Open source gives us the opportunity to develop, create, learn, collaborate and share with the community.

Japanese time zone push window and workload analysis

Finally, the report analyzes Japan’s standard time zones. As of mid-November 2019, the daily working hours of Japanese developers have increased (by 5-15 minutes) compared to the same period last year. Starting in April, we saw the push window get longer and developers start spending 20-52 minutes more per day on their work. In June, that figure fell to about 15 minutes more per day than a year earlier.

In this time zone:

  • The Push window ranges from 4.3 hours on Friday to 4.8 hours on Tuesday.
  • The average developer works at 9 commits per day per week.
  • On Sunday, the workload was reduced to 8 commits.

Unlike similar lockdowns in the United States and Britain, the measures taken by the Japanese government are non-mandatory in nature, with no penalties for individuals or businesses. As a result, the effect of the shift in working patterns may not be significant.

Productivity varies from person to person

COVID-19 and the sudden shift to working remotely had a big impact. However, developers are doing more work than they did a year ago. We are happy that productivity is rising in the face of uncertainty, but is it really sustainable? For some people, working from home liberates productivity by allowing them to work according to their needs, setting up their workspace as much as they like with as little disruption as possible. And, more time for naps, exercise and family time. This is not possible at the office, perhaps because the open work environment is too noisy, or the office environment is not customizable, or the commute is too long to be flexible about the time of day.

However, for many people who are just beginning to try remote work, it can be a maddening situation. For some people, working remotely makes it more difficult to interact and communicate with others. Many also don’t have workspaces at home, lack the equipment they need to work, and have to look after their children themselves or with someone else. The boundaries between work and life blur, and time previously devoted to commuting becomes work time, leading to longer working hours. Despite this, many people still feel they don’t have enough time to finish their work on time.

Here are a few tips for delivering productivity and avoiding laziness:

  • Take a few minutes each day to think about what you are grateful for. Some developers shared that this had a positive effect on their mindset adjustment.
  • In addition to managing your time, manage your energy. Figure out what works for you and optimize for those patterns. If you’re a morning person, finish important tasks first. If you’re more productive in the afternoon or evening, coordinate your work with other colleagues.
  • As a team, support flexible, sustainable work schedules and be aware of burnout among team members. This helps make our team and ourselves happier and more productive.

For more tips on working from home, check out the following:

  • Telecommuting: How are parents adapting to working remotely during COVID-19
  • Telecommuting: How do you collaborate remotely
  • Podcast: Parents Drive Remote work

Developer activities

Developer activity (that is, developer behavior) is another aspect of productivity. Measuring developer activity as part of productivity is complex, but when done well, it can be very beneficial. This can help developers uncover best practices for task management, work coordination, and problem solving. For team leaders, work barriers can be removed to help the team cooperate better and achieve better results.

The data is based on a year-over-year analysis of all GitHub initiatives (public and private, including open source). The comparison period is October 1, 2019 to September 30, 2020 and October 1, 2018 to September 30, 2019. Year-to-year changes in the geographic distribution of users included in the analysis are included in the figure below.

Developer activity has increased significantly

This report analyzes each account’s pull request, push, reviewed pull Request and reviewed issue. Overall, these figures were flat or increased compared with the same period last year.

Unless otherwise noted, the figures in the chart are for each developer standardized on a weekly basis. Late-2019 dips correspond to holidays. This report analyzes the amount of pull requests and pushes per person per day and finds that activity continues to increase compared to last year. In addition, I also analyzed the reviewed pull request and reviewed issue, and reached a similar conclusion: the data was higher than last year, and basically the same throughout the year.

The data also shows that the numbers have been consistent or even increased during the COVID-19 outbreak and working from home. It’s worth noting that while the impact of various factors has resulted in a dramatic change in the way we work, the numbers haven’t changed much, suggesting that flexible tools, processes, and solutions can support developer productivity and continue to set new highs even in the face of major changes. Cloud development can provide a better development experience for developers and a more stable and resilient development model for teams and organizations. In addition, the report points out that flexibility is also beneficial to developers by allowing them to break things down.

Collaboration is the centerpiece of development

Some teams have always worked remotely, either full-time or on open source projects, while others have had to work remotely for the first time. To explore how the changing work environment can affect key collaborations, this report analyzes peer review data from the Pull Request.

A Pull request is a way for developers to tell others what changes they have made to the repository. A pull request may involve review of changes by interested developers before merging, review what has been changed, discuss code, and sometimes commit. Finally, the pull request is merged into the relevant branch of the corresponding repository. To assess this collaboration process, this report measures the time it takes for a pull request to be created and merged, compared to the same period last year.

In the open source repository, the time it takes for a pull request to be created to be merged varies, with most of the big fluctuations occurring around the holidays — generally, this year’s pull request merges slowed from 3.5 hours faster than last year to 3 hours faster than last year. In addition, since mid-February 2020, the speed of merging pull requests has been faster than the previous year and has remained constant, reducing the overall time by 1-7 hours.

An analysis of the code in the work environment found that at the end of 2019, the average time to merge pull Requests was longer than the previous year, 1.5 hours longer in the team warehouse and 1.5 to 4.2 hours longer in the enterprise account. As team members take more time off (vacation), the merge takes more time and the amount of review in the pull Request decreases.

At the beginning of 2020, you can see that the merge time is still longer than the previous year, but it has improved: 1-2 hours longer for team warehouses and 0.1 to 1 hour longer for enterprise cloud warehouses. In March, there was a significant drop in merge pull Request usage, which then extended, and this pattern has remained for the rest of the year: team warehouse merge Pull Request speed increased by 5 hours at its peak, and enterprise cloud warehouse speed increased by 6 hours.

In a recent interview, developers and project leaders shared their team’s experiences with pull Request. The consensus best practice is to keep the number of changes in the pull request low, because this makes it easier to review, improves the quality of the review, and makes it easier to undo if something goes wrong. In addition, it enhances positive feedback, which can help drive creativity and increase team productivity.

Issue creation volume changes

In addition, the report also analyzes the number of issues created on GitHub. Before the COVID-19 outbreak, the number of issues created on GitHub per day was less than or equal to the same period last year. As the arrow shows, this pattern began to change in mid-March and remained the same throughout this analysis. Similarly, the decline in figures at the end of 2020 corresponds to the holidays.

Note: GitHub announced free team accounts on April 14, 2020, and this report also analyzed the data to investigate whether the increase in activity on free accounts was due to a change in account policy or a genuine increase in activity. The analysis found that half of the increase in activity data was due to COVID-19, as there was a significant increase in the number of issues created for free accounts during the year, and this was significantly different from the activity for corporate accounts.

Further analysis shows similar changes in the rate of issue creation in all warehouses, with the largest increase being in warehouses owned by free developer accounts and paid team accounts. The figure below shows the change of the number of issues created in the warehouse relative to the same period last year. Note that the peaks and lows in enterprise cloud account data in late November were caused by the Thanksgiving holiday in the United States.

Development has not been affected

The analysis of the data combined with global events can be divided into three different stages: October to December 2019 (pre-COVID-19), January to March 2020 (early COVID-19), and April 2020 to September 2020 (most developers start working from home). From this perspective, the analysis found a difference in the data for issues between corporate and free accounts, especially after April 2020.

Note the trend line, as you can see from the chart that the data for the free warehouse has changed dramatically.

If we break down the push and pull requests by these same date ranges, we see a slight increase in both numbers over the course of the year, but no significant change in activity. Because push and pull Requests are a core part of development activities, they are not significantly affected by a change in workplace.

The analysis found that the actual size of the push (as represented by the number of files changed per commit) remained roughly the same over the past year, even as the developer workload increased. In contrast, an issue is used to track and plan work and is more susceptible to interference.

Enterprise cloud warehouse and issue

Data from the enterprise cloud warehouse showed two main patterns: the year-over-year numbers were relatively stable until April 2020, after which the overall numbers declined. You can see a spike in issue creation activity around mid-April and May, probably due to developers moving to work from home and coordinating development efforts through Issue. However, the report does not see the issue creation rate returning to the year-ago level. This may be because corporate teams are more used to tracking development through issues.

Free warehouse and issue

The data from the free warehouse also showed two main patterns of activity: the year-over-year figures were relatively stable or slightly lower through April 2020. Then we saw a huge jump in the numbers that seemed to level off in May (average 21% since April, median 22%). In the free warehouse, the analysis did not find the same dramatic drop in the number of issues created on weekends, possibly due to activities related to open source, hobbies, tutorials, etc.

Automation facilitates development

Delivering code quickly and reliably through automation is very important. It is important for developers to get quick feedback as they write code to confirm that their code is deployable, so they do the next requirement immediately rather than manually deploy their code.

This report examines how open source libraries use actions to automate their pull requests. The pull Request is focused on because it is a key point of intersection in the development process. By introducing automation at this stage, the team can notify others to review the pull request and start testing and build once the review is complete.

Across all open source libraries, the time taken to merge pull requests decreases by 18% and the number of merged pull requests increases by 34% once they start using actions. Teams that use automation in their workflows can speed up their software delivery because they can merge pull requests faster, continue writing code faster, and then quickly incorporate more code into their projects. This is a virtuous cycle, where improved software development practices provide a better experience for developers and generate consistent revenue.

Automation can not only speed up software delivery. Other studies have shown that automation also reduces errors and improves the quality of submitted code, which in turn gives developers more time to develop and innovate.

The industry standard

It is often asked “what is the industry standard” for developer activities. The GitHub team encourages you to use these benchmarks to think about your programming practices and where you could improve them in light of your situation.

In work – and interest-driven projects, the development code may be somewhat different, so only data in an enterprise environment is analyzed here to control for differences. In this case:

  • Developers typically submit code four times a day
  • It typically takes 1.6 hours for a Pull request to be created until it is merged
  • Code review cycles are typically 1 hour

In the report, the timelines of pull request and review are split and analyzed. As you can see, the first pull Request review usually takes 54 minutes and the time from the last review to the merge is 12 minutes. It took 1 hour and 36 minutes from the time the pull request was created to the time it was merged. Also, in most cases, only one person in the pull request is reviewing, so no time is lost between the first review and the last review, but other reviews may cause delays if they occur.

Looking to the future

What this report analyses is a naturally occurring, global “experiment” that suggests remote working is far more successful than previously thought. The health care industry, which declared telecommuting impossible just a year ago, has found ways to provide services safely and reliably because the environment demands it.

The report notes that the number of GitHub developers has increased year-over-year, in line with typical growth for the platform, and that individual developer activity has also increased. And in the face of changing work patterns, corporate strategy, and economic and market conditions, it’s very welcome to see such an increase. This also shows that cloud-based development provides more stable and resilient development for developers, teams, and organizations. And an analysis of hours and workloads shows that developers also benefit from flexibility. Flexibility allows them to be more flexible with their work.

Will this affect centralised working patterns? The findings in the report, coupled with studies of teams that have already begun to recover, suggest that:

  • Teams may find that the mode of work that works best for them is a combination of remote and field work.
  • Even when we return to our traditional workplace, we find that the hours are still longer. In particular, “night shifts” are more common.
  • Provide flexible solutions so developers can create their own solutions to make work sustainable.
  • Network conditions and collaboration are so important that even if a disruptive event occurs, it will not have a big impact.

Work patterns over the past year suggest that people are doing more and doing more. This may be the result of increased productivity through automation, better development practices and more flexible office patterns that blur the boundaries between work and life.

We’re all more malleable than we think.

Thank you

  • By Nicole Forsgren
  • Data scientists: Greg Ceccarelli, Derek Jedamski, Scot Kelly, Clair Sullivan
  • Reviewers: Denae Ford, Martin Fowler
  • Copy editors: Leah Clark, Cheryl Coupe, Stephanie Willis
  • Designers: Siobhan Doyle, Aja Shamblee

Note: This article is based on the GitHub 2020 report and is not a strict translation. You can download the Chinese version of this report from the Nuggets Translation Project and the English version from OCTOVERSE.

Search the official wechat account “Technology Talk” and subscribe for more exciting content.