Monday, September 10, 2007
What Programmers Do
For every post on this site, there are five or ten that I write and never post. My favorite topic for these never-posted masterpieces is to answer this question:
What do programmers do?
Before answering the question, "write programs, of course!" I should stipulate that the person who asks such a question is usually not a programmer (except when it's me asking the question, and then I pretend I'm not a programmer).
I think of a programmer as someone who fills two roles: one of specification, and one of abstraction. Too far in one direction, you're a project manager (my current job). Too far in the other direction, you're an electrical engineer (a job I will never have, but always kind of want). But somewhere in the middle, you do both- you coerce specifics from the humans, and coerce abstraction from the machines.
Specification begins with a need, order, complaint, itch, feeling. Something is too difficult, too slow, or not cool enough. Or maybe someone is bribing the programmer with fancy hardware or money or caffeinated beverages. It ends with some detailed notion of how the user of the resulting abstraction will interact with it.
In reality, the specification process might gloss over that last bit, and remain... "less specific." That's generally bad, for reasons I'll elaborate on in some future note.
Abstraction ends with a solution which matches that specification. The abstraction might be many layers deep, but eventually it allows hardware (tediously specific - allowing a very narrow window of electrical charges to perform all its functions) to interact with a person.
And once again, reality. Specification and Abstraction usually happen at the same time. This is often necessary, for reasons I'll elaborate on in some future note.
So in the end, what programmers do ranges from talking to people to playing with hardware, and just about everything in between.
But our job is named for the part we like the best: write programs, of course!
Before answering the question, "write programs, of course!" I should stipulate that the person who asks such a question is usually not a programmer (except when it's me asking the question, and then I pretend I'm not a programmer).
I think of a programmer as someone who fills two roles: one of specification, and one of abstraction. Too far in one direction, you're a project manager (my current job). Too far in the other direction, you're an electrical engineer (a job I will never have, but always kind of want). But somewhere in the middle, you do both- you coerce specifics from the humans, and coerce abstraction from the machines.
Specification begins with a need, order, complaint, itch, feeling. Something is too difficult, too slow, or not cool enough. Or maybe someone is bribing the programmer with fancy hardware or money or caffeinated beverages. It ends with some detailed notion of how the user of the resulting abstraction will interact with it.
In reality, the specification process might gloss over that last bit, and remain... "less specific." That's generally bad, for reasons I'll elaborate on in some future note.
Abstraction ends with a solution which matches that specification. The abstraction might be many layers deep, but eventually it allows hardware (tediously specific - allowing a very narrow window of electrical charges to perform all its functions) to interact with a person.
And once again, reality. Specification and Abstraction usually happen at the same time. This is often necessary, for reasons I'll elaborate on in some future note.
So in the end, what programmers do ranges from talking to people to playing with hardware, and just about everything in between.
But our job is named for the part we like the best: write programs, of course!
Labels: programming
Subscribe to Posts [Atom]