Forem: Filipe Monteiro

How switching to VIM DIDN’T help me to be more productive

Filipe Monteiro — Tue, 08 Dec 2020 16:35:30 +0000

TL;DR: If you came here for the title, I’d like to apologize, I like VIM and although I don't think it helps me to be more productive, it's fun to code using VIM.

2013 was the first time I heard about VIM, while editing apache configuration files in a linux server. I used to use Nano for the job, and couple friends tried to convince me that VIM was the way to go.

Nano was more than enough for me: Open, Edit and Save files, that’s all I needed. Why would I use a program that I didn't even know how to close it? No way!

Over the years, I got more curious about VIM, many developers could affirm that they were more productive, just by using VIM. That's mind blowing, isn't it?

Then I thought: Why not give it a try? After a couple days trying and reading about all different commands I had to learn, I was completely sure: It couldn’t make me more productive! The reason: Learning more commands to code didn’t make sense at all. Mouse + a few command/ctrl + arrow commands were absolutely more than enough.

When did VIM make sense?

In April 2019, I decided to give it another try. This time, I was committed to make it right and get into it for real to see if there really was a benefit on VIM. I’ve bought and online course on Udemy, Vim masterclass, and took all classes patiently, as I was learning a new programming language.

I got impressed with all the things VIM could provide.

All the motions, modes, registers seemed simply awesome. The fact that I could scan a file without editing it was amazing.

Deleting a word or a couple words with only 3 key strokes was neat. If you’re curious, open a file on vim, and press: d2w. (delete two words).

After the course, I moved slowly, started by setting up the vim plugin into my VScode, relying in all the easiness that VSCode provides and yet I could practice vim commands.

I use the vim plugin for a while and struggled a lot on the first months. Mixing wrong commands, forgetting about caps lock turned on and I was coding slower than I would with normal setup.

Fully Switching to VIM

The full switch to VIM happened in 2020 (the year this blog post is written).

The reasons:

Although is great to have VIM commands in VSCode, the best plugin isn't that perfect yet, and there were a couple commands that were super slow, and just moving around in a file was painful.
I was so upset with my VSCode eating up 4gb of RAM with only one project open.

I started to plan for a full switch.

After some back&forth from VSCode to VIM, I’ve found a tutorial from Ben Awad (https://www.youtube.com/watch?v=gnupOrSEikQ), helping to set up vim as a full IDE for typescript/react projects. I got his dotfiles, added some tweaks and went heads down on that.

More struggle! I’ll have my criticisms to VIM listed below, but here is one: One of the most powerful things on VIM is extensibility, plugins are first-class. But that’s what makes it so complicated to use as your main coding tool.

After a long set up process, do and undos, VIM (Neovim) is my official code editor. It’s working great in a large typescript codebase and I’m completely used to it. Node & Chrome are my only outstanding RAM eaters.

Am I more productive now?

All of that to say: do I feel more productive after switching to vim? Short answer is: No.

Do I believe developers can be more productive just by using VIM? Maybe?!

I’ve seen super productive developers using VIM, and I met super productive developers using IDEs.

Keep in mind, Productivity is not tied to the IDE you use, neither your seniority.

Things like: Clear tasks requirements; Great communication skills; Solid knowledge of the core concepts of the language and framework you use take your productivity bar way higher than just using VIM.

But I have to say, coding using VIM is fun! Not using your mouse to scroll up and down or place the cursor is magical.

If you've got until this point, let me tell you what are my favorite and things I wish were better in VIM.

Favorite ones:

VIM is lightweight! If VSCode or IDEs drive you nuts by eating up your RAM, give VIM a try.
Installing and using plugins is super easy, check out vimplug.
Creating shortcut for commands is straightforward and clean
Macros are simply amazing. Record commands and replaying them is sweet.
Navigate on your file tree with your keyboard and the same motion commands is amazing.
Closing and reopening vim is fast. You can do that almost instantly.
Switching to a new computer is as easy as installing VIM and place your dotfiles in the right place.

Things I wish were better in VIM:

As I pointed out above, being super extensible is also a drawback. Basic things are not out of the box, for example: you need a plugin to navigate on your file tree in a decent way. VSCode and other IDEs have that for free. But in VIM, you’ve got to set it up yourself.
The learning curve is high.
It's a pain to do a simple Find & Replace in all files. Although there are a lot of great plugins, if I need to perform that task confidently, I open my project in VSCode and use it.
As many things in VIM, autocomplete isn’t out of the box. You’ve got to set up LSP for the language you want to work on.

Conclusion

Give VIM a try, it may help you or not to be more productive, but I assure you the coding can be way more fun using it!

And if you're planning to fully switch to VIM, I highly recommend you to use tmux or any one similar.

Add a planning step to your dev workflow and be more efficient!

Filipe Monteiro — Tue, 28 Jan 2020 15:00:55 +0000

That's a short post, but here is the TL;DR: Before jumping into code/project, plan it before hand, take a look at what might need to be changed, what might need a refactor and take notes about it. Follow your plan and you'll be way more efficient.

If you don't want to read the reasons about why you should have a plan, just jump to How to create a good dev plan.

We, developers, love coding. Nothing can be more boring than a working day without a single line of code and it's very common that this love make us a bit anxious for coding and when we see a shiny new project/task/ticket, we're like dogs wagging our tails looking forward to get started.

There's nothing wrong with that, we're developers and love coding, but have you figured that by doing that we're often more inefficient? I'll tell you why.

Why we're more inefficient when we start coding right away (without a dev plan)?

You've probably faced that before: you get a new ticket to work on, right away you jump into coding and start working on that and after a couple lines of code, you see that the lines you've added are not in the correct file (maybe because of architecture decisions or just the wrong file). Then, you delete your changes and find the correct file, apply the changes, but wait, your lizard brain tells you that there's something wrong, you need a refactor before adding that code.

So, you start doing that refactoring and that takes all your day, by the end of the day, you figure the refactor wasn't needed and you get back to your first strategy (or try a new one) and that cycle repeats until you get your project done!

Can you see how inefficient that dev approach is?

We're way more inefficient when we start coding right away, because our ideas of what needs to be done aren't in the right place yet, they're not connected to each other, also unless you're starting a brand new project, your new code usually will need to communicate and fit to other parts of the codebase, if you start coding without a plan, how do you know which parts of the codebase that may affect?

So, what could we do to help ourselves to be more efficient? Add a plan step before you start coding!

Benefits of having a dev plan

Before flying an aircraft, pilots are requested to create a flight plan, they never (shouldn't) fly without a plan, there are a lot to consider before taking off, landing and flying: Aircraft weight, winds, best route, altitudes, weather, speed etc. By doing a flight plan, pilots are able to find the most efficient way to go from A to B safely and efficiently.

And if you're not sold yet, here are some benefits/reasons for having a dev plan:

Having a dev plan before dev kickoff helps you to understand what you're supposed to do, before you actually do; where you will apply your changes; and what should be the desired result (code wise).
Having a plan before you actually start coding, helps you to communicate to your teammates what they should expect when pairing or reviewing your code. By doing that you've shorten the feedback loop (yeah, the feedback loop is everywhere, either if you're pairing or someone is reviewing your code).
Having a plan helps you to be way more happy when coding, you know exactly what have to do!

How to create a good dev plan

Hopefully, you should be sold that you need a dev plan, right? so how can you create good one? Here are a few things to consider when creating your plan:

Make sure you understand all the requirements, if you have questions, ask them before coding, never try to find the answers while coding, you will end up writing code that will be changed or even deleted, be efficient! I recommend that the first section of your dev plan should be a summarized description of the project requirements, that also helps you to have them more clear in your mind and it's also a good rubber duck.
Go to the codebase and look for what needs to be changed to get your project done. Will you change how a component works? Write that in your plan. Will you need to refactor a whole section to prepare the code? Write that in the plan. Will you this only need new code and nothing will be changed? Write that in the plan.
After you know what to do, and how you will do it. Plan the best route to get that done! Does the refactor needs to be done before all other parts, list it! Organizing what and how you will do it in steps will make you way more efficient.
Sometimes the project we're working on has a limited time scope, so saving a refactor to another time is helpful, right? Even if you're not doing that refactor/change along with your project, you should still write that in your plan.
Run your plan by your teammates and ask for their ideas and approval. Your teammates might be aware of what is going to be changed, how and why. Having another set of eyes in your plan might help you to decide and change the route to get that done, and the best part, before you've written a lot of code.
Sometimes is really hard to create a plan, you need to test something new, the code is a bit messy. In those cases, create a plan for a prototype or investigate, let people and you know that you're going to do that before jumping into the real code. After you know what to do, update your plan with your new strategy.

When you don't need a dev plan?

Not always you need a dev plan, sometimes a bug is really easy to fix, or a feature is easy to get done. In those cases, go for it and CODE it. But if something that was supposed to be easy, is not going as you expected, stop it, and write a plan! (or maybe you should've done it before 😬)

Always remember: Coding without a dev plan, is like flying an aircraft without a flight plan, you can get there, but this can be way more expensive than you expected.