On Effective Use of Tools

When I was learning guitar some years ago, I went through a learning path many people go through (bear in mind that this was in the early 90s, before the wealth of materials on the Internet that we take for granted today!)

I started with a nylon-strung classical guitar in the family, learning a few chords and not much more. I started listening to classic blues / rock guitarists such as Eric Clapton, Jimmyy Page, Jimmy Hendrix etc. Eventually, I got my first electric guitar and learned all the songs from books I found, or just by listening to the tapes and learning by ear.

I started to solo using the so-called Blues (i.e. pentatonic minor) scale, and figured out the "5 shapes" through blind effort, and trial & error. After a few years - whilst I was at university - I started to learn a little theory (harmony, scales, modes, progressions) and simultaneously started listening to and learning songs by instrumental rock legends like Joe Satriani and Steve Vai.

When I came back from university and started sharing this with friends back home (who also played guitar), there was an instinctive "recoil" when I mentioned scales and modes. It was almost as if by learning some theory, people felt that it by definition meant I wouldn't be able to play "tastfully" or "soulfully". I was told repeatedly "Yeah, it's great learning scales but it's not about how fast you play but what you play".

This was completely true, but to me it was never an issue. Scales and modes and techniques were simply tools of the trade that I learned rote as exercises, just like learning riffs or chord progressions. They were never going to define how I played guitar - it was more important to know how to play with others, to learn about musical spacing, dynamics etc. - but nonetheless knowing those techniques and lessons were fun, useful and helped me become a better guitarist because I was able to understand contextually what was happening in songs that I already knew, and also more easily execute specific musical ideas because I'd learned the techniques to do it.

I thought of it in terms of building blocks. There were two sides to my playing guitar:

• Mechanical exercises: Scales, chord progressions, modes, music theory, different techniques like arpeggios, string skipping, hybrid picking or tapping
• Real-world application: Jamming with others, harmony, writing music, soloing etc. - things that would put the techniques I had learned to use in a proper context.

Programming Keys

Why am I talking about music and guitar? Because it's a useful (although not entirely accurate) parallel to a recent tweet which caught many people's eye :

The point here was that an "experienced" developer should be using keyboard shortcuts. Lots of the replies generally highlighted the importance of other skills that make up a developer, and how knowing keyboard shortcuts is but a tiny part of efficiency and effectiveness of a software developer. This is 100% correct. You can know every shortcut for every IDE out there and still write terrible code, or deliver the wrong solution for the customer.

However, what I did find interesting was that whilst many of the comments rightly pointed this out, I sensed that many people phrased it as a zero-sum-game, whereby someone who knows keyboard shortcuts must, by implication, not have an awareness of the other key elements of a software developer. This struck me as similar to that feeling I had many years ago, where fellow guitarists told me "if you learn theory, you won't be able to play with feeling".

Learning Shortcuts

There are many activities we spend our time on as developers - communicating with stakeholders, researching, working with different technologies, designing software etc., and, of course, writing code. Now this last activity is clearly not the only thing we do, but for many of us, it's an important part of our daily routine. It's also one that I feel we should really be as effective as we can be - and that's where keyboard shortcuts can quickly have a measurable impact.

Each one in isolation will not save you much time - just a few seconds - but if you're using them dozens, or hundreds, or even thousands of time a day, the savings quickly add up. In fact, I feel so strongly about this that I put together a video series on YouTube that show many of these tricks here. Here's the first video:

These are not difficult to learn; it's basic muscle memory that can be picked up through a simple habit such as

"Every day I'll spend 5 minutes first thing every morning coding without using the mouse".

I guarantee if you spend just 5 minutes a day, within a week you'll be using several shortcuts and saving time. This is especially true because a lot of what we do when coding is repetitive actions, so much so that you probably don't even realise it. Here are some examples of common actions that you do every day, probably dozens or even hundreds of times a day.

• Navigating within a file to look at the implementation of different methods or functions
• Looking at the definition of a different type to understand what fields are on it
• Finding all references of a given type to understand where it's used

Learning keyboard shortcuts for any one of these will have several benefits:

• You'll save time
• You'll be more likely to navigate around your codebase to look at other parts relating to what you're doing because it's less of a hassle - which can help you write better code
• It'll reduce the strain on your wrists

All of these are positives - you won't suddenly lose your others skills as a developer by learning this!

Savings can add up

Let's take the example of a simple navigation action, like moving to another file.

• Mouse approach: Move hand to mouse, move mouse pointer to solution explorer / file explorer, visually locate the file with your eye, expand the file tree as needed, double click the file, move hand to keyboard.
• Keyboard approach: Press CTRL + P, type first few characters of the file, press enter.

Let's assume the time saved is 3 seconds for the keyboard approach. Let's also assume over the course of the day you perform this action 100 times (a conservative estimate).

  2 seconds
x 100 times / day
= 300 seconds / day
= 5 minutes / day
= 25 minutes / week

That 25 minutes a week could be spent on any number of things, whether that's working on deliverables, learning a new skill, chatting to an old customer to see how their business is or jumping on a call with a customer to ask a question on something you're unclear about.

Now, scale that across a team of 4 developers for a whole month:

  25 minutes / week
x 4 developers
x 4 weeks
= 400 minutes / month
= ~7 hours a month

That's around one developer day. In other words, each shortcut your team learns will save the team one day every month. None of this means forgetting the importance of communicating; of designing systems effectively; of being honest with your colleagues and customers; of coming up with an effective and suitable architecture. It's simply about being as effective as you can be with a tool that (like it or not) is a core part of our profession: the IDE in which you write code.

Summary

Keyboard shortcuts won't save you. There's more to writing effective systems than quickly bashing out random code using keyboard shortcuts.

At the same time, writing code is a core part of many of our daily work and it's incumbent upon us to be as effective and efficient as we can be in that. It's not a zero-sum-game, and you can learn many shortcuts through simply rote practice and habit. How you use them is up to you!