DEV Community

Cover image for Why we started Devsession
Aram Drevekenin for Devsession

Posted on

Why we started Devsession

When I started developing, after a certain period of writing code alone, I was taught how to collaborate with others. I was introduced to version control tools (back then it was SVN, today it would be Git) as the point of coordination. My first impression was that someone was trying to play a trick on me.

In order to work along side my teammates I would need to:

  1. Work on my feature alone until I'm done
  2. Try to push my changes to the joint code base
  3. Have Git tell me what it understands are the contradictions I need to fix
  4. Fix those contradictions, and hope there aren't any more non-textual contradicting assumptions that the tool couldn't catch

This just seemed so needlessly complex to me.

We waste so much time on merge conflicts, and on fixing bugs that happen because Alice zero indexed the IDs while Bob one indexed them.

Development is team work, but as individual developers, our teammates' work is often a point of friction rather than a welcome additional pair of hands.

What if things could be different?

This is where Devsession comes in. We're building an IDE synchronizer that would allow you to have a Google-docs-like collaborative experience in your own IDE, and see your teammates type in real time.

Plug in a url (for example: into your IDE, terminal or browser and you're in the session.

Join a dev session from your own IDE

With Devsession, the code is shared between all members of the team, but each one still works in their own environment.
Devsession will also include a built in set of feature flags, allowing developers to switch each other's changes on and off if they want to temporarily work alone without having to diverge the code itself.

The feature flags are logical rather than textual. This means that instead of having a language specific feature flag such as if (my_feature_flag_name == true) inside the code, Devsession will be able to manage which parts of the code should appear in your editor depending on which flags you switched on.

In addition, Devsession will include a built in modern messaging system. Meaning that if you don't want to be interrupted in your flow, you could also set yourself as "Do not disturb", and then your teammates can always switch off your feature flag if they want to.

A depiction of a generic IDE with Alice and Bob writing code together concurrently with a set of feature flags they can use to turn each other's changes on and off

Share your terminal without sharing your cursor

Devsession will also allow you to synchronize your terminal, with each user having their own cursor rather than being made to share the cursor with others. This would allow developers to hop between the different environments of their teammates in order to be able to seamlessly pair on a joint problem in the middle of development.

This solution could also be used separately. In order to collaborate on solving a production issue or temporarily helping a friend out of a jam.

A screenshot of a terminal with multiple users connected, each one with their own different colored cursor

Say goodbye to meticulous coordination

Imagine you and your teammate are working on two different features, each one touching the same data structure. For example: in a social media site, both of you need to change the User model. One of you wants to add an attribute, and the other wants to change the type of a different attribute. Today, depending on our language or environment, we would often have to meticulously coordinate such tasks. Usually this would not even be enough and on the whole, we would be slowing each other down.

With Devsession, this problem goes away. We would both make our changes to the data structure and quickly fix any contradicting assumptions each developer's implementation creates.

Look through history with varying levels of granularity

How often did you try to optimize a piece of code someone else wrote only to end up with basically the same thing after a few iterations? No shame, it happens to us all.

Right now, if we need to understand a piece of code as developers, the only history we have is our git log. While certainly better than nothing, git commits tend to be of finished pieces. There is a lot of context about "why things are this way" that gets lost. We could ask the developer who wrote it... if they are still around - or if they even remember.

Wouldn't be cool if we were able to analyze a piece of code and see exactly how it was written? Kind of like going through an undo-chain in our own editor.

An upshot of Devsession is that since everyone is coding together in the same instance - the instance itself has memory. We could use it to better understand what was happening when a piece of code was created - and we could even edit it into a feed that developers could browse to find out what happened while they were on vacation.

Do you want to get rid of Git?

No, not at all! We believe Git is a great tool for version control, but that we've been misutilizing it as a collaboration tool.

We think Git should be used in tandem with Devsession, with developers deciding when to commit a larger change together as part of the code-base's evolution.

A diagram showing how a Devsession instance can be used as a client for git with developers connecting to it directly and together deciding to push to Git

Devsession is an open source company

Devsession was started by the team behind Zellij. We intend to use Zellij as our technological infrastructure and be the first major app in a growing ecosystem around it. To that end, we intend to sponsor the development of Zellij and work to improve it and nurture others who might benefit from the infrastructure it offers.

As a free service to the Zellij community - Devsession also intends to offer terminal sharing over the web for free. Sharing that will not lock users in to only having one cursor each. But instead allow them to work separately in the same session. When we launch, we intend for terminal sharing to be as simple as sending a friend a URL: They would open the URL in their browser or through Zellij and immediately start working together.

A diagram showing multiple users connected to the same Zellij instance, some from a browser and some from terminal emulators, assisted by Devsession in order to facilitate connecting to the session through a url

Devsession itself intends to be as open-source as possible. Pursuing revenue by providing services rather than creating intellectual property.

Sound interesting? Want to learn more?

Sign up for early access!

Top comments (2)

ben profile image
Ben Halpern


michaelrosejr profile image

Interesting idea!