Early on during The Plague I wrote a lot about remote work. It’s been a year since I’ve updated that so how’s it going? I’m still skeptical and the situation still seems inconclusive. Many businesses and salaryfolk seem desperate to get back into their office park corrals. I’ve called out tech in the past for being the most absurd industry to resist using tech instead of offices. I did however just spot this in The Economist today.
I hope it’s true, but I continue to postpone making a big bet on the matter one way or another. Another year has passed and we still don’t really know how life will be different.
I could just tack that as an update to my previous post about this, but this post is really to share an unusual opinion I have about remote work: competent programmers always work remotely. Even if your software controls robotics, remote sensors, manufacturing processes, autonomous boats, or some other location based real thing that forces you to be "on site", for programmers it is still worth always having the mentality that you are working "remotely". Before exploring why I think that, I’ll quickly review the normal obvious reasons programming remotely is preferable when possible.
I’ve talked about how people who make tech-based communication systems should be comfortable collaborating via tech-based communication systems. A good counter argument might be the one implied by this Time article about a famous telephone company, "Bell Labs needed to house its critical mass of scientists and engineers close to one another so they could exchange ideas; it also needed to give them all the tools they needed." Sure, and they produced some great stuff. But how much of that really improved telephone service? What if all those guys were forced to work far from each other and spend most hours each day on the telephone? I’m guessing we’d have seen some more notable progress in the areas that they were actually being paid to improve! If those guys were incapable of using telephones like that, well, that’s a pretty damning limitation.
Some people believe that even programmers benefit from mentorship and
close collaboration. I know this because I’m one of those people. But
I draw the line well before we’re holding hands under the partition
while we share a bathroom to take a morning dump (BTW - do the thought
experiment to consider what programmer bathrooms are like when the
office park is designed for an ordinary gender distribution that is in
practice quite extreme). I’ll go
one better and say that — like Donald
Knuth — I’m a big fan of
pair programming. But
why can’t collaborating programmers simply share a screen? (Hint: They
can: screen -rx.) If we can discuss the code while editing it from
the same editor at the same time while we both use our own comfortable
keyboard and monitor setups, what exactly could be missing? Back rubs?
Really excellent smelling deodorant?
Proponents of the tech bro mosh pit (who think it through beyond "that’s what Google does") often cite enhancing the ease with which spontaneous interactions can occur — presumably to exchange all those profitable "ideas". Whenever I hear such a thing one word pops into my head: distraction. When programming I tend to do the heavy lifting hard parts very late at night when the rest of the world has gone to bed. When you take programming seriously it is like an elite level sport; maybe a little league parent can yell some truly good advice to a player, but anyone in the stands trying to communicate like that to a professional is heckling. But even then I’m receptive to whatever great idea (or banal meme) you think I should know about — over email or IRC (or even Discord or Slack). Share whatever you want with me any time, even ask me to voice call you, fine — just don’t make it impossible to temporarily ignore you while I’m trying to concentrate!
I understand that points like that are debatable. Let’s turn to something more inevitable. When a programmer writes computer code, the hope is that a computer will read it. What is inevitable (if the code is actually ever used) is that it will have to be read by a human — a remote worker. Why remote? Because that person is very likely to be your future-self. When you’re editing or debugging programs, they were often handed to you by your past-self just like the remote night team in India or Australia might hand off a project. Unless your commute involves time travel, those other selves are working remotely to you. But wait! Surely deciphering something written by a completely different person is much more cryptic than your own work, right? Wrong.
People unfamiliar with actually programming computers might think that it would be reasonable to remember something about the experience, but I can assure you that projects can evaporate completely from memory very quickly! The way this has been impressed on me even long after I’ve known to be diligent about documenting things for my future-self is when a project I think of as currently ongoing gets interrupted. Even a few days away, I can come back and forget everything that I had done. The number of times I’ve spent serious energy just trying to find the files of a rough prototype I whipped up a couple of days ago is embarrassing! As someone especially proficient at remote work, I’ve even had to hunt down which computer I was even using when I started playing around with ideas that later turned into a project.
Locking in the iron discipline required to always assume you’ll be handing any project off to a complete stranger across the globe at any random moment is strangely the correct way to think. Hopefully it is painfully obvious that this is better for the company that hired you for a thousand reasons. But what is counter-intuitive to inexperienced programmers is that it is actually crucial for you to think this way all by yourself.
This is why I pride myself on being able to work asynchronously and remotely with strangers. That’s how I work with myself! It is why being literate is useful. It is why being able to use technological mediums to communicate complex ideas is helpful. It is why concurrent version control is a big deal. It is why commenting and documenting code is so important to both do and do well. It is why having a very good technical system for technical notes is essential. It is one reason why I practice by writing blog posts to my future-self!