We developers are often paid to get productive quickly on a large, unfamiliar code base. There are many ways of doing this. One way of NOT doing this is to start from
public static void main1 and work your way through each function or class or module till you understand what you want - that way lies failure and madness.
I can think of 3 ways of getting to grips with new code:
- Use external sources: Talk to others who understand the code base better; Read the documentation; Watch a tutorial screencast; ...
- Use the debugger: Step through the code and see what it does.
- Use the Source, Luke: Read through the code.
Of these, I've found the last the hardest. It is this skill - reading through code - that I want to talk about today.
When I say "read through the code", I use
read in a sense that is very different from reading a novel or even a text book. It's more of jumping around the code base, reading a bit here, taking in a whole class at a glance, poring over a single method for over an hour, finding the usages of said method, ... If you are a programmer, you know exactly what I'm talking about. While doing this, you are attempting to build a mental picture of what is going on in the code. This is where the
Magic Number comes in.
The idea is that
human beings2 can only handle a limited number of pieces of information in their
working memory. You can think of working memory as the set of registers on your computer's CPU - all of your thinking happens on pieces of information that is in the working memory, and there is a limited amount of it available. Even though you may not agree with the range 5 to 9 specified in the article, for the purpose of this post, it is enough if you accept that there is a limit.
Here's how I think the code reading process works: You start off with understanding a small piece of code - piece A, let's say. Then piece B. And D. And then how B and D are related via C. And Z. Five of the slots in your working memory are now filled. Suddenly you realise that all these pieces are part of the English alphabet - and boom! five used slots shrinks to one used slot! The larger chunk - English Alphabet - occupies just one slot worth of space. You are essentially building up more powerful abstractions with which you are able to explain the purpose of ever larger swathes of code. So your ability to comprehend code depends on how many free slots you have in your working memory.
"Ok, even if all that is true, where do keyboard shortcuts come in?", you ask. Well, which keyboard shortcut to use is a piece of information too. If you are not very familiar with your IDE, then thinking about which keyboard shortcut to use will take up one or two registers in your working memory. Your brain has less free registers and hence is a slower computer. On the other hand, if you are really familiar with your IDE, your fingers automatically press the right key-chord when your brain thinks "I wonder what that method does?" and take you to the definition of the function. This process doesn't use the 5-9 registers at all, but is
muscle memory a la riding the bicycle or swimming. More registers to understand the code implies faster understanding.
There is another factor involved as well:
frustration. When you are struggling with the tool, the resulting frustration will make you want to take more breaks from your task of understanding the code. When the tool is almost an extension of you, the feeling of being in control will allow you to work longer periods. This is one way the human brain is different from computers - the latter doesn't get tired.
I don't have proof to offer for all the claims I'm making; I do have anecdotal evidence though.
Exhibit 1: While reading Java code, I'm much faster while using IntelliJ IDEA than while using Eclipse. I believe that Eclipse and IntelliJ IDEA are pretty much equal feature-wise. I attribute my higher productivity on IntelliJ IDEA entirely to my much greater familiarity with its shortcuts.
Exhibit 2: I find it easy to switch between reading C# and Java. I think a lot of the credit should go to JetBRAINS' - their masterstroke of reusing the IntelliJ IDEA's shortcuts in ReSharper means minimal muscle memory retraining when switching between these languages.
All of the above are arguments for learning to use your IDE really well - they could apply equally to using the mouse as well. Here's why I prefer the keyboard: accuracy and speed. With the mouse, I'm a bit of klutz. I click the wrong piece of code. I select the wrong region. I'm really slow at reading the available menu options and very likely to pick the wrong one even after all the reading. And my hands ache when I use the mouse for a while. With the keyboard, especially my trusty old
Kinesis Classic, I'm fast and accurate. This leads to less mistakes, less frustration and more time spent reading and processing code. Ergo, Happy Developer.
And that's another reason to learn touch typing!
Are you a predominantly mouse person or a keyboard person? Either way, what are your reasons for preferring one over the other?
1 Or its moral equivalent in your favourite language.
2 That typically includes us programmmers as well.
