Why You Should Invest Time Honing Editor Skills

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” — Abraham Lincoln

As a software developer, I often need to collaborate with my colleagues on some tasks, like pair programming or simply helping others to troubleshoot a problem. During this process, I get to see how others code in their environment and all too often I find developers not using the full (or even the basic) potential of their chosen IDE/editor. I can see that such unfamiliarity with coding tools has reduced their productivity and sometimes even impaired their creativity. So in this blog post I would like to talk about why I think all serious developers should invest at least some time to hone their IDE/editor skills to increase productivity and thus set on a journey to become a better developer.

But as long as I write good code, why should I (or you) care?

OK I get it, because I have been there myself. I had that exact same mindset when I first started out learning to code. At the time it just feels that learning the basic of programming is far more important than knowing a bunch of tricks about how to do fancy stuff with editor key bindings. Even now I still believe this is true for most beginners, and there is a reason behind it.

As a beginner, most projects you will be working on are likely to be smaller toy projects. Usually they consist of very few source files and hopefully not too many lines of code in any of them. At this stage the project size is so manageable that you can survive without any sophisticated editor functionality. You can just do everything manually without spending too much time!

But as time moves on, and hopefully your skill advanced, you will eventually come across some Godzilla projects that consist of thousands or even hundreds of thousands of source files, and not to mention the sheer number of lines of code that resides in them. Soon you will realize the old way of mouse clicking through a file structure tree to locate the file you want to read or update becomes a mission impossible. And what if you need to update a function that you don’t even know where it lives? What if you want to see who has changed that line of code that you don’t understand?

In addition to these “hard” problems you will be facing, there are some less noticeable effects that can affect your productivity. I remember one time when I was helping a colleague to debug and we were following some complicated function call chain. The unsmooth code navigation interrupted my thought process so many times that I had to bring up my editor to check on my own. I like to think of an editor as an extension of your brain. At the same time if you are not smooth with it it can also become a bottleneck of your mind flow. I am for sure not a fast thinker and I definitely don’t want my tool to slow me down even more.

My last argument is probably more biased by my own experience. But for what it’s worth, I have noticed all great coders I’ve known are extremely proficient in their chosen editor and they love to talk about their setup, with passion and pride! Just like a master carpenter cannot make a perfect furniture without being proficient in using his/her carpentry tools. Even though it’s not a deciding factor in judging how good a developer is, I believe tool proficiency is a good indicator showing how passionate you are in coding, and passion leads to excellence.

I’m sold! Where should I start?

Hopefully I have convinced you that it’s a good investment to learn your editor very well. And you have decided that you will spend your next weekend or company held hackathon to sharpen your code editing skills. But most people might get overwhelmed by just how many features/plugins there are for any editor environment. Where should you start?

My experience is to find the most frustrating thing you feel when working on code, then Google how to solve it with your editor. It might be that you want to locate and open any file within 1 second. Or you want to jump to the code you were working on after you have navigated to some other place to check something. Whatever it is, learn one thing at a time. Make it a muscle memory so that you don’t need to think about it when you perform the action. Then find the next thing to tackle. Eventually you will be so smooth that you won’t even believe it! And others will start to get impressed by your editor skills with a gasp “how did you do that!?”

If you still don’t know where to start, here is a list of features that I use daily at work:

• Fuzzy file searching (very important when working with big projects)
• Auto-completion with function signature preview
• Jump to definition
• Code refactoring related (like renaming function across files)
• Git integration (running git grep then jump to grep result, inline git blame etc)

By the way I am a Vim user (R.I.P Bram Moolenaar). Most of the functionalities above I achieve through plugins and language server. If you are a beginner and not sure what editor to use yet I highly recommend learning a text based editor like (Neo)Vim or Emacs. A mouse free coding experience would give you the maximum concentration on the work you are doing.

Advanced

Now you are an expert in your editor, great for you! What next?

If you have achieved everything you have ever wanted with your editor, then you can live happily ever after! Maybe also share your knowledge with the new guys/gals in your company or your editor community. They will thank you for that!

Or maybe you find some feature that you really want but couldn’t find a plugin for it. Then write one yourself! It might feel intimidating at first but once you get the hang of it, it can be really easy and fun.

I wrote a Vim plugin at work so that I can connect to our test environment easily. When I’m in a test suite, I can just run any test case under cursor with a simple key binding. I can also run multiple selected test cases highlighted with Vim’s visual mode. This feature I have been dreaming for so long and I was so glad when I finally implemented it. I made a presentation and shared this plugin internally. After the presentation one participant told me he thinks the plugin is really cool. And I’m very happy to see that some colleagues start to use it afterwards. Shared fun is double fun!

Final words

Whichever level you are in right now, there is almost always something in your work flow that can be improved. Invest some time to solve it. You will thank yourself for doing that later. Happy coding! :wq