Nowadays I rarely hear anyone speak about the importance of good memory (not RAM, but the stuff we have in our heads) for programmers. It think a good memory is one of the most underrated quality for a programmer. Developers often extol the virtues of understanding concepts vs. memorizing information. While they are correct about the importance of understanding concepts, memorizing and understanding are not either-or habits. Both are important. Understanding concepts is paramount, but remembering details after understanding the concepts is extremely important if you want to shine as a developer. With the ready reference of the Internet at our fingertips, it's easy to think that we can get by with only understanding concepts without remembering much. But the truth of the matter is that we could be orders of magnitude more productive if we remember certain important details as well. It's very similar to what a cache does for a microprocessor. All that the processor needs is in RAM, but operations can be considerable sped up if stuff can be fetched from the cache.
I have been lucky to work with a few extremely productive developers; here's what I noticed. Along with talent, hard work, and intelligence, they all had great memories. They remembered far more facts than most others. So even though memory is not the only factor which influences how good or productive we are, it is without doubt a very important factor, and certainly not something to be scoffed at.
But there's way too much to remember, you might be thinking to yourself. That's true, and it's why understanding what to remember is as important as learning how to remember. Here are three things you should remember if you want to improve your productivity substantially.
Cultivate muscle memory for your tools
A few years back I worked on a project where the lead programmer conducted an iteration planning meeting every Monday morning (it was an Agile shop, as you might have guessed). One of highlights of these meetings was watching him code with his computer hooked to the projector as he suggested a refactoring to a team member. I was awed at how he moved about the IDE and version control system as if he were navigating the back of his palm. He knew all the shortcuts in Eclipse and was a master at using Mercurial. Just these two things made him significantly more productive than the rest of the team because he was able to use all the power user features of the IDE and had to spend very little time pushing, pulling, and merging code in the Git repository.
If you are a developer who wants to improve his productivity, then you should start with getting to know your tools and becoming a power user. It's the simplest thing to start with and you will see the benefits right away.
Remember the most frequently used API's
With modern IDE's and code completion we often think that the days of remembering API's are long gone - but that's not true. Let me explain with a few examples. The String class in Java has a few really useful methods like: substring, valueOf, format, etc. I have probably used the substring method more than any other method in my code. Yet I could never, for the life of me, remember the semantics of its second argument. I was always confused if the following code returned just "c" or "cd".
String c = "abcdef".substring(2,3);
So every time I used substring, I hit F2 and looked up the semantics instead of directly typing what needed to be done. It does not sound like a huge hit but it is. Something which could have taken 1 second now took 15 seconds and distracted me from my chain of thought. Now if you add to this the additional time it takes not just to use substring, but also to work with other frequently used utility classes like Collections and Arrays, the Date class, various collection classes, the overhead becomes fairly high. Once I realized how much these cache misses were costing me in productivity, I made it a point to understand and memorize the most frequently used classes and methods.
This simple exercise helped me write code much faster than I could write earlier. Try it, and you will be very pleasantly surprised at the productivity gains for what is a very modest time investment.
Keep the code you are working on, in memory
This reprint of an article by a Polish developer Stiff quotes Peter Norvig's advice to programmers for improving their productivity. This comment on this HN thread credits Guido Van Rossum for suggesting the same thing.
The ability to fit the whole problem into their heads at one time
Paul Graham articulates the same thing very well:
A good programmer working intensively on his own code can hold it in his mind the way a mathematician holds a problem he's working on. Mathematicians don't answer questions by working them out on paper the way schoolchildren are taught to. They do more in their heads: they try to understand a problem space well enough that they can walk around it the way you can walk around the memory of the house you grew up in. At its best programming is the same. You hold the whole program in your head, and you can manipulate it at will.
But holding an entire program in your head is easier said than done. Here are some suggestions that Paul Graham outlines in his article (read the article for more details):
- Avoid distractions
- Work in long stretches
- Use succinct languages
- Keep rewriting your program
- Write rereadable code
- Work in small groups
- Don't have multiple people editing the same piece of code
- Start small
Although they may not be aware, many good developers are adept at keeping the entire code in memory. It could just be one of those things which separate great developers from the good ones.
facebook
twitter
linkedin
blog