The Programmer

In trying to describe what a programmer does, it’s easy to get sidetracked into discussions about compilers, delivery methodologies, design principles and frameworks. And then we try define the attributes of a “good” programmer when we’re really trying to define a “valuable programmer” [or team]. And even then, we can get sidelined into discussions about how a valuable programmer communicates, approaches design, deals with team conflict, translates and can abstract appropriately.

and that’s all good. But there is a less spoken of attribute which is very valuable:
is the programmer a servant?

As a programmer, i believe my existence is [should be] one of servanthood. All my decisions regarding design, implementation, methodologies, conflict- should be underpinned by an attitude of “to serve”.
I have heard programmers [myself included] negate a user request because:
“…the system is not designed to do it that way…”
“…it’s too difficult to implement…”
“…it’s too much effort…”
“…it’ll break the class design…”
“…too much refactoring…”
i do conceded that these may be valid reasons in the right context. As i’ve paraphrased them here, imagine these responses to be expressed void of any attitude to serve.

So… rather, if the class design won’t handle it, change the design.
If it’s a mission… make a plan.
Bottom line, a programmer exists to serve the needs of the user [ note: i say “user” and not necc the whims of the product manager/owner- that’s a different discussion alltogether 🙂 ]

And if you approach your choice of compiler, methodology, framework, team members, or principles; how to deal with conflict resolution, translation, communication… all of the above with attitude to serve, and serve your user well… the rest is mostly detail …