becoming a keyboard ninja

Hi, i’m Gregor, and I want to help you become better at coding. Here are some tips to improve your keyboard utilization. If you are already very good at it, this might not be for you.

keep your eyes on the street

It is our most important tool because of it’s relatively high throughput. This throughput not only determines our speed, it also affects the quality of our output. Let me explain: As coders we’re switching between different views and modes. We’re mostly looking at the code from a bird’s eye perspective, just reading and thinking. As soon as we have decided on the changes we want to make, our focus tightens. We’re now more concerned which button to click next, which menu to open. Using the mouse is terribly slow. It breaks our flow of thought. We’re not watching the street, we’re looking at the stick shift. Fluent keyboard utilization can help us keep our eyes on the street. It frees our minds and helps us make fewer mistakes. We can not only drive faster, but also safer.

getting better is easy!

Just lower your expectations. There is no need to get to 0% mouse usage right away. Start small, but start now! The following tips should help you get started.

tip #1: buy a keyboard you’ll want to use

Do yourself a favour and buy a good keyboard of your choice. After all, you’re a programmer and this is your most important tool. It will be much easier to get better, once you own a keyboard you enjoy working with. One you’ll want to use. Maybe a mechanical one, maybe a slim one, whatever suits you.

tip #2: use a powerful editor

It should have support for code navigation, refactoring and other coding related stuff. Could be an IDE, could be a lightweight editor that has a healthy plugin ecosystem.

tip #3: plugins may help

Search for plugins that assist you in learning keystrokes. Like the Key Promoter X for IntelliJ. There is also Mousefeed for Eclipse, and Keypromoter for Netbeans, which do a similar thing. They will assist you by showing the keystroke you could have pressed, whenever you used the mouse. Also they will count and show you how often you used the mouse for that command.

tip #4: start small

Don’t try and learn everything at once. You gotta start small. Choose ~4 keystrokes or combos you want to learn first, and focus only on them while working on the code you are usually working on. You will soon start doing them unconsciously. This is when you are ready for the next ones.

tip #5: prepare a cheat sheet

Prepare yourself a cheat sheet, so you can quickly look up the shortcuts you are working on. Maybe you’ll find a nice print out online, or even create one yourself. There is the code cops shortcut search for example.

tip #6: be gone, mouse!

If it does not work out, and you keep grabbing the mouse out of habit, move it to the other side of your keyboard. So when you try and grab it, it won’t be there. This is also a good tip if you’re advanced and you feel like ditching the mouse anyhow.

tip #7: pair with others

You can’t practice tricks you didn’t know existed. Pair- and mob- programming will help you find inspiration. I learned some of the most valuable shortcuts from pairing with others.

tip #8: RTFM

Also, it might be worth it to study your editors documentation. Some of the actions I adopted are ones i found there. For example: The ‘Search and Replace Duplicates’ refactoring.

tip #9: extend your keymap

Some of the actions you frequently use might not even have a keystroke assigned by default. I for example like to split my tabs when doing TDD. So I can see my tests on the left, and production code on the right. The ‘Move Tab to the Right’ action however did not have a keystroke assigned by default. I had to do this myself. Expect your editors keymap to be imperfect. Think outside the box, and adapt the tool according to your need.

I hope these tips will help you utilize your keyboard more. So you can keep your eyes on the street, and increase both your throughput and quality of output.

to the comments

maybe a different view on object orientation

information/state and behaviour

I like to think of software as a universe of state and behaviour. State, whether mutable or immutable, is represented in the form of parameters, return values, vars, fields, files and so on and so forth. Those have many different traits to them. For example: vars, fields and files are location based, while parameters and return values are flow based. But they are all state.

Behaviour is represented in the form of functions that operate on that state. There is no behaviour without state. Try to imagine a program that had no state. No Vars. No Input. No Output. Not even lambdas… they generate state. We can’t even print a damn thing without passing a string state.

cohesion

Some state is related. If we’d increase the cohesion and move related state closer to each other and behaviour towards the state it operates on, groups are emerging. Groups of related parts. Groups of state and behaviour.

encapsulation

We can wrap them in capsules, which come in many different forms. Functions, classes, packages, modules, processes and even servers are all kinds of capsules. For each capsule we define a minimum viable interface. The encapsulation serves the purpose of defining usable units that hide their internals which are irrelevant to the outside world.

objects

We are defining Objects - behavioural capsules that interact with each other at runtime. So a function is a form of an object. An instance is a form of an object. A module is a form of an object. And even a microservice is a form of an object.

coupling

Each object is in some way coupled to the neighbours it interacts with. Coupling prevents independent changeability. Objects which are strongly coupled to one another cannot be changed independently of each other. The size of an objects public interface correlates with the strength of this coupling. The more we close the capsule, the more details we hide, the smaller the interface will be, thus the weaker the coupling will turn out.

feature envy

Sometimes, an object accidentally operates on the state of another object. We call that a ‘Feature Envy’, as the object envies the other object. This increases the coupling between the two. We can resolve this situation by moving the behaviour to the object that holds the state.

dependency

When an object knows about another, we call that a dependency. But don’t confuse ‘knows’ with ‘controls’, those are different things.

dependency inversion

An object can control another object without even knowing it. This is called dependency inversion. Think about a AAA battery. It provides power, but it has no idea who it provides power to. The form of the battery, AAA, is its interface. The flashlight knows the battery, it implements its interface. And even though the battery knows nothing about the flashlight, the former controls the latter.

to the comments