Are we developing more or less remotely now?

In this Developer Happiness Hour the Stateful Panel discuss the evolution of remote development, the trend it’s going and some of the problems remote development has and the future of remote development.

To clarify, the team defined remote development as developing on a machine that typically lives on the cloud / server other than your own local machine instead of remote work which is the aspect of not physically working in a dedicated office, so working from home or co-working spaces.

Definition of remote development

• Working on a machine that is not your own
• Reproducible environments
  • Helps with the problem of “it works on machine why doesn’t it work on yours?”
• Example: cloud server hosting a virtual machine that contains your typical development environment such as your repo, the languages you use and toolings - extensions, linters, bundlers… etc.

How was remote development then?

• Developers would SSH into a box and run their development environment through the companies data centers.
• Internet speeds was a blocker. Latency would cause frustration as there was noticeable latency per keystroke versus what you see type on the screen.

The rise of remote development

• Popularity in remote work has influenced the platform to grow.
• Distributed teams needing to connect to the same project.
• The running of complex toolchains made easier to maintain and run.

Are we developing more remotely now?

Yes and no. It comes to project toolchain demands. But overall, remote development is a space that is getting more traction and is being implemented on IDE’s to have that native feel.

With developer tooling getting better:

• IDE’s are able to setup remote developer environments giving a “native / local” look, which developers are wanting when it comes to development.
• People just need an internet connection and can connect to a computer that runs an entire setup for your development needs.
  • Using codespaces or gitpod as some examples.
• Rise of containerization.
  • Docker
• Convergence of remote and local development
  • Not a which one is better but why not both type of relationship.

Use cases for remote development

• Guest Contributions
  • You don’t necessarily work on the project a lot and prefer not cloning the entire repo to your local machine.
• Enable projects to be setup for you on the fly. Just connect to the env container and you can start coding.
  • Configuration and tooling are provided, you just need to spin up an instance of that project remotely and you can begin coding.
• Moving vulnerabilities from your local machine to a cloud machine.
• Better debugging experience.
• Being able to test race conditions.

Fast Computer vs Fast Internet

The team opens a dialogue on which would they prefer - a really fast computer (M1 Ultra) but a spotty 3G internet speed or an older computer that’s dated years old but the fastest internet.

Lorenze - At first says a fast computer but changes his choice once the slow internet speed clarifies.

Adam - Chooses faster internet.

Christian admits that a slower internet would frustrate him more than a slower computer.

Sebastian also chooses the internet, realizing that he probably cannot use all the computational power from his Macbook to the extent of his available bandwidth.

Teams thoughts on remote development

• There’s a notion that if remote development feels like you’re developing locally then it’s in a good place.
• There is hope where members in a team or organization can create an instance of a development machine in any project and be able to tinker with the codebase with all the configurations setup for you.
• Remote development is not ready yet when it comes to performance in terms of feeling like everything is running locally.