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.