Tuesday, September 25, 2007

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.

Sunday, September 2, 2007

Referral: The Most Honest Feedback

When I recommend someone to work at my company, it's because I've worked with that person before and I actively want to do so again. That's probably the single-most clear, honest and positive feedback I can give to any previous colleague.

Because, let's face it, everyone has some good qualities and some bad ones. If I say something nice about you, I probably mean it, but it doesn't mean that you don't have bad qualities that counterbalance and overwhelm the positive. Whereas if I refer you to a company at which I work, I've weighed all those factors one against the other, and I've decided that, in the balance, I'd still like to work with you.

If a potential employer asks me about someone with whom I've worked, I'll try and give balanced feedback that includes the things I like about that person's work and things I disliked, or found to be challenges. Most of the time, I'll emphasize the positive, but I'll still try and give something from both sides. I don't want to bad-mouth that person, but I do want the employer to get a sense of what the tradeoff is. That said, if that potential employer isn't my employer, I'm not going to push too hard. Even if I don't want to work with that person again, it doesn't mean that I don't want them to find employment anywhere. In fact, I'd prefer them to find employment elsewhere, because that guarantees they won't seek employment with me.

Most people want to be nice, to be perceived as nice by others and by themselves. And as long as being nice doesn't have a direct cost, most people are willing to do so. So if I've worked with someone, and I don't want to work with that person again, doesn't mean I'm not willing to comment on your good sides (and bad) to a potential employer, and let them make up their own mind. If the employer is using different criteria than I am (or isn't listening very closely to what I say), they may end up wanting to hire that person. So much the better; if there's a fit, that's good for everyone.

But if my employer is asking, I have to ask myself, "Do I want to work with this person?" If the answer is no, then I'm going to do my best to make sure that my employer understands that, even if I use the nicest possible terms to get the job done, "Joe is a great guy; friendly, works hard. I'm not sure he's ever going to be a great programmer. He can get stuff done, but he doesn't seem to really have that design sense that you need to be really good, and I just didn't see any sign that he was getting any better as time went on. I'd probably pass." It's honest, it's direct, and most employers will make the right call if you're being that direct. (I've never worked with a developer named Joe; he's just an example).

If another company were asking about Joe, I might be a little less direct. "Joe is a great guy, friendly, works hard. He wasn't in a senior role when I worked with him; I'm not really sure I can picture him in that role, but I haven't worked with him for a few years, so he may have taken on new responsibilities and skills since I worked with him." This is much more non-committal; a really astute observer might ask some probing questions that I'd answer more or less honestly and get to the heart of the matter, but most people would stop there, and draw their own conclusions.

This is probably why, in part, referred employees tend to be better than the ones that come through regular employment channels. Because the referrers have pre-filtered their past colleagues through the "Do I want to work with that person again?" question, and anyone they refer has passed the test. And despite this fact (or, rather, because of it), it's probably a good idea not to make referral bonuses too high: you don't want to get to the point where the incentive to refer outstrips the incentive to avoid referring people with whom you don't want to work.

So, if I've ever referred you to a company at which I've worked, and they've hired you, take heart, that means I'm willing to work with you again, and said good things about you, and that puts you in the upper tier of people I've worked with. It's probably the most unambiguous feedback you could get from me. And if any of you choose to refer me in the future, I think I'll take that as a high compliment.