Efficiency

One of my favorite books was always Cheaper by the Dozen. (It inspired a hit 1950 movie, but the book had no relation to the recent Steve Martin comedy.) The book is about Frank and Lillian Gilbreth and their 12 children. The Gilbreth parents were efficiency experts who examined the smallest movements of even their own children, looking for ways to reduce the number of motions. This was decades before the recognition of repetitive motion injuries caused by computer use and other fine muscle movements.

One story I found particularly interesting was about how Frank had courted Lillian. Frank apparently encountered bricklayers at the home of Lillian's parents, and suggested how they might do their work more efficiently. The skeptical workmen watched as Frank quickly laid out a row of bricks and mortar in expert fashion.


Daughter Ernestine, who wrote the book, retells her father's tale with the moral lesson that although Frank had become a professional consultant, he was still in touch with the common laborer and his travails. (I say "his" travails because this was in 1904, before female bricklayers became commonplace.)

But even when I read the book as a child, this explanation rang hollow. I do believe Frank, who had indeed started out laying bricks before becoming a management engineer, wanted to prove that his motion studies really did pay off. Imagine his frustration watching someone lay bricks inefficiently. I don't think he was bragging that he was a better bricklayer, but that he knew of a science that could make better bricklayers of us all.

❀

So, it is with chagrin that I watch the students in all my classes struggle with their keyboards, mice, and trackpads. Watching someone carefully select a line of text, from first letter to last letter, while tightly clutching the mouse or slipping around on the trackpad is like watching a bricklayer spread the mortar with a rock instead of a trowel. It is not only inefficient, but error-prone; moreover, it is eventually painful to the programmer. As someone who used to experience great pain due to improper computer use, I want to spare my students (and all my friends) a similar fate.

I'm not going to say that one should not use the mouse at all while coding. The triple-click maneuver is pretty cool. (Try it; you'll see that it selects a complete line of code, or even a complete line of prose in your word processor of choice.) But when push comes to shove, the most efficient programmers seldom take their hands off the keyboard. With a text file, almost anything you can do with the mouse, you can do better with the keyboard. There are a great many keyboard shortcuts you can use to navigate and select code.

Even non-progammers should be aware of Ctrl-S for Save and Ctrl-X/C/V for Cut/Copy/Paste. Ctrl-A for Select All is pretty universal. (Mac users can use the ⌘ key equivalents.)

Each code editor has its own particular keystrokes, but try the right, left, up, and down arrow keys in various combinations with Ctrl, Shift, and Alt/Option. Even within this blog, I can use Ctrl-Left Arrow for beginning of line, Ctrl-Right Arrow for end of line, Shift-Up Arrow for select a line going up, Alt-Left Arrow to select a word going left, and so on.

When selecting code, it's best to always select a full line. I use Ctrl-Left Arrow to put the caret in the left gutter, then Shift-Down Arrow to select full lines one at a time, with the selection including the trailing carriage return. You may prefer a different method, but I'm not aware of any others that use fewer keystrokes. Selecting full lines like this is the computer programming equivalent of using a plumb line while laying bricks. It makes sure everything lines up when you are done.

If you think about these things and apply them, you'll become a better programmer, and more importantly, save yourself years of physical therapy while recovering from repetitive motion injuries.