I tried a new tool with Kyle Shipley recently, and it has proven to be interesting and useful.

Floobits is a recently-created remote pairing solution. Imagine wanting to pair with someone and they are across town or in another state.

I enjoy pairing remotely, as it lets multiple people work together even when they are not colocated. I think that pairing is a great way to share knowledge on a team and reduce defects by promoting accountability and quick feedback. Further, I think that remote worker morale increases when talking and working with teammates.

Kyle and I used Floobits to pair on a random coding project, and I found the entire experience compelling enough to get past the set up and some early wrinkles. With Floobits, you create a shared workspace that other people can view (public or invite-only). You install a plugin to your editor and maybe a custom build of the editor. Then when you make changes to the file, diffs of the code are sent up to a server, which then propagates to anyone connected.

Existing solutions

There are some solid existing solutions out there like sharing tmux or screen sessions.

I won’t go into certain things like Skype screen-sharing. In my opinion, both people pairing should have the ability to edit at any time except for very short sessions. I find it frustrating to have to spell out exact changes when I do not have control, and I think it is asymmetric enough to warrant looking for a better solution when the “pairing” will need to happen for more than an hour.

Positives of using Floobits

However, I think there are some unique advantages that Floobits has specifically.

One of the best features of Floobits is being usable across multiple different editors. For example, I like using Vim, and my partner can use Emacs or Sublime Text. I really like this over being forced to use a common editor.

Since I can use my preferred editor, all of my custom key mappings and settings work locally. This is useful because the muscle memory is preserved. You might even find that one editor or person is more effective at making certain changes (say, replacing text or reformatting markup.)

Being cross-editor and just sending file diffs to a server means that the service is cross-platform as well.

There is minimal setup and learning curve. Basically you just install something and you can use your local editor like normal. This seems preferable to bringing on someone and needing to get them up to speed with tmux’s commands before being fully productive. For consultants, this could be fantastic for working with people from different organizations and being able to let each side use the most productive environment for them.

Both people can edit concurrently, which saves time and sanity. We can both spike out a feature or syntax and see which way looks better. There is no need to coordinate ‘driver’ and 'navigator’. I can even look at different parts of the code while other parts are being edited, which increases engagement. Compare this to being locked into whatever view our pair is looking at when using tmux. Just like Google Docs, the changes are propagated to the other person’s editor without needing to save. Even in Vim, I see the other person’s cursor moving about. Wondering how they do that…

Worried about getting off track and not knowing where your partner is? No need to worry – your editor now has a special command called 'summon’ that will ask all attached viewers to look at the current file and line where your cursor is. There is also follow-mode, which makes your cursors follow theirs so both people type and see the same thing.

The web version has a full code editor, so you could conceivably edit from a mobile or tablet device. Rounding out the features, you can use a shared terminal which either person can type commands into and see the results of running. Floobits also integrates with Google Hangouts, so you can have everyone connected and not need to coordinate that setup. So far we have just used Skype, but Hangouts seem like a nice integration.

Possible negatives of using Floobits

Not everything is rosy, and there are some shortcomings at least at this time.

Syncing files between machines can be a bit flaky at times. There have been some ghost files that just show up and are hard to get rid of. We sometimes can’t figure out if it’s syncing too much or not enough. Sometimes I will have a new file locally that seems like it doesn’t get synced up for a little while.

Obviously the codebase of the editors and service is fairly new, so there are random display bugs and so forth, but I would imagine that these would improve over time. No show stoppers yet.

Sharing code with any external service means that they could conceivably look at your source code. So you need to consider the security of this in the event that you work on valuable code on Floobits (even in a private environment.)

While I found the shared terminal to be useful, it can be slightly risky. For example, anyone who has edit permissions to the project can type rm -rf something and cause some damage. It would be interesting to explore a different model that has your environment in a sandbox of sorts, even at the cost of some flexibility. That said, you should probably only open a shared terminal with people you trust at this point.

Extensions

For companies or individuals that advocate transparency, live coding on an open source project in front of the world is a great way to be transparent. Anyone can connect to a publicly accessible project, so you could get people who follow along and might want to help out coding. It could be someone interested in the project and how you are coding it, or maybe someone who is trying to advance their own skills. Moreover, it could be a good avenue to find new pairing partners.

I could see conducting live code interviews using Floobits since it allows people to code in whatever editor they feel most comfortable working in and has a shared terminal to view test results. Sharing editing privileges are not even necessary, the workspace could be read-only.

#pairwithme :)