I could write a long, rambling blog post here with anecdotes and examples, but instead, I’ll just get straight to the point. If you want to see significant productivity gains, and avoid having repetitive strain injury destroying your programming career when you head into middle age, stop using the mouse. Mousing may be easy and intuitive, but it is slow, cumbersome, and it trashes your wrists.

I speak from experience there. When I first started experiencing wrist pain, I found that of all the things I tried — ergonomic keyboards, learning Colemak, what have you — by far the most effective step that I took was to cut down on my mouse usage and adopt a more keyboard-centric workflow. Today, about thirteen years after the first onset of discomfort, I’m almost entirely pain-free.

But even if you aren’t suffering wrist pain, mousing is still painfully inefficient and cumbersome for many tasks. Watching people thrashing around with the mouse, selecting text then faffing about with toolbars and popup menus is painful when you know that they could achieve pretty much the same thing far more quickly with judicious use of Ctrl-C and Ctrl-V.

Here are things that you can do to make a start:

• Start by learning keyboard shortcuts in your IDE, your word processor, and your web browser. Find (or create) cheat sheets, print them out and refer to them regularly.
  
• Look for features of your software that let you accomplish things all the more quickly. For example, most modern text editors will let you quickly search for a file by name by typing a keystroke such as Ctrl-P, or a command by typing Ctrl-Shift-P.
  
• Learn to use Spotlight on the Mac, or the search facility in the Windows start menu (press the Win key, then just type the name of the program or document you want to open).
• Install Vimium on Chrome or Firefox. With this, you can press “f” to bring up shortcuts on each link or input box on a web page that you can type to jump to them.
  
• Learn to use the command line. If you’re on Windows, git bash is your friend.

Once you get into the swing of things, you can then start considering other more advanced techniques, such as customising shortcuts in your most commonly used programs, or even learning to use a keyboard-centric editor such as emacs or vim.

Learning to go mouseless takes time and effort, and the chances are that you’re not going to be able to go cold turkey right from the start. But like learning a new language, it’s well worth the effort of learning a new shortcut every day. Your wrists will thank you for it, your boss will thank you for it, and your stakeholders will thank you for it.

Posted at 10:00 on 3 September 2018.
Tagged: productivity, mouseless, health, RSI, typing

I’ve recently been getting into various discussions about science and faith with friends at church and on Facebook, and one of the things I’ve been doing is explaining to them exactly how the scientific method works. This got me thinking—there are some aspects of the scientific method that we don’t always apply to software development, that maybe we should.

People with no scientific training often don’t appreciate just how rigorous and exacting the scientific method is. It has a lot of very strict protocols to ensure that research meets stringent standards of quality control. One of these protocols is keeping detailed laboratory notes. In other words, you document everything you do. In meticulous detail. As you do it—not after the fact.

There are several benefits to keeping a detailed record of everything you do in this way. It helps you to keep focused on the task at hand. It gives you something more constructive to do during slow edit/compile/test loops than reading Reddit. It helps you to pick up where you left off after your lunch break or when you get into work first thing in the morning. It jogs your memory for your daily stand-up meeting. It provides you with a searchable audit trail that you can consult to figure out where to find things, why things were done in a certain way, or what exactly happened when you tried X. It provides source material for when you need to write up the documentation proper. And it covers your back. For example, if you’re working from home, it provides evidence—should you need it—that you were actually working and not slacking off.

Of course, if you’re a fan of the Agile Manifesto, you are probably cringing at this idea. Aren’t we supposed to favour working software over comprehensive documentation? In fact, the whole idea no doubt sounds like anathema to many software developers, who hate writing documentation with a passion.

But if we were research scientists rather than software developers, we would be doing this as a matter of course, and we wouldn’t think twice about it. Besides, as Martin Fowler says, if it hurts, do it more often.

Posted at 08:00 on 13 December 2016.
Tagged: productivity, scientific method, lab notes