Call of the Wild

One thing I noticed while living the glamorous life of a consultant in the greater DC metro area was the daily struggle of the Developer.

Developers as a species do not have it much easier than any other species. They arise early (or late depending upon the gig and the boss), run through morning chores and routines, hit the AM traffic tuned to the Morning Zoo, roll into the early bird pay parking lot, park, grab a muffin and a coffee and then plop down in front of a monitor for the next 10 hours. Just like rock stars do, except for the monitor thing, and the traffic, and the Morning Zoo, and the pay rate and private jet. But similar.

Developers are not herd creatures. They prefer to work alone or, if a brand of Agile is imposed, with one or two other individuals at cubicle-length. It isn't so much that developers are not team players -- they are no less team players than the next species -- its just that when they are channeling divine code from the Muses, they don't want any interruptions. Who has time for team coding anyway? As if Milton, Arnold or Eliot would team-compose poetry?

Developers are wild, dangerous creatures when it comes to territory. Of this I am as guilty as the next guy, perhaps even more so as a consultant than as a salaryman, because I usually rode into an engagement as a hired gun, a High-Plains Drifter packing EAI heat. And without exception the first meeting my peers, the development staff, I'd get shaken down.

Dev1: "So you are a developer? You know C++? So what is the memory allocation performance of the standard allocator in STL?"

Dev2: "We have some VB COM+ code that uses the multi-threaded apartment model. When does it make sense to make it single threaded, if ever? Why should we early bind? Why doesn't VB support inheritance?"

Dev3: "We use Java. I see you have a lot of Microsoft experience. Why does VB suck?"

Dev4: "Can you characterize this algorithm using Big-O notation?"

Developers want to know who is encroaching on their territory, whether they are a threat, and if so to what extent. I have honestly gotten questions like the above and even more domain-specific questions by experts (specific trace flags in SQL Server, PL/SQL optimization questions, even one or two Prolog questions) while being shaken down. Sometimes it is public, sometimes in private, and in most engagements usually both.

Responses vary. I usually answered the technical questions professionally and without emotion. Questions that called into question platform, language and other "religious" issues were pushed to a non-work location -- Dave and Busters, a local brew pub, or some other low-key place where religious issues could be discussed without threat. Almost without fail someone would flip the Bozo Bit on me and declare themselves Dominant based on a syntactical or obscure academic detail that I failed to know, recall, or derive on the back of a napkin in 30 seconds. This was never the majority of developers -- if that happened I would have been bounced out of the gig -- and one or two times it would happen during an interview. I would call these short and bow out; I don't want to work in a place that values the degree to which I have memorized obscure C/C++ compiler precedence rules. Ugh.

As they move up the food chain, most developers appear to become more docile. This is a facade. I have seen the most docile, people-friendly ex-dev project manager disembowel an over-zealous young buck developer who foolishly challenged the PM one time too many on a technical issue. It was fun to watch -- the young buck swatted at the battle-hardened PM's tail like a lion cub. He was ignored the first two times but the third time, nice! The young buck didn't know what hit him. His place in the dominance structure was never the same.

Developers, like other professionals, tend to treat other professions based on how they measure up to Developer. As if "Developer" was a job forged by the cosmos billions of years ago and handed down only to the select few who finagled time on a timeshare system, the B&H Apple ][+ at high school, or a punch-card machine. Hardly. But ask any developer in private where testers, documentors, project managers and even the client rank relative to him or her and learn. None of these groups measure up, none have the status of developer. Or power, perceived or otherwise. And often times this perception gains a foothold in those other professions.

More next time.