Media outlets have reported that tech workers are among the least impacted by “lockdowns” and workplace closures over the last year. This is ostensibly because we can work remotely.
But can’t anyone with a white-collar job work remotely? Unless you need to be physically doing something in proximity to your workplace, most modern office jobs can be done over a video or chat application.
I will submit to you that there the real reason tech people are having such an easy time transitioning to remote work is that we have already built all the tools to do our jobs remotely. We have been so far ahead of the curve, that our industry is already built for remote work.
Consider the problems of remote work, broadly:
- Workers may be working from different timezones. Timezones may have significant overlap (e.g., New York and Chicago) or they may have little or no overlap (e.g. Mumbai and Texas). Thus, being able to work independently is necessary to maintain productivity.
- Workers must be able to work independently, but eventually their work needs to be integrated together. How shall this be accomplished? If workers A and B are both going to do 50% of a project, how can we divide the work so that both are contributing their fair share, without significantly impacting productivity?
These are the very problems that source control systems are designed to solve. The popular Git system works as follows:
- Work is sub-divided into “commits.” When worker A has completed a task to their satisfaction, they then “commit” that work to their local copy of the project. Note that the work is still not integrated with worker B’s work.
- Commits should be small. Large commits are harder to integrate, and are thus discouraged. Thus, worker A and B plan their contributions accordingly so that they produce many small commits.
- There is a “master” version of the work, similar to a multi-track master for an audio recording, which contains the sum of all past commits. When a worker begins changing the project, he updates his local copy of the “master” branch, and then creates a new branch off of this local copy of master where he will do his work and create commits as he completes it.
- master is not a stable, static thing – it is changing constantly as others complete work. When worker A is done, he will integrate or “merge” his changes back into the master branch. Here he must fetch whatever other commits have been “merged” by worker B, C, D, E, F, etc. This may trigger an event requiring him to consider how his changes should be integrated with everyone else’s work before it will be pushed out for distribution to the rest of the company.
All of this is accomplished through a clever use of a graph data structure and hashes. If you’re interested in learning more, I suggest getting a book about how Git’s internals work.
Taken together, Git’s features allow worker A to work on a small piece of the total project without coordinating with worker B, and yet also ensures that worker A’s hard work will be integrated into the project. Hopefully you can see why this system is ideal for remote work.
Software people, I think, underestimate how powerful source control really is. I greatly doubt that lawyers, accountants, or civil servants have a similarly sophisticated method of working independently.