Back in April, I finally got around to read ‘Pragmatic Thinking and Learning: Refactor Your Wetware‘ after heard about it from various co-workers. I won’t go into the details of the book itself as this is not a book review. Needless to say I highly recommend it to everyone, even to non-technical people.
One interesting topic (out of many in the book) Andy Hunt touches upon is what he calls L-mode and R-mode (L as in linear and R as in rich) of brain processing. Other similar and familiar, but not same, terms most people heard about include Left-Right brains, and Conscious-Subconscious.
L-mode processing deals with day-to-day events. For example these abilities (from the book): Verbal, Analytic, Symbolic, Abstract, Temporal, Rational, Digital, and Logical.
Whereas R-mode has these attributes (again from the book): Non-verbal, Synthetic, Concrete, Analogic, Non-Rational, Spatial, Intuitive, and Holistic.
While not exact match, one can think of L-mode is same as conscious thought/action and R-mode as sub-conscious thoughts/reflex action.
The problem is that L-mode is ‘louder’ than R-mode during everyday activities. When your brain is engaged in L-mode/Conscious to deal with sensory inputs and provides answers to them, it suppresses R-mode/Sub-Conscious from coming forth. One technique Andy Hunt suggests to ‘release’ R-mode/Sub-Conscious is to engage brain in an activity that L-mode doesn’t want to deal with and thus allows R-mode processing.
I noticed a few years ago that when I was problem solving, I tend to grab an object on my desk and ‘play’ with it while I ponder the problem. For example, spinning a pen (though not to the crazy level some people can, just google youtube), or randomly twisting a Rubik cube. Some people may assume that I was not concentrating on the task at hand. After reading the book, I realized what I was doing is giving a task to my brain to shut down L-mode so I can engage the R-mode.
L-mode, R-mode, and Programming
At the most fundamental level, majority of programming involves expressing logical statements in textual form . Basically the programmers type each character using the keyboard until a statement is completed, which group into a method, then a class, and eventually a system. But there are much more than that. In additional to a keyboard, we also have a mouse to navigate with. We have a huge collection of menu items, windows, icons, etc. to distract us.
However, programming is not just mechanical tasks of text entry. It involves pattern recognition for code smell, design patterns, search for solutions in memory gathered from experience or learning, verbalizing thoughts to your coding partner if you are pair-programming, and plenty more!
One may think the all the tasks mentioned above are L-mode activity, I would argue that detecting code smell, knowing which refactoring technique to use, which design patterns to apply, are inherently R-mode activity. That is, developers rely more on their sub-conscious during programming than they realize. But this is only possible if the brain is engaged in activity that allows R-mode to come forth. Otherwise, we would be programming in L-mode which is fine but probably not going to produce creative solutions.
Keyboard and Mouse
Once upon a time, I used to follow every announcement of new mouse in the belief of improving my Human-Machine-Interface with the computer. Better shape, higher tracking resolution, more buttons are all features that manufacturers claimed make better ‘computing experience’. Same goes with keyboard. More shortcut buttons, different ergonomic shape, wireless, etc.
But if you look at this picture of my pairing station in the office today, you will notice that I have a very plain Dell keyboard and even plainer mouse. Wouldn’t it make more sense if I have a super tricked out mouse with many buttons that will allow me to navigate the IDE in lightning speed? In fact, I used to have that during the mid-2000’s. What I found though is that there was hardly any improvement in my programming ability or speed.
It was not until I joined ThoughtWorks back in 2007 that my approach to programming changed, dramatically. In my very first project as a ThoughtWorker, I joined a team that used pretty much the same toolset that I used in my previous job (Visual Studio 2005 + ReSharper) but yet was much more productive, both in terms of amount of coding (producing as well as refactoring) and design changes. There were many other differences, of course, despite the same toolset, but the main shock to my system was the usage ratio of keyboard and mouse.
Whereas I used to type some code, then reached for the mouse for some menu item to either formatting or refactoring, that ThoughtWork team used the keyboard for as much as possible for everything and only reached for the mouse for action that was just not possible with keyboard.
At first the improvement in speed was mainly from reducing the time my hands go between the keyboard and the mouse, and the navigation of menus. But now in 2010 having internalized that skill and after reading the Pragmatic Thinking and Learning book, I realized what was happening was that by relieving our brain from L-mode activity (i.e. moving our hand to the mouse, moved the pointer, click button and navigate menus), we engaged our brain in R-mode processing and thus able to concentrate on solving the our collective experiences, initiation, etc. without the distraction of the mouse.
Just like I judge a programmer’s skill level on his/her ability to touch type, the amount of keyboard usage during programming is also extremely important to me . But this has nothing to do with being 1337, or showing off how one memorized every keyboard shortcuts. This is about utilizing as much as our brain capacity and capability to produce the best code we can. After all this is why we call ourselves professional, right?
 This doesn’t stop some software vendor (you know who I’m talking about) from pushing ‘visual’ programming for every tools to every level of programmers.
 This is not to say that programmers who are not familiar with keyboard shortcuts or the value of them are not as good a programmers. Just like every skills, there are levels of competencies re Dreyfus Model.
You were doing well right up to this point:
“…Just like I judge a programmer’s skill level on
his/her ability to touch type, the amount of keyboard
usage during programming is also extremely important
but now I can’t take you seriously at all.