What makes a good programmer?
What makes a good copywriter or designer? These are questions not easy to answer. There are many styles and talents used by various people that make the answers to these questions very subjective.
There are, however, a few characteristics that I have observed in working with a large number of good programmers. These mannerisms are so small they sometimes go unnoticed, and yet they can be learned. I do not think that these characteristics are definitive, but I have seen them time and time again among the very best I have met.
Uncommon Common Behavior
If observed unobtrusively, a good programmer will follow a pattern in the way they write the code. Many times it will appear that they are not doing anything at all, particularly at the beginning stages of a project. There will be long moments of pause in which they do little else but scroll around through the code, followed by a bit of doing nothing. Then there will be an intense burst of activity on the keyboard, fingers flying. This burst may be broken up into staccato chunks with very brief pauses in-between each one, but even so it becomes very apparent that they are in a different mode now than they were a moment ago.
This flurry of activity will often culminate in a test-run of the application – then it repeats itself.
Zen of Code
Now I could be mistaken, but I swear I’ve seen many a programmer go into a zen-like state in this moment. Their posture becomes relaxed but alert, the eyes slightly unfocused. I believe this happens because they are visualizing – playing the code through their internal debugger as they enter it. The time they had previously spent seemingly doing nothing was not time wasted at all. That was when they were truly writing the code. Now the keyboard and our awkward input devices merely get in the way of it all, and they are determined to not let that be an impediment. A really good programmer, I believe, at this point already has the code running in their mind – they now pay just a little bit more attention than average to the physical act of entering the code. They strive for less typos, they look for the most compact and straightforward way of structuring things. They become the Hemmingway of Java if you will, stripping out unnecessary keystrokes, keywords that do not need to be there. Perhaps this is why bare-metal languages, with their compact structures, still exist at a time they could be easily replaced with languages more verbose and human-readable.
Those small pauses as they type allow them to “chunk” the information into sizes that the fingers and input device can handle, but that relaxed concentration allows them to follow this chunking method without disrupting the flow they are in.
Programmers are not alone in this regard. Many top writers seem to follow a simillar pattern, penning furiously at times, then seemingly falling quiet. But are they really quiet? Or are their brains flying like hummingbirds?
Conclusions
What can we take from this behavior? Well, would that writer pen as well as they do if they thought of a single word, wrote it, then thought of the next word? They do better to think of full statements, writing the words in their mind before they attempt to put it down on paper. Of course, they may do subsequent passes in which they debate the merits of one word over another.
Simillarly, when writing code, one does well to stop, compose the thought, then when they are prepared write a full statement that ahieves an objective. In doing so, the statement will be better formed, and usually written faster.
This is a small adjustment, but it can have large results. It flies in the face of the “shotgun” approach to coding in which we get in there and start blasting away, going back later to clean up the wreckage. It also forces us to write and organize smaller chunks inside of our heads before committing to what we type out through the keyboard.
The trap in this style of writing is that it is easy to get caught up in the small details, losing sight of the overall architecture of what you are making. Modular code helps in this respect, but I believe the greatest assistance comes from that pause before the typing. I think that good coders have developed, through repetition, a stronger ability to zoom out to the big picture, compare what they are thinking of writing for consequences, then zoom in with the next breath to see if the code they are contemplating will work at a more microscopic level.
The difference between a top-notch coder and an average one is profound, according to some sources they may differ up to thirteen times in productivity. In other words, a really top level coder might accomplish what thirteen other coders could do. Is this the result of having thirteen times as much talent, or rather is it a product of a few simple good practices repeated over and over in developing code? I believe it is the latter.
Some developers find it helpful to keep a pad of paper nearby. Yep, that’s right, good old pen and paper, the most low-tech solution in the world. Many times I have seen top developers making use of the pen for sketching out little maps of how their code should work. They use it as an assistance to “zoom out”, back to the top level, and it helps ground them for what they are writing at a more microscopic level. One of the few big purchases I made after I started working was a Cintiq tablet – one of those interactive screens you can draw on. It was very pricey for my income level at the time, but I have never regretted it for an instant. Being able to draw right onto the screen, with all the cut/paste/move advantages that gives has been incredibly useful for most things I do.
All of this observation comes down to one practical piece of advice: have a clear thought before typing out an instruction on a keyboard. Why? If the thought is not clear at that time, if it is half-baked, you will be divided between the act of entering the keystrokes and conceiving why you are doing so, and neither things will be done particularly well.
How much of an impact can this have? Well, consider how many times the process gets repeated during writing and application (or an essay for that matter). I’m sure that you can see how it all adds up to create such a large divide between the really top-notch programmer and the average one. It is a million tiny victories rather than one big all-encompassing answer.
I reserve the right to modify these conclusions with more observation. 
