Software Developer Patterns I: Enthusiast

In keeping with Christopher Alexander's seminal tome: A Pattern Language: Architects, Designers, Construction Workers, I have decided to document the pattern language of Architects, Developers, QA.

Although I cannot hope to document every pattern you see in your co-workers, I can, at least, start by codifying those patterns familiar to all. I do not claim to have invented these patterns, only to have begun the process of collecting them together into a common language to aid in communication.

Instead of grinding your teeth at your next design review, you can instead retort, "You were being a bit Enthusiast there, weren't you?" Your co-workers and the intended target, having read these patterns as well, will immediately understand what you're implying, and, chastened, acquiesce to your superior intellect.

Although developers are geeks, and therefore one-dimensional, maybe two-dimensional at best, you'll find that some of your co-workers exhibit not just one, but possibly two, or even three of these patterns. Some might even defy classification: occasionally, you may find that rather than treating your co-workers as the avatar of one of these patterns, you may have to treat him or her as an individual, with complex motivations and rationale. This is an edge case which can be resolved through good QA, or possibly an exception-handling routine.

Structure
The structure for each pattern will be as follows:

• Name: The name of the pattern
• Overview: An overview or description of said pattern, how it might be recognized.
  
• Motivation: The primary motivation of the pattern-exhibitor.
• Applicability: Where this pattern is useful, where it isn't.
• Collaboration: Who this pattern can collaborate with in order to form a team.
• Consequences: The likely outcome of employing this pattern.
• Sample Conversation: An example of a conversation between an arbitrary observer and a pattern-exhibitor.
• Known Examples: Well-known members of the community who exhibit this pattern regularly.
• Related Patterns: Similar patterns; ways in which these are similar and different.

In keeping with the broadcast television model, I'm going to stretch these patterns out over a series of intermittent posts. If I thought you'd stick around in between, I'd play advertising, but I figure most of you have Tivos or other PVRs by now, and wouldn't watch them anyway. That said, I'm told that it makes economic sense to give a 'free sample' to get you hooked, so without further ado:

Enthusiast (Fan; Zealot; Cultist)
Enthusiasts feel strongly about their technology choices. They identify with them on a personal level. When push comes to shove, they will defend these technology decisions with the zeal of a cornered badger using all the techniques in their arsenal: ad hominem, straw man, yo mamma, whatever approach prevents them from having to face the deeper issues.

Motivation
Enthusiasts often relate closely with technology because they have trouble relating to other humans and/or animals. Unable to form friendships and relationships, or even to own a pet, they transfer this emotional bond to objects with which they feel the most intimacy: a programming language, a hardware manufacturer, or something of that nature.

Applicability
Enthusiasts make good bloggers, evangelists and marketers. Their enthusiasm is so strong it can be infectious, particularly when they're preaching to the already-converted. They are not well-suited to fielding criticism, performing quality-assurance or to lend an objective eye. They cannot be trusted to make high-level decisions that touch upon their areas of enthusiasm. A Lua enthusiast asked to choose a programming language for his or her project will stack the deck in favour of Lua.

Enthusiasts are a good choice to help a team succeed with a technology to which the team is already committed. If you're well down the path of implementing your system in Erlang, it's great to have an Erlang enthusiast around who can tell you about Erlang Conf East, or what's happening at the Erlang user group, or what libraries the Erlang community is talking about.

Collaboration
Enthusiasts pair well with Worker Bees, who may gain energy from the enthusiasm, and learn from the Enthusiast's constant stream of well-meaning knowledge. They can have productive discussions with Builders, but should probably not be kept in close quarters for too long. Rarely do an enthusiasts and Dependency Minimalists see eye-to-eye. They get along well with Architecture Astronauts, but nothing good can come from this union.

Consequences
If an enthusiast is channeled well, they will act as a font of enthusiastic energy and useful knowledge to the team. A misdirected enthusiast with too much power will make arbitrary decisions that hurt the company and dismay the team.

Sample Conversations
"ASP.NET allows you to drag-and-drop UIs!"
"The iPhone API is composed of HTML, Javascript and Ajax."
"Macs aren't really that much more expensive, when you consider what you're getting."
"Smoking cuts ten years off your life."
"'Well you know. Smoking takes ten years off your life.' Well it's the ten worst years, isn't it folks? It's the ones at the end! It's the wheelchair kidney dialysis fucking years. You can have those years! We don't want 'em, alright!?"
"I'm thirty times more productive in Ruby on Rails than I ever was in Java."

Well-Known Examples
Apple customers. Ruby zealots. Bruce Tate.

Related Patterns

• Early Adopter: Like an enthusiast, but the enthusiasm is applied broadly to 'all things new' and tails off as the pattern-exhibitor grows bored of each item.

• Hawthorne Effectors: Not necessarily enthusiastic about technologies, but exhibit improvements in work when confronted with change.

• Cargo Cultist: Adopting enthusiasm for practices or technologies without understanding the reasons behind the enthusiasm.