VIM is extremely powerful and configurable, allowing developers to set it up in a way that matches their preferences and workflow. However, this also brings a big issue: using another person's configuration can be rather frustrating.

This problem is even more accentuated on a pair programming rotation with many teammates and many different setups. Some teams try to mitigate this issue by coming up with standards and default mappings, however, even though this can be an effective approach, it also sacrifices flexibility and it may undermine organic configuration improvements.

In my setup, I follow a few rules that help me keep my configuration flexible and approachable. They may be handy and give you some ideas on what can be improved to make your (and your team's) life easier.

My good practices

1. Learn how to do it in the VIM way first

Before creating a new mapping or installing a new plugin, search for how to do the same task using VIM's default commands. You'll be surprised by how many things can be easily accomplished using what comes out-of-the-box.

By doing this you may get two benefits: You'll be able to work when using a vanilla VIM configuration and you will avoid bloating VIM with unnecessary mappings and plugins.

My rule of thumb is: I only use a mapping or plugin if the command is too complex to remember. Everything else I prefer to keep as it comes.

2. Try to not override default mappings

Every time you are pairing on someone's else machine, which does not have the same mappings you have, you can rely on the default commands to accomplish the job. Well, as long as they are still available.

I've seen many people overriding default mappings with their preferences and even plugins suggesting mappings that conflict with VIM defaults. For someone trying to use your editor, this can become annoying and frustrating very quickly.

As a good teammate, you should keep the defaults working just fine so other people have a fallback in case they are not used to your mappings. Replacing a few silly mappings is fine, but changing some important navigation command is mean.

3. Only set mappings for things you need quick access

A good way to keep your configuration simple and avoid collisions is to set mappings only for commands you use frequently or require quick access.

When setting up a new mapping think on how often you are going to use it. There is a chance you will never need it or when the time comes you'd have forgotten what it does.

4. Understand your peer's workflow

Every person has a preferred workflow. I don't like to use tabs and I use mainly ctrlP to navigate between buffers. A friend of mine, on the other hand, uses mainly tabs. He uses them like an accordion, expanding and collapsing as needed.

When starting a pairing session we usually define how we are going to work. If both can use their preferred approach without messing with the others, fine. If not, choose the simplest one. It's also worth to try other people's workflow, as you may end improving yours or even enjoying the new way.

5. Keep your config file organised

Maybe this one is not related to pairing, but it does help to share knowledge and avoid forgetting "why the heck is this configuration here". I usually add comments explaining what a plugin does or why I use a given configuration.

Your future self will thank you when reading your documented configuration.


In summary:

Keeping your configuration sane and accessible helps your pairing mates to have the same joy and speed you have when using your setup. Also, make sure you share your good practices, so people can learn from them.

Photo by Kevia Tan on Unsplash