Why Remote Engineering Is So Difficult

It's good that it dulls the bad side of human interaction, but the converse is also true; and therein lies the rub.

The only thing about remote work that is different than local work is communication paradigms. Specifically, whereas you could normally poke your head around a corner and interrupt someone to ask them something trivial, with remote work it's harder to forcibly intrude on them and get instant feedback. And I think that's what people have a hard time grasping: how to 'work' without instant feedback?

Of course we all own a telephone, so the instantaneous-ness is always there. But timezones create a mandatory delay to availability which can't be easily worked around. So whereas people are normally very accustomed to working via a continuous flow of real time communication, they now have to learn to communicate via delays and compartmentalize decisions and production.

Some people can't deal with this. So they start to find ways of splitting up work by location. But eventually, things get out of sync, because they never learned how to communicate in a new way. This then creates things like a mandatory daily meeting just to figure out what's changed in the last 24 hours, or red tape designed to keep people from making decisions on their own, or a lack of any kind of tape, or a breakdown in leadership, or the inability to accomplish tasks independently, or lowered morale, etc. This lack of being able to cope with communicating and working asynchronously is, I believe, a sort of stagnating death spiral that (without seriously competent self-starting workaholics) just results in mismanagement and tepid progress.

As a contrary example I like to use the open source development world. They work on different parts of different projects in different regions all the time. They self-organize and come to consensus quickly, and are led by a small team of well established hierarchy that makes quick, decisive executive decisions. There is basically no bone-headed executive level muddling with your work, nor contemptible middle-managers fighting for power, nor tepid low-level engineers waiting for someone to make a decision. Everyone just gets shit done because they all have one goal: to ship a good product. That's all very nice because you aren't part of a corporation, and you feel like your contribution matters more.

But in a corporation, you have to deal with all the usual corporation bullshit, in addition to now working asynchronously. I think this is where the big breakdown occurs in practice; two different sets of problems (asynchronous communication, and corporate bullshit) add up to a more complicated way of working. If you're very lucky, everyone will be able to work the same way and things will go smoothly. But in practice, not everyone works the same way, and thus bugs crop up in the work due to process incompatibility.

So why is remote engineering difficult? It's not; it's just a specific skillset.

That problem exists for local work in the same way, no? If you can 'git clone' onto a dev machine, you can also copy that git repo to a USB stick.

Efficient dev environments can't be totally locked down, because often people need to experiment with some parts of the environment (for example to reproduce bugs that only happen in some environments).

Yes but unless the local employee anticipated to be fired, most of the times they won't have made copies of the work.

When you tell them they're fired you can block them from physically accessing their dev machine.

Of course if you work on an open source project this problem go away, every employee is mandated to release their code ;-)

As a general rule, when talking about risks, you want to evaluate the cross section of Likelihood vs. Impact. Sometimes, you ignore high-impact risks because the likelihood of them occurring is just so low that it doesn't make sense to do anything about it, especially if there isn't much you can do about it. Like, "a meteor could strike our office, killing everyone inside". There's just nothing you can do about it[1], and if it does happen, there won't be anyone left to pick up the pieces anyway.

So I think you're underestimating the likelihood of employees copying code (it doesn't take anticipating being fired), and overestimating the impact it would have (it really won't do a damn thing)[2].

Every job I've had, the project code has somehow ended up on my personal computer. It has been a combination of factors. Generally, it goes that I get sick and declare I'll work from home. Either the company had provided a laptop or they hadn't, in which case I would have to use my personal PC to work. If a laptop was provided, the hardware was slow, or the tools installed were not my favorites (or particularly bad), or issues with the VPN connection/antivirus/corporate spyware software made everything slow. So in almost all cases, I've ended up with everything copied anyway.

And when I left the jobs, I had immediately deleted it. But even if I hadn't, even if I had taken and used the code (illegally), it really wouldn't have impacted the company. It's not like I would have been able to approach the clients and gotten them to go with me: typically the client owns the code anyway, I wouldn't have needed to copy the code. It's not like I could have started a competitor all on my own off of the company's own code base. And finally, the vast majority of projects just aren't that novel: why would I potentially throw myself into a den of thieves and lawyers for what is probably a crufty POS that I could replace in a weekend of caffeine fueled mania?

[1] oh, except, you know, not forcing your team to be co-located.

[2] This leads me to believe you are probably more the businessy/MBA type, rather than the engineering type. It's usually the MBA type who is most fearful of someone stealing the IP. The engineers who actually make the IP rarely consider it a threat.