Coding Efficiency Improvement; What You Need to Know

Developer experience improvement has been the order of the year as all minds, both big and small organizations and government bodies, are after developer experience improvement. Ranging from security to fast and smooth development, all to make the developing communities welcoming and sustainable.

Developers' productivity comes with better coding and automation, which gives advantages like speed, improved collaboration, and culture.

The GitHub Octoverse report showed improved communication between teams with good automation, which nurtures better culture. Availability of good tools is also a deciding factor in the developer's fulfillment.

Developers productivity through code

According to the State of Octoverse report, GitHub came up with a model based on the survey data for this year to make them understand what makes developers and teams perform better, be more productive, and have excellent development experience.

The models are constructed to represent development work practices, documentations, healthy communities, or the outcome of successfully completing these processes.

The models are to show you what will be the result (end of the arrow) of doing some practices.

Each line of the arrow shows the prediction or effect of the practices stated. The colored lines indicate a positive relationship between practices and effects, while the grey ones show negative relationships.

The model is in two-phase, the “work model” and the “open source model.”

Automation

Speaking of automation, it is a key enabler to help teams go faster at scale in open source projects, according to developers' patterns on GitHub reflect. And it was also seen that GitHub Actions is used more proportionally compared to small or medium-sized repositories.

According to the data from GitHub, the top 100 contributors that use GitHub Actions to contribute in open source, open source at work, and work repositories have been categorized by percentage.

For open source contributors, 18.77% are heavy users, 9.68% are moderate users, 15.87% are light users, and 4.08% have tried using GitHub actions.

Open source at work contributors have 30.34% heavy users, 10.56% moderate users, 13.32% light users, and 4.7% have tried GitHub Actions.

Work contributors have 17.89% as heavy users, 4.97% as moderate users, 5.93% as light users, and 2.71% have tried Actions.

Contributors in the top 1000 that use GitHub Actions to contribute in open source, open source at work, and work repositories were also categorized by percentage.

Open source contributors in the greater than 1000 contributors category have 50% heavy users, 11.27% moderate users, 7.58% light users, and 2.46% have tried GitHub Actions.

The open source at work category has 60.16% of heavy users, 6.64% moderate users, 3.91% light users, and 2.34% have tried GitHub actions.

And for the work contributors, there is 39.08% that are heavy users, 4.58% are moderate users, 8.09% are light users, and 2.96% have tried GitHub Actions.

The data shows that Large repositories using GitHub Actions have a 61% increase in pull request merge with a 31% increase in speed of the merging.

Also, all open source repositories have an increase of 36% in pull request merging and reduce the time of merging by 33%. Therefore, this shows that automation increases team productivity.

Frictionless code reuse

Code reuse is a way of improving efficiency and productivity for developers. Reusing code is what most open source communities rely on to build further. The Docker community uses codes from tens of thousands of repositories, from thousands of contributors across different countries and regions.

Docker community has about 49,593 packages in total, 632,170 contributors, and they are all distributed across 215 countries.

When there are access restrictions to code, entitlement procedures, or fragmented information in codes, it can cause discouragements for developers to reuse code. And reusing other people's code increases developers' performance by up to 87% and causes less friction. Reusing codes for open source projects also increases the project's performance 2x compared to projects with friction.

Efficient search algorithm

Searchability is also one of the many factors that improve developers' productivity because, according to the survey data, 60% of developers feel equipped to do their job when they can get what they need easily, and it gives an 11% productivity bump already.

Collaboration with the right tools

Efficient collaboration between teams is important as development is all about collaboration. Which tools will be suitable for effective collaboration as life moves on? This is a million-dollar question that needs to be addressed.

According to the report, the survey results of over 12,000 developers showed that there is now a workplace shift as the paradigm shift of remote and hybrid work solidifies after the pandemic. The survey showed that 41.% of respondents worked in an office before the pandemic and 10.7% expected to work in an office after the pandemic, 28.1% worked hybrid before the pandemic, and 47.6% expected to work hybrid after the pandemic, 26.5% worked fully remote while 38.8% expected to work fully remote after the pandemic.

Overall, the data shows us that just about 11% of respondents are ready to resume full office work, thereby giving traction to hybrid and remote work.

Teams now use pull requests.

Pull request usage was noticed to be significantly used during the pandemic, and merging became quite fast. But with the data, GitHub realized that pull request merging this year at work has become two times faster than the time used in merging open source pull requests. But a development was noticed concerning work pull requests that they became 25% slower than last year, and this brought an understanding that things are returning to pre-pandemic settings.

The data compared the median hours taken to merge pull request from 2019 to 2021, and it shows that pull request takes about 14hrs to be merged in 2019, 13hrs in 2020 (during pandemic), and 10hrs in 2021 in the open source at work category.

It takes 13hrs in 2019, 11hrs in both 2020 and 2021, in the open source category. Then in the work category, it takes 5hrs in 2019, 4hrs in 2020, and 5hrs in 2021.

Teamwork and coordination

Coordination is quite a handy task when contributors are too many, but if it's about the time taken to merge a pull request, we realize we work faster when a task is shared.

The data analyzed showed us results on repositories with more than 3 pull requests, and 60% of it is in a single merge group. It was realized that about 30 contributors in open source, 48 in open source at work, and 16 in work take a day or less to merge. 26 contributors in open source, 28 in open source at work, and 9 in work take up to 2 days or more than 1 day to merge pull requests. 16 contributors in open source, 30 in open source at work and, 9 in work takes up to 3 days and greater than 2 days to merge pull requests. 65 contributors in open source, 62 in open source at work and, 15 in work takes more than 3 days to merge pull requests.

New contributors slow merging time

As new team members are trying to get familiar with the codebase, it slows down time to merge pull requests.

The data analyzed showed us results on repositories with more than 3 pull requests, and 60% of it is in a single-speed group. It was realized that about 4 new contributors in open source, 4 new contributors in open source at work, and 3 new contributors in work take a day or less to merge. 3 new contributors in open source, 3 new in open source at work, and 1 new in work take up to 2 days or greater than 1 day to merge pull requests. 2 new contributors in open source, 8 new in open source at work, and, 1 new in work takes up to 3 days and greater than 2 days to merge pull requests. 7 new contributors in open source, 6 new in open source at work and, 2 new in work take more than 3 days to merge pull requests.

The a-day-or-less club for merging pull requests

GitHub used the data gathered and analyzed to arrive at solutions to help in speeding up pull request merging. They stated that:

• Assigning up to 3 reviewers for an open source pull request will likely merge the pull request in 24hrs.
• Work pull requests with just one reviewer often get merged in 8hrs max
• We can build better together through automation and community

It was further explained that with an extra pair of eyes (extra reviewer) debugging codes and scanning for inconsistent logic, the probability of merging a pull request in 24 hrs goes down by 17%.