Thinking in Code

When writing software, I believe the most productive developers actually think in code. They imagine concepts and easily translate them into the coding language of choice. They have the languages and tools so ingrained that they don’t have to bother thinking about such mundane topics. They can focus on the problem and code a solution. For them, their coding language of choice actually lives as a language.

That some programmers produce ten times the code of others raises several interesting observations. While I haven’t seen a study confirming this factor of ten, I believe the validity of this approximation.

Some relevant questions:

  • What internal states do these highly productive developers embrace?
  • How does the code flow from an external problem description to working code on a computer?
  • How can we model these programmers to educate other programmers?
  • What tools support these developers and how do they use these tools differently from “ordinary” developers?
  • What habits do these developers perform that allow them to stand out in the crowd?

Just Notice Coding Behaviors

Let’s start this investigation by noticing how coding gurus behave.

As we observe their working habits we can see how agile they use their tools. Developers spend a huge portion of their time using a text editor. Typically vim, emacs, eclipse or similar editors translate internal thoughts into code. They often type with great ferocity and speed. Minor rearrangements appear almost as magic as code disappears into a text buffer only to emerge in a different location.

As we continue to observe more closely, see how they know and use shortcuts so that they don’t rely the mouse as often as other developers. They have mastered keyboard shortcuts and tend to keep their fingers on the keyboard.

All these behaviors with seemingly little effort!

Constrasted with Average Developers

Contrast this with many of the less productive developers. These people may be junior developers just starting or they may be developers who should not be developers at all. And certainly include your “average” developers.

These comments should not disparage the “average” developer – these developers form a solid core of productivity vital to the software industry.

I’ve observed too many developers with several years experience continuing to struggle with elementary operations of their editor. This should raise an immediate red flag. Obviously this creates a point of friction in translating internal ideas into usable code friendly expressions. If you have ever observed someone struggling with learning to type, you know the situation.

Yet some developers, even experienced ones, use only a minimal subset of their editor.

How did these gurus become so proficient with their editors? They practiced. And practiced some more. They made mistakes. And they made more mistakes. I don’t feel I understand something unless I make the same mistake at least ten times. Your mileage may vary.

My Experience with Learning vi and others

As I was learning my preferred editor, vim, I stumbled about and learned the basic operations. I remember creating a sheet of commands that I kept next to the terminal. I then promised myself to learn one new command a day. When I took a break I read about a new command. I then practiced that command multiple times on some junk text. Adding that command to my sheet allowed me to repeatedly practice recent commands on a somewhat daily basis.

In short, I studied and practiced about my editor.

The same study method applied to keyboard shortcuts to minimizing mousing about.

Practicing my programming language with the same rituals meant lots of reading code, typing it into some file, debugging that code. That language was getting into my bones.

When I was learning to type, I reached an acceptable plateau. But I noticed that I frequently glanced at the keyboard. So I endeavored to become a touch typist. I refused to look at the keyboard even when I made a mistake. My productivity plummeted as I felt hobbled by the crush of typos and fat fingers. As my touch typing skills progressed, my productivity slowly increased. Fewer typos appeared. Overall I feel my typing speed has increased – or at least I feel much more comfortable and much speedier.

The learnings from proficiency with an editor and touch typing contain a gem. Learning a skill well involves internalizing the behavior to a point where the ingrained operations do not involve conscious thought.

Then the flow of creativity becomes friction-free.

Conclusions? – Or just a start?

These observations should be obvious to almost anyone. So how many skills do we perform that we could perform much better if we could internalize that skill? How do the many clumsy behaviors inhibit our productivity? How much better would we feel about ourselves if we devoted some little time towards developer in an internalization?

About Cecil McGregor

As a software developer with many years experience, I am offering some of the many insights learned through the school of hard knocks. My passion is writing software! And I like to write superior software. I try to follow current trends and techniques as I apply them to my everyday work.
This entry was posted in analysis, code reading, software, software development, techniques. Bookmark the permalink.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.