vim is my text editor soulmate¹. But I've gone and done a Brutus by betraying vim and using a different editor. And I did it on March 15th², the Ides of March. Or is it the IDEs of March?

The betrayal happened slowly, then all at once.

For the past few weeks I've been ruminating on the pair programming experience I have had at work. Mostly, we've used screen sharing and that's a whole pile of pain I'd rather not talk about. Meet and Zoom are great for some things, and the things they're great at are decidedly not sharing a window of text that's scrolling at a decent clip.

So I was thinking about how bad it was, and I was dreaming about what I would want in an ideal tool. I would want:

• vim integration, of course, because I'd never use a different editor (foreshadowing)
• real-time collaboration with my pair, because I want us both to be able to type
• sharing both editors and terminals

But then I was pairing with two of my friends at different times.

The first one, we were pairing on some machine learning, so he had us use a collaborative Jupyter notebook. It was really cool, because we were both editing different cells at the same time. We were able to work quickly, coming together for the parts that matter and going separately when that made sense.

The second pairing, my friend is learning Rust and I was helping him get started on a small Rust project. His screenshare wasn't working so instead, we fired up replit and started the project there. That gave us almost exactly what we wanted: real-time collaboration in the same file, shared terminals. No vim integration, boooooo.

But it was profound. While he was writing some code, I went off and wrote a test for it, and we got a lot done. And when something was confusing, I could take the reins and type an example directly in the code.

That's the experience I want every time I pair, but replit for all its good things isn't a tool I can use at work. So what's a person to do?

More searches, that's what.

I stumbled back on VS Code's Live Share. We used it for our next Rust pairing session and, and at risk of sounding like a commercial, it was an incredibly smooth experience. We each had our own editor themed how we like it³, and we were able to both work in the same files, in the same terminals, at the same time.

No blurry text. No laggy video.

Since that pairing session with Live Share, I've used it a few times at work. It gets better each time as we get used to a different way of pairing. Maybe this is old news to everyone else, but it's really changed how I pair at work. Instead of just doing driver/navigator over a screenshare, we have another mode of "parallel pair programming"⁴ available.

Here are some of my initial observations from pairing with Live Share:

• Both having an editor available increases engagement. With driver/navigator over a screenshare, it is often a struggle as navigator to stay really focused and really engaged. It's so much easier to stay engaged when you have the files in your editor and you're both staring at the same thing but also have control over your own environment.

• It gets you unblocked easily. Just like with all pair programming techniques, one of the key draws is that you can get unblocked really quickly. With sharing an editor, you can more easily pass the keyboard back and forth so that your pair can enter a little code if you're stuck or you don't understand a suggestion.

• It lets you program in parallel. With driver/navigator pair programming, I usually felt like one person was always a little under utilized. Collaborative editors let both people can write code the way they normally would, but you come together for key decisions and for tricky things. It also means that you can do really effective TDD in parallel if you so choose.

• The tedious changes are twice as fast. When you have to go through and change the arguments passed into a function in a bajillion different places? Now you have two people typing those changes at the same time. Sign me up.

• Working in the same environment means sharing compiler errors. If you're both writing code at the same time, you'll occasionally break each other's code, or just flat out break the build. And then you get to help unbreak it! This is usually not a big deal, since you should be working on related portions of the code (if not, stop and work on your own or work together).

• You can still do driver/navigator when you're in unknown territory. Having both people write code is great when you're on familiar ground and you know where you're going. When you're coming on unknown territory, it helps to still do the traditional driver/navigator mode. That way you can have someone looking up docs, thinking about edge cases, etc. while someone else is focused on the task at hand.

• It's great for teaching. Sharing code while on a screenshare is awful. The victim student is forced to follow at your speed and watch the code over an inevitably choppy video feed. If you use a collaborative editor, they can move around as makes sense to them, but can still follow where you are.

• Some things don't work super well this way. One example is when we need to explore through a lot of docs and just straight up read them. I know this is something that you can theoretically do while pairing. My brain turns off its "read the docs" function when I'm pairing, so this doesn't work for me! So that's one of the tasks that just won't work in this mode and is reserved for solo work.

I'm sure I'm just scratching the surface of this mode of programming, and I'd love to hear wisdom from anyone who's done it and found joy or sorrow. And if there's an even better tool out there, let me know! Especially if I can use vim with it.