What makes a programmer?

The answer to this rather philosophical question came up yesterday on the way home from my company's parachute jump event (more on this in a later post). My superior explained how he used to program in the past: "Try something, and if it works add more. Things that are used more then once are moved into methods." This approach will work for small projects, but will create a big mess over time. It will definitely create a mess immediately for larger projects. We are lucky that he is a good manager, but also lucky that he does not program for our customers.

So how does a good programmer work? In my opinion the sole work of a programmer is to map abstractions onto other abstractions, and to add new abstractions when this is not possible.

Lets give a simple example. XML documents are a well known abstraction for a hierarchical structure of labeled values. Files are a well known abstraction for a named sequence of bytes. To persist an XML document one writes code that maps the first abstraction to the second. How to do this is well described in the XML standard, but is definitely not the only way. I have written more performant mappings for specific cases.
A more complex example: to understand a voice command, one of the mappings might be from a sound sample to vowels and consonants.
Other types of abstractions are written in functional designs, test documents, etc.

So what makes an excellent programmer? An excellent programmer:
- Works with well known abstractions. There is not much to know about XML documents and Files. This makes them easy to understand and versatile. RDMSs provide an abstraction for storing tabular data. They are more complex, but well know.

- Will create small and consistent new abstractions.
An excellent programmer will create small levels of abstractions in his system with consistent terminology. For example, while processing sound samples it may be wise to create an intermediate level of abstraction that facilitates working with different sample rates and sample sizes. Consistency can be reached naming things carefully. Simply using the same names for the same things is a good step.

- Can work with many levels of abstraction at the same time.
At times it will be necessary to understand how the different abstraction mappings interact. For example, while persisting a phone book in an XML file, you need to know what each mapping does with character encoding.

So how do you do all this? Unfortunately I have no simple receipt as my manager has. I am afraid, excellent programming is still a craft.