Systematic, Pragmatic and Opportunistic Programmers

Steven
Clarke
added a recent
comment
to my blog that I thought was worth highlighting:

Systematic programmers tend to follow a defensive coding
style. They do not make assumptions about the code they are writing, the
platform it runs on, the class libraries that they are using etc. For example,
they do not assume that a class library will behave as advertised. Instead,
systematic programmers will test the library in a safe environment, inspect the
library source code etc before using it in a production environment. Systematic
programmers desire programming languages and APIs that give them full control
over the execution of their code and that do not hide important details from
them, even if it means they have to write more code and take more time to
understand how the code works. They value being able to get under the covers and
tinker with components or even replace them.

Pragmatic programmers tend to be less defensive than
systematic programmers. In many cases, they are comfortable trading off control
for productivity as long as they are aware of the existence of the trade off.
Rather than spend the time understanding the full working details of an API,
they will prefer to learn as they go, building up an understanding of the API,
programming language etc in the context of the work that they are doing. They
value being able to get under the covers and tinker with components should they
need to, but will prefer not having to do so.

Opportunistic programmers value productivity features in a
language, API and IDE very highly, often higher than anything else. Unlike
systematic programmers, they place less value on having complete control over
their code, since for opportunistic programmers, the cost of control is added
development time. They particularly value 3rd party controls and APIs that allow
them to concentrate on the business problem that they are trying to solve,
rather than on configuring the control or specialising the API so that it meets
their requirements. They don't really value being able to get under the covers
and tinker with components - they would rather look for some other API or
control that met their needs instead of modifying controls or APIs that they
already have.

What type of developer are you??