Programming in the pandemic - DevGraph: Beyond the baseline
With only a proportion of developers classified as key workers (where their responsibilities perhaps included the operations-side of keeping mission-critical and life-critical systems up and online), the majority of programmers will have been forced to work remotely, often in solitude.
So how have the fallout effects of this played out?
This post is written by Darren Broemmer in his capacity as developer evangelist at DevGraph — the company is known for its suite of integrated software development tools that deliver higher productivity and better-quality software through automation and insights.
Broemmer writes as follows…
To what degree is programming during a pandemic truly different? The GitHub Octoverse 2020 Productivity Report illustrates how software development productivity during the pandemic is either consistent with the baseline or has increased. The report includes activity from more than 35,000 organisations covering the 12-month time period ending September 2020.
Thus, a pre-pandemic baseline can be established and changes observed during the first six months of the movement to widespread work-from-home. Based on that report and my experience, let’s take a closer look at the state of software engineering.
In March 2020, there was a sharp decrease in the number of code commits. While this metric is far from perfect, it does provide good insight into developer productivity. Organisations were figuring out how to adjust to remote-first work conditions. Engineers made the switch and the realisation settled in that this would be the new normal.
The first logistical issue to tackle was the home office. Speaking as one myself, engineers are very particular about their workspaces. Who can be productive with only a single monitor? Many engineers simply did not have a great setup at home. They probably had a desk where they could work but used it only occasionally on a sick day or while waiting for a delivery.
I quickly realied that a stand-up desk for my home office was an absolute necessity. It didn’t matter that my corporate employer at the time wasn’t going to reimburse me. It had to be done, I simply couldn’t sit all day.
Finding your flow
Once developers adjusted to their new routine and sorted out logistical concerns, their newfound flexibility became a strategic advantage. It is common for engineers to have a most productive time-of-the-day. Once they get into the flow, productivity skyrockets. The new work schedules helped these flow states thrive.
In an office setting, continual interruptions interrupt flow. Now, however, communications largely come in the form of chat messages and emails that can wait, as opposed to managers knocking at your door requiring immediate attention. Maybe the new setup wasn’t so bad after all.
By late May 2020, developer productivity increased as the number of code commits went up sharply. A few notable trends in the work paradigm stood out:
- Engineers started working more hours each week, often the equivalent of adding a full extra day.
- The workday was ‘stretched out’ over a longer period (as measured by time from first code commit to last).
One explanation for this is the recovery of commute time. However, this doesn’t account for the entire increase in work hours. A bigger paradigm shift was occurring that blurred the line between home and work even further than it was before. It was now incredibly convenient and productive to sneak in a few extra hours at the computer whenever you could. This trend extended into Saturday and Sunday.
Engineers used their newfound flexibility to take breaks throughout the day and work in bursts. Work-related interruptions went down, and productivity went back up. Another key metric trended upward at this point, one that arguably had a more profound impact on the development lifecycle. In addition to the number of code pushes increasing, the time to merge a pull request went down.
Faster code reviews & cadence
Developers often juggle multiple tasks, but typically they work on a primary development task. This consists of design, development, testing, and review subtasks. The code review portion is essentially wait time. After a developer sends a pull request, they wait for another engineer to review and comment on the code. If there are non-trivial comments or changes required, this cycle can go through a few iterations.
One outcome of the elongated workday was that various engineers are available at different times of the day. Developers were submitting code as they completed it, and more often than not, someone would be available to review it. This led to faster turnaround times and more frequent merges of pull requests. The amount of wait time had been reduced.
Long wait times for code reviews can affect a developer’s flow. An engineer may decide to work on a different task while they wait. Context switching is required once feedback is received. In the work-from-home world, the development cadence increased to a more natural state. Developers were receiving more timely feedback. Coverage for most teams likely wasn’t around the clock, but it did span a much larger time window.
This also helped facilitate smaller, more frequent code reviews. Really large pull requests can be difficult for the reviewer to grasp and often slow down the velocity. Smaller code pushes were something we emphasised to junior engineers during my time at Amazon.
According to a study by the University of Zurich, 24% of a developer’s day involves “collaborative activities with co-workers, customers, or managers, such as planned or ad-hoc meetings and emails.” Did the isolation and periods of quarantine not affect developers?
Greenfield, more prone to rot?
It did, but more so for a certain class of development organisations. Teams in established development cycles were less affected than new large-scale or greenfield development efforts. Projects involving significant design and interactive discussions were likely slowed down by the pandemic. Normal team communication during day-to-day activities was less impacted.
As an example, my team sat in one row full of cubicles when I worked at AWS. It was quite common for the area to be quiet. Why was that? Due to the proximity, people knew if they started a verbal conversation, it would potentially distract others. Thus, the team chat room was used heavily even though most team members were only a few meters apart.
From the early days of open source, development and its toolsets have been designed to support remote, asynchronous workflows. The pandemic has been, to a large degree, simply another use case in this overarching pattern.
The isolation and remote nature of the work can make certain aspects challenging, for example, design discussions where it is quite handy to stand together at a whiteboard. Team members who wanted to chat at AWS would use someone’s office or a break-out room, stand together at a white board, and talk through the problem. This type of interaction can be achieved remotely, of course, but it requires some coordination and can be less effective in a video conference format.
The remote-first paradigm is here to stay.
Fortunately, software development is uniquely positioned to succeed given the constraints. The increased flexibility has already resulted in some positive trends in developer productivity. The challenge ahead may lie more in the realm of maintaining some semblance of a distinction between home and work and avoiding the possibility of burn out.