Software Developer Pattern: Worker Bee

Second in a series of patterns describing software developers. The original treatise included the Enthusiast pattern.

Worker Bee (Drone; Cog)
Worker bees are willing (more or less) and able (more or less) to implement the code assigned to them in the manner in which they've been told (more or less). They usually do not exhibit a strong passion for software development, a keen design sense or a drive for process improvement.

Motivation
Worker bees are really just hoping to get through the day so that they can go home and do whatever it is that really interests them: spend time with the family, watch TV, roller-disco, whatever. Their motivation for showing up at work every day to develop software is usually something basic like the need to support their family and hobbies, or "I dunno, the pay's good", or something equally gripping.

Applicability
Worker bees are best suited to an environments that other developers might find stifling. For instance, if the development process and procedures is onerous and ineffective, this will not bother the worker bee, who, frankly doesn't care that much as long as you continue to sign the cheques. They are relatively reliable employees who are less likely to move around as more interesting and lucrative opportunities open up elsewhere.

Because they tend to follow the path of least resistance, Worker Bees have a tendency to deliver code of average quality or sometimes lower-than-average. This can be mitigated by regular contact, supervision, code review or simply accepted: not every project and task requires a stellar codebase.

Worker bees are also good maintenance programmers, because, again, they're not looking for fulfillment from their job, so won't mind so much being stuck fixing bugs in other people's lousy designs.

Some organizations believe that development teams should be like factory lines, with a large number of relatively low-skill workers supervised carefully by one or more foreman-types. These organizations are looking for worker bees, and if you hire someone else to fill that role, they'll probably just get frustrated and move on.

Collaboration
Some worker bees are willing to engage and be engaged; these benefit greatly from an Enthusiast, whose enthusiasm and energy may rub off over time. A sheepdog is a perfect fit for worker bees, as long as you don't mind mixing a metaphor. Sheepdogs are happiest when they have a team to shepherd through daily obstacles, and worker bees can thrive in that nurturing environment.

Pairing worker bees with architecture astronauts can be disasterous. Worker bees will happily implement the most wildly outrageous ideas that the astronauts generate without once stopping to question the sanity or applicability of the idea. On the other hand, if you have a highly-placed architecture astronaut whose energy you're trying to divert, sacrificing a worker bee to the task such that the remainder of the team can focus on doing the real work can be effective.

Consequences
A well-channeled worker bee can regularly turn in reasonable (if unexceptional) code in an environment that would drive most developers to distraction. A misdirected worker bee can plant unintentional timebombs through your codebase, or waste the time of other team members.

Sample Conversations

• "You'd like an abstraction layer over the database so that we could swap it out for a cache, a filesystem, a content repository or a filing cabinet? Sure, I'll get started on that right away."
• "No, that's ok, I don't need to know how this feature will be used."
• "The last development book/website I read? Well, there was this one book in college that I liked..."
  

Well-Known Examples
You've worked with these people before, I know you have. Worker bees, as a general rule, don't make it to Well-Known.

Related Patterns

• Cargo Cultist: Although enthusiastic, cargo cultists remain just as oblivious to the rationale behind the practices they follow.
• Consultant: Same basic motivation, but better at self-promotion, sometimes better at coding, and radically more expensive.

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.