Programming in the pandemic - DevGraph: Beyond the baseline 

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.

Image: DevGraph