Get Your Efficiency Right

I just read:

“That’s the reason why senior developers are more efficient than junior developers: they type faster and know more keyboard shortcuts, making them more productive.”

That was meant in a sarcastic way by the author of the book. Nevertheless, it mirrors what many seem to be still thinking. (A variation of this is “Real programmers use the […] text editor for coding!”)

Over the years I’ve been reading such claims so often and have never ever seen any really productive programmer whose productivity could be attributed to knowing more shortcuts and faster typing. That’s a claim, I guess, perpetuated by tool vendors. “Look, our tool has so many more shortcuts. This will make you more productive.” (And by programmers whose life supporting system is the IDE.)

Well, maybe they are all right? Once I’ve learned all those shortcuts by heart. But how long is that going to take? And it’s only true for tools you really use regularly.

I’m not saying shortcuts don’t make tool usage easier/faster. Sure they do. But knowing them does not distinguish the performance of a pro from that of a newbie.

Let me tell you: I don’t know many shortcuts in my favorite IDE. It’s a handful, not more. And beyond that… I’m using the mouse to point and click. Am I typing fast? Yeah, somewhat, although I’m just using maybe 5 or 6 fingers only. But that does not even help me much. Whenever I’m starting to write it’s just a short burst. Maybe 10 or 20 characters of code. Sometimes more when I’m writing a blog article like this. It’s a burst of keystrokes then a pause of several seconds, then another burst, pause, burst, longer pause… and so on.

What would I gain if I was able to type twice as fast during those short burst? No much. What would I lose if I typed only half as fast? Not much. Much more time passes not typing.

So let me tell you a secret: Programmer productivity is only slightly depending on typing speed and knowledge of keyboard shortcuts. Rather programmer productivity mainly hinges on thinking speed!

Here’s what I see again and again in the Clean Code trainings I’m doing: When it’s time for coding I’m 2 to 4 times faster than my students. Me, the guy not knowing any keyboard shortcuts. How come?

At that point we’ve gone through a problem analysis phase at length. Also we’ve done an extensive design session. The problem at hand is solved. The solution just has to be translated into code. That’s very, very straightforward; I can assure you of that. But still… it takes the students much longer than me to accomplish the same coding task.

The reason is simple: Even though what’s left is only coding, they can’t do it. They don’t know enough. They have to look up API calls, they have to research how to set up a project, they run into a sudden disconnect from some company infrastructure, they realize they haven’t understood what seemed perfectly clear 10 minutes ago. There are so many impediments, they need to do so much head scratching, their hands are hardly on their keyboards at all. Being able to type faster or know a couple of more shortcuts is of no use.

What is of use, though, is to have a clear mental model of the task at hand. Or to have a stable infrastructure. Or to really know your framework. That’s what makes developers productive.

Since I have full control over my machine, am independent of corporate networks/infrastructure, am understanding the solution 100%, I can be fully productive. That’s what makes me in this “coding only” situation about 2 to 4 times faster.

But what about the 10x productivity differences between developers? They should not be looked for in typing. The differences in typing/coding usually are not that large. But once thinking enters the picture differences skyrocket.

What I observe is huge differences in performance during analysis and design. They become very explicit in my trainings since those phases of software development are worked through systematically and openly. How fast people can immerse themselves in a problem, how fast they can think through implications and ramifications, how quickly they can model a solution and devise a structure… well, that capability is distributed quite differently among developers.

Becoming more efficient at maybe 10% or 15% of all the work – coding – is a pretty vain optimization. As if there were not more fundamental problems to tackle first.

Be a slow typer, click around with the mouse as much as you like. As long as you’re crystal clear what you’re doing, and have a comprehensive mental picture of what needs to be accomplished you’ll outperform most keyboard wizards.

Get inspiration from Cliff Young, the surprise winner of ultamarathons:

He was the slowest runner – but the most persistent. While others needed to stop he just continued shuffling towards the finish line. Beating them all.

To translate the analogy: Others might be typing faster and know their keyboard shortcuts. But if those need to stop frequently in order to think again, refactor quickly typed code, check their understanding with some person etc. their bottom line productivity will be lower than yours not being a keyboard wizard, but with everything necessary right in your head (or on a piece of paper next to you).

My advice if you really want to become an efficienct and productive programmer: Yes, know thy tools. But even more train your mental faculties. Become an analysis expert, become a design buff, increase your ambiguity tolerance, improve your drawing skills, hone your natural language fluency in speaking as well as writing, start reading philosophy books, learn to listen and ask… in short, do all you can to become smarter, to be able to juggle more stuff in your head, and communicate it visually. That will increase your performance (as well as general joy of living). That’s the efficiency I’d be looking for as a employer.

Posted in English postings.

5 Comments

  1. Well, the original citation is not only sarcastic, but also misleads the reader to confuse efficiency with productivity. In fact these are two very different things. That is, efficiency is just one component of productivity and typing speed and shortcuts go in the efficiency category. You argue that shortcuts and typing is just a minor factor of productivity and you are right, but that is because they only can raise efficiency, which is a small component of productivity.

    I fully agree with you that thinking is much more important. That being said, I strongly disagree with the overall message of the post where you diminish the importance of efficiently and advise not to waste much effort trying to raise it. That is wrong because of various reasons.

    The first reason is your recent idea about reasoning “as well as” instead of “either or”. You make the same mistake by subtly putting efficiency and productivity as mutually exclusive, but they are not. In fact there is no reason not to raise mechanical efficiency.

    The second reason is pairing. It is very very tedious to pair with somebody who is efficiently controlling his own IDE, his own shell or his own file manager. You think together, you design together and you both know what to do next. And then comes the big waiting. Wait for them to locate a file, wait for them to navigate the codebase, wait for them to operate the shell. Again and again and again – it can be annoying.

    The third reason is semi-automatic manipulations. Being efficient means that if you have 20 spots with slop or inconsistencies, you can clean it up quickly. This usually requires little thinking, but leaves multiple small improvements. It comes to pay off when the changes are either too inconsistent to automate, or their number is not big enough that it pays off to automate it. I mean if it takes 10 seconds to rectify some lines of code semi-automatically and 30 seconds to write an automatic macro, then it is more reasonable to go with the 10 seconds and spare the thinking power for more valuable things.

    The fourth, perhaps minor reason is that it adds up. Get an inefficient sysadmin and add up the time wasted during a month or a year of work. Get an inefficient pair partner and add up a week.

    All these factors matter to me and it really annoys me when I pair with somebody non-novice, who does not control his primary tools efficiently. So if I were you, I would start improving my efficiency instead of finding excuses why it might not be necessary.

  2. “It is very very tedious to pair with somebody who is efficiently controlling his own IDE.” I meant “not efficiently controlling his own IDE (and other important tools)”.

  3. I do agree that typing speed per se is not the reason why some developers are more productive than others. However, if a developer can type fast and knows her editor inside-out, it means that she cares about her craft and invests in her skills and tools.

    I’ve met many developers who do hunt-and-peck typing and, guess what, they were almost all lousy developers. My theory is this: if you cannot type fast, you won’t do it, or at least not enough. You won’t write enough documentation, emails, blog posts and you won’t do the refactorings that you should do just because it causes you so much effort. Bad typists constantly look from the keyboard to the screen, move their hand from the keyboard to the mouse, back and forth. Not only is this very inefficient, it is also bad for your body.

    Being a professional software developer these days means writing a lot (not just code) and investing in your typing speed is a cheap investment and definitely worthwhile. I wouldn’t hire a developer who cannot touch-type at a reasonable speed (say 200 chars/minute) just like I wouldn’t go to a dentist with bad teeth. (You are the exception that proves the rule, of course).

  4. @Rusi: I’m sorry you got this impression from my article: “the overall message of the post where you diminish the importance of efficiently and advise not to waste much effort trying to raise it”.

    I do not argue against becoming efficient. Right to the contrary. It’s also in the title. Efficiency is important – but which capability to become efficient in? Not typing, not knowing keyboard shortcuts. Become an efficient thinking, become an efficient user of the core frameworks of your platform.

    Sure I’ve experienced sitting next to somebody typing slowly (for my taste). But still I would distinguish between somebody typing slowly but knowing her shit, and somebody typing slowly and being highly uncertain. The latter drives me crazy, not the former.

    Again: yes, hone your skills. But be sure to hone the right ones. Don’t get distracted by tangible ones; because that’s what keyboard shortcuts and typing speed are. Just tangible competencies. Rather look for importance and impact.

  5. @Ralf: I’m so relieved: my typing speed today was 330 chars/minute 😀 (But I’m not looking to be hired.)

    I would not conclude from seeing some typing speed that somebody is not interested in his job. And not just everybody likes to speak in front of other developers about experiences with a new framework. People are different. We should not derive too much from single efficiencies.

    But I agree: Overall a person can look as if she was clear what to do – or uncertain. Typing speed can be one of several aspects of that.

Comments are closed.