You’ve probably heard advice from certain quarters that a software developer doesn’t need a pointing device. Everything they need to do can be done with the keyboard, and the work is much faster that way.
The advice seems succinct until you unpack some of the underlying assumptions. Besides that, I think we should think about the effect on novice developers when highly-experienced trainers and coaches tell them to throw away their mouse. They often end up spouting off on their blogs about how anyone who ever reaches for a mouse for any reason is unprofessional.
They have been told by mentors they respect that they don’t need a mouse. All they need is a keyboard. And they’ve practiced working that way through code katas and other exercises. They can navigate their favorite text editor flawlessly using the keyboard alone.
Proportion of software development time spent in a text editor
That’s great, as far as it goes. But what proportion of time does a software developer or software engineer spend head-down in a text editor?
Some have said it’s as much as 80% of their time. I would say a coder might spend that much time in a text editor. A programmer would spend less than that. A developer would spend significantly less. The reason is that there are many other tasks involved in developing a software solution besides editing text.
So when someone tells me they’re a software developer and they spend 80% of their time in a text editor, it causes me to doubt they’re really a software developer. Maybe they’re a coder.
Proportion of lead time spent editing code
The argument in favor of discarding the mouse is that one can work faster without one. The statement is often taken in a context-free way by novices who are impressed with how fast their mentors can do things without a mouse.
What if you made a value stream map of your software development and delivery process? It would show value-add time and non-value-add time. The value-add time would include the time you spend using your text editor or IDE, as well as the other things you do that add value to the product.
If you haven’t done something like this before, pause for a moment and take a guess about what proportion of the total lead time is value-add time.
What was your guess? Most people figure they spend something like 70% or 80% of their time in value-add activity, and the rest in overhead activity of one kind or another – attending meetings, filling in time sheets, etc.
When people have measured this in real software development organizations, they have found that only about 0.5% to 2% of total lead time is spent in value-add activity.
The most effective way to reduce lead time is to shorten the non-value-add activities, rather than speeding up the value-add activities.
In the previous section, I mentioned that software development involves many other activities besides editing text. A software developer, as opposed to a coder, will not spend 80% of their time editing code. It will be more like 5%.
So, by avoiding the mouse at all costs, you might save 10% (speed improvement) of 0.5% (value-add time, maybe up to 2%) of 5% (code editing time) of software development time. Between 0.000025% and 0.001% of total lead time.
Something that has such a small impact surely can’t be considered the definition of “professional.”
Keyboard-oriented and pointer-oriented tools
Many of those who favor discarding the mouse are experts with one of three venerable text editors: EMACS (from the *nix world), VIM (from the *nix world), and the ISPF Editor (from the IBM mainframe world).
All three were first developed when graphical user interfaces and pointing devices were in an experimental stage, or didn’t exist at all, even in a lab. They are designed from the ground up to be used with the keyboard alone.
They were also developed in an era of slow network speeds and dumb terminals. So, they have a lot of features to minimize data transmission, and to perform significant work with minimal input. You can do a heck of a lot with them and never notice the absence of the mouse, and you can customize the bejeezus out of them.
Many others who give this advice are experts with a particular Integrated Development Environment (IDE) or smart editor that they have learned inside and out.
And I do mean to say they are experts with “a particular” tool – one tool. That’s the reason they can internalize all the keyboard shortcuts so well. They rarely, if ever, work with another IDE that has different key mappings or different functions.
These tools were designed with a GUI in mind. They also support “keyboard shortcuts” that can be faster than using a pointing device to locate a menu item.
As the term implies, the keyboard shortcuts are shortcuts for pointer actions. The tools are not designed around the keyboard natively. Realistically, a combination of keyboard and pointer actions tends to provide the smoothest work flow for working with source code, even if you can use just the keyboard for the majority of actions.
When a mouse isn’t a mouse
Personally, I think the advantage of emphasizing the keyboard for editing text is that you needn’t take your eyes off the screen to look for the mouse. But what if the mouse isn’t a mouse?
My Mac keyboard has an integrated trackpad. I don’t have to take my eyes off the screen to find where the mouse has gone on the physical desktop. When using EMACS, VIM, or ISPF I don’t miss it. When using an IDE or GUI-oriented smart editor, my fingers can find the trackpad without causing any interruption in my work flow.
Best of both worlds.
Different developer experiences
Some software developers work on the same application using the same tool stack configured and extended in the same way for long periods of time – sometimes years.
Others have a favorite set-up, and the technologies they specialize in allow them to use the same set-up for multiple client engagements and development projects using different languages. The “and” in that sentence is significant, by the way. Every development stack isn’t well-suited to every language or platform.
In this situation, it’s quite feasible to build muscle memory for key mappings and keyboard shortcuts for a long list of functions. It’s helpful if you can customize your desktop or laptop environment in a particular way that suits you, as well.
Other software developers routinely work on multiple systems in multiple languages using multiple tool stacks. They don’t usually customize their desktop or laptop environment because they often re-install operating systems and development tools. They may work on different projects simultaneously, moving from one platform and tool stack to another multiple times per day.
In this situation, developers may be able to remember a handful of key mappings or shortcuts for any given text editor or IDE, at least in the short term, and they may be able to recall more when they work with one particular stack for a couple of hours. But it’s hardly feasible to build deep muscle memory for key mappings in the way the proponents of mouseless programming advise.
And it’s definitely unprofessional to call them “unprofessional” for that reason.
What’s a “keyboard,” anyway?
Emphasizing the keyboard may be helpful in some situations and not so helpful in others.
But what is this “keyboard” thing?
In the early years of computing, there was no standard or common input device for computers. Originally, people programmed them with patch cables. Later, it was possible to set the bits in registers using toggle switches. Some people added octal or hexadecimal keypads to computers.
One fine day, someone somewhere wired up a typewriter to a computer. Univac began to build mainframes with integrated typewriter-style keyboards as early as 1951. IBM soon started to use a combination of a teletype device and a printer as a console. Control Data Corporation used oscilloscopes as monitors and typewriter-style keyboards on their consoles.
The world settled into a “standard” of a cathode ray tube display coupled with a typewriter-style keyboard as a terminal. Terminals from Wyse, Digital Equipment Corporation (e.g., VT100), and IBM (e.g., the 3270 family) became ubiquitous.
These keyboards were fundamentally typewriter keyboards. They weren’t specifically designed for computers, except maybe for a few special-purpose extra keys. Typewriter technology was re-purposed and adapted to computers.
Quite early on, people wrote software that could capture the signals from the keyboard and route control to a routine that performed some particular function on the computer. In the case of block mode terminals like the IBM 3270, only certain keys transmitted data to the host, but people wrote code on the host that captured those key codes and mapped them to functions, too.
Today, it’s easy to find inexpensive keyboards that look like typewriter keyboards but are actually fully programmable. A keyboard like that isn’t a re-purposed typewriter keyboard. It’s a panel of switches. Each switch can be assigned any function you might choose. The devices ship with the keys set up like a typewriter keyboard, but that isn’t set in stone.
Between programmable keyboards and software that captures key codes, we have a great deal of flexibility in how we can configure our primary input device.
What does it mean to “master” the keyboard?
If every key on a modern keyboard is programmable, and all mainstream IDEs and text editors support custom key mappings, what does it mean to “master” the keyboard? In a world in which no two keyboards are (necessarily) the same, and no two configurations of any given text editor are (necessarily) the same, can a person “master” anything beyond his or her personal set-up?
And what do they do when they have to work on a different platform, a different IDE, a different programming language, or use a different keyboard? After all, work comes wherever it comes. You have to be flexible. Are they just slightly less efficient than usual, or are they at a loss?
When I was 13, “keyboard” meant “typewriter.” I took a typing class in school (most boys didn’t take typing, but I had 24 very good reasons to sign up for the class; they were all 13, too). Mastering the keyboard meant touch-typing. Eventually I got to the point I could type 240 words per minute for three minutes with no mistakes. No, that wasn’t enough to win a typing competition; but it was sufficient to get ahead of a DEC VAX input buffer.
Today, the people I know who advocate mouseless programming can do just about anything with a code base using just the keyboard, and they never have to look away from the work. But they can’t type their own names without watching their hands. Even then, what they do isn’t really “typing.” It’s pecking.
Is that keyboard mastery? Well, yes, it is, actually. In today’s world, that’s what it means to master the keyboard. Touch-typing isn’t really in demand. FWIW I still find it a useful skill, even with my slower, older fingers. But it isn’t a necessary skill for software development.
When programmers advocate mastering the keyboard, they mean we should learn key sequences that streamline our work flow. That’s a good thing. But please take care when expressing the idea to novices under your tutelage, lest they take it out of context and to an extreme.