Preface

I spent a few hours spread over the last couple of weeks to learn every single one of VSCode’s keyboard shortcuts, specifically the 149 shortcuts from the official keyboard shortcuts reference. These are also present in KeyCombiner’s searchable table of VSCode shortcuts.

Admittedly, I started this challenge to write a blog post about it afterward and as a way to promote KeyCombiner via content marketing. The blog post I had in mind would be similar to my previous one, documenting my process of learning 50 new web application shortcuts in 42 minutes.

But, as it usually happens only in romantic comedies, my intentions changed over time. This article turned out much different. It is not about the learning process but about how this challenge changed some of the developing habits I had for many years. Workflows that I grew used to during many projects, different IDEs, and even varying programming languages suddenly evolved.

Habits are Hard to Break

As software engineers, we like to think that we are continually learning and improving our skills. This is certainly true when it comes to the technologies we are using. However, our development habits, such as which features of our IDEs we use, are much more rigid. I believe most of our core workflows are formed early on and very hard to change. I don’t have data to back this up, but when I look at myself, my co-workers, and other developers I know, this certainly seems true. If you think about it, it is not surprising, the same thing happens in other areas of life. For this very reason, you will find that developers who have studied or worked together will often use similar shortcuts, similar IDE features, and have similar limitations in their workflows.

The usual way to combat this is reading books, blog posts, attending conferences, well, everything that is used in our industry to extend our knowledge. However, with fundamental developing habits, I have found that this works poorly. You might read about a neat feature of your IDE, or see someone demo their workflow, but when you are eventually sitting in front of your screen and writing code, it is easy to fall back to what we already know, what is already set up, and proven to work.

After this experiment, I am convinced that keyboard shortcuts are the main factor in how we form our developing habits, and they can also stop us from evolving our habits. Even before this challenge, I felt that I was good with shortcuts. I knew quite a few refactoring shortcuts, knew how to pause and stop program executing during debugging, was decent at jumping around between files, searching through my project, and all the other usual stuff. When I saw a co-worker using a shortcut that I didn’t know, I was quick to incorporate it into my workflow, too. After all, I was enough into shortcuts that I built a whole side-project around learning them. The thing is, all new shortcuts that I learned were the ones that would augment my existing habits.

This is a hen and egg problem; if you don’t know the shortcuts, you will not start to change your habits and use new IDE features because, without shortcuts, they are too tedious to use or not at all usable. But if you don’t form new habits, you will not learn the shortcuts.

Without intending it, I think I found a way to break out of this cycle: Learning all IDE shortcuts very well before getting back to work. By learning all shortcuts, you are not limited to what somebody shows you and might not be compatible with your situation. You can naturally include what makes sense, in addition to your existing skills.

The next section shows how this worked for me.

Evolving my Habits

I started the learning process as it is usually done with KeyCombiner: By importing some shortcuts from the public collection of VSCode shortcuts into a personal collection. Intuitively, I started with the ones I already knew and some additional that seemed most useful to me. Back then I was still trying to show that I could learn all shortcuts very quickly with KeyCombiner. I didn’t expect that shortcuts that had nothing to do with my existing workflows will be the real deal.

Some of the first combinations that I picked and that I did not know previously were alt+w/r/c for toggling find options (match whole word, regex, case sensitivity) because I was already using those features. This went on for a few days. I did a couple practice runs every day and added new shortcuts whenever KeyCombiner was saying that I mastered all of the previous ones.

Eventually, I knew all shortcuts that seemed useful for how I was using VSCode back then. So I had to start adding shortcuts that had nothing to do with my existing habits. This brought up an interesting misconception. Often keyboard shortcuts are seen as a way to do things faster, compared to using the mouse. While that is true, I think there is an even more important aspect to shortcut usage in IDEs: Many features are not used at all, if you don’t know the shortcut!

As I was learning new VSCode shortcuts every day, I started to use features that I previously didn’t even know of. One of the first things that suddenly made a lot of sense was Select all Occurences of Find Match with Alt+Enter as default binding, especially when combined with regex search. I was so excited about it, that I even tweeted a Gif showing how I use it to modify the CSV files that are the source for KeyCombiner’s public collection tables.

The process worked both ways: Sometimes, while I was practicing a shortcut on KeyCombiner, it seemed apparent that this was useful and that I should include it into my workflow. Sometimes it hit me while coding that I had just learned a shortcut that can make the current task more efficient.

In the following, I describe the most significant changes in my daily development habits. The list is far from complete though; there are many more small things that I picked up and frequently use now.

Editor and Panel Management
Since knowing all the shortcuts to switch focus between panels and move editors around, I am using VSCode’s powerful layouting capabilities much more. I have 3-5 editor panels open at pretty much all times, seeing many related pieces of code at once. Working this way by using the mouse is very impractical. I switch between editor panels with keyboard shortcuts and move editors from one group to the other.

There is one negative side-effect, though: I am starting to get annoyed when I use other IDEs (PyCharm, Eclipse), because they lack far behind VSCode when it comes to using multiple editors.

Multi-cursor Editing
If you don’t know the shortcut to add additional cursors, I doubt you will ever use this incredibly powerful feature of VSCode. It is a typical feature that only blends into your habits once you know the shortcuts. The basic commands are Ctrl+Alt+Up/Down for adding cursors above/below. However, I found the commands to Insert cursor at end of each line selected (Shift+Alt+i), and the above-mentioned Select all Occurences of Find Match (Alt+Enter) even more powerful. These commands are why I frequently paste text snippets into VSCode, apply a few operations, and then copy-paste it back into whatever application I was using.

Opening views by shortcut
I sometimes tried to do this before, but it never stuck. Now I finally switch to all views (Explorer, Debug, Search, Problems, etc.) with dedicated keyboard shortcuts. These shortcuts translate very nicely to other IDEs. After learning the VSCode default bindings, which are Ctrl+Shift+<char>, I set the same bindings also for Eclipse and PyCharm. Especially Ctrl+Shift+e for switching to the explorer view and Ctrl+Shift+d for switching to the debug view are among my most used shortcuts now.

Making Selections
I hate to admit it, but I did not use shortcuts to expand and shrink AST selections before. AST stands for abstract syntax tree, which means that the IDE will take the current language’s syntax into account for modifying the selection. Finally, I picked up Ctrl+Shift+left/right to shrink and expand selections. Not all IDEs handle this in the same way, which can be a bit annoying, but it works well for the most frequent tasks, such as expanding the selection to enclose the current string, method, class, or HTML tag.

Folding
I have started to use folding much more. For years, I have rarely used this feature that all IDEs support to a great extent. Now, I do it frequently. Folding is one of these things that are just not feasible with the mouse. Of course, if you need to fold code, chances are that you need to structure your code better. Many organizations even apply automatic code linters that will complain when methods or classes are too long. However, I have never seen someone recommend splitting up blog posts into multiple files. The same goes for other non-code file types, such as JSON. All we have there is folding.

I am not saying these are the things you should start to learn now, far from it. These are the things I personally integrated deep into my workflows after doing this challenge, without choosing them deliberately, but naturally. Who knows what you will pick up.

Of course, some of the shortcuts I learned still seem a bit, let’s say nonessential, but a little useless knowledge never killed nobody.

More Unexpected Benefits

In addition to finally breaking out of old habits and experiencing a real evolution of my IDE usage, there were some other, less significant, but still delightful second-order effects.

As a shortcut enthusiast, I often had the problem that I needed to decide which binding to use for a particular operation and application pair. KeyCombiner’s public shortcut search helps to find out which binding is the convention for a particular operation, but it can still be tricky. For example, take the frequently used Step Over operation used for debugging. KeyCombiner shows that VSCode, Eclipse, and JetBrains IDEs all use a different default binding(F6,F8,F10). Learning every single VSCode shortcut has freed me from this mental load of deciding what the best binding for a particular IDE operation is. I simply use VSCode’s bindings everywhere. There are good arguments for why VSCode is a good reference. With the rise of GitHub CodeSpaces and its thriving extensions marketplace, I think it is likely that it will emerge as the industry standard of IDEs within a few years. That’s the topic for a future post, though.

Another effect is that I rarely use the mouse anymore when working in VSCode. This is not ideological for me. I hold no grudges against mouse usage. It just so happens that the need to touch it rarely comes up anymore. I guess most people that can do this use Vim or some Vim extension for their IDE. I can say confidently that it also works to learn all the default shortcuts. However, if you aim to eliminate the mouse completely while using VSCode, you should probably still go for one of the popular Vim emulators.

And finally, maybe most importantly, VSCode feels like home now. As someone who also uses other IDEs daily, it’s hard to develop a feeling towards a particular one that this is your professional tool: The place where the magic happens. Now that I have a complete picture of VSCode’s feature set, I feel that I have truly made it my own.

Conclusions

Of course, you don’t have to learn all shortcuts of your IDE. I never thought I would either. You can pick up a new shortcut here or there. Read blog posts where developers show off their selection of favorite shortcuts or exchange favorites with your co-workers. That’s a perfectly fine approach, and it is how a large majority of developers tackle this topic. It is even a core idea of my own project KeyCombiner to build collections of selected keyboard shortcuts that can be learned, shared, and organized.

But, you can also invest a few hours spread over a couple of weeks, stop making compromises, and learn all the shortcuts. There is no way of knowing beforehand how this will influence your habits, how it will amend your existing workflows, and which entirely new possibilities will open up for you.