When I decided to switch from Eclipse to vim, I remember being apprehensive of the clumsiness I would have to experience while facing vim's supposedly steep learning curve. I would have to lose lots of handy features, try to regain some of them plugin by plugin and survive with vim's at the time somewhat alien interface until I got comfortable with it.

One thing that helped me regain a lot of the speed I formerly had was a very low-level feature: the ability to split windows. While on Eclipse, I had not
even considered doing it because my window was filled with very "handy" panes that would show me a file tree, methods in the current file and so on. Once on vim, I found plugins to have those kind of panes back, but I did not seek to enable them by default because by the time I found those plugins I had realized a very important thing for my new workflow, something even more important than the fact that I did not really need a menu:

Being able to see several files at a time is way, way, way more important than having any of those panes.

It is the same kind of feeling you get when you start working with an additional monitor.

When I work on a piece of code, I typically have my vim window split in 4 or more vim "windows": the separation of concerns makes it so that you will often work with a service, a controller, corresponding tests, a template, some models and will need to quickly switch back and forth between them. When using Eclipse, I would often Ctrl+click keywords and navigate through the code, each click leaving me with one new tab I did not really care about, and then I would cleanup tabs I did not need. With vim, those tabs do not show up. They are still in the so-called buffer list, but that one is not visible by default.
I found that a bit stupid at first, but then it clicked: just split your window several times, and display files you really care about. Instead of remembering their name and looking for them in a long list of tabs only a few of which you actually care about, just look at your screen and recognize the file by its contents. The switch is instant. And that is if you need to switch, because sometimes, all you need is to read something in the file, not edit it. And if the file you want is not displayed, either split even more or consider replacing one of the windows you already have with the buffer that has the file you need. That file switch is a very low level action, and it is important to get right because you have to do it all the time.

And that's when I started paying a lot more attention to the length of the lines in my code. Nowadays, widescreens are the norm, and it seems to be an argument for people who disregard any limit in line length. But it is not about being able to edit files on an 80-chars wide terminal, like they often claim it is: it is about being able to see several files side by side.

And even if you do not see the benefit of split windows, ask yourself why this blog post does not span all your screen, or why newspapers use columns.
Spoiler alert, it is, among other reasons, because it is far more efficient to scan that than a long line of text. Convinced? Then start writing your code for human beings, start using split windows and tell your fellow developer about that.