Duck-Typing Developers

Originally posted over at The Evil Place in a slightly altered version.

Developers can be categorised along two orthogonal dimensions: coding- and design-skills vs. team/people skills. Tendency toward sociopathy, if you like.

This post explains how to locate a developer according to this scheme, and describes how best to manage each developer personality-style.

Tame Ducks are easy to manage, get on with the job, etc. They produce decent working code, but won’t come up with the most innovative solutions. Great maintenance coders.

Wild Ducks are your innovators who will break new ground, but it’s hard to get them to follow rules, comply with standards, etc. Give them the tough stuff to code.

Lame Ducks: Deal with a Lame Duck by making Duck Sandwich. Sandwich the Lame Duck between a Wild Duck and a Tame Duck. They will either learn and gain competence and, in time, become a Tame Duck, or they will Ship Out.

Quacks: Talk a good project; strong tendency to bullshit their way through design by resorting to TLAs like SOA, XML, NLP, POA, xDD… Deal with Quacks by (again) making a Duck Sandwich. The Wild Duck has exquisitely sensitive bullshit-detection capacity which, combined with their cultivated lack of tact and an intolerance of freeloaders, will leave the Quack with no place to hide. The Tame Duck is there to back up the Wild Duck’s assertions as to the Quack’s actual performance. The Quack will almost certainly soon move on, though on rare occasions one might reform and become a Wild Duck.

Credit: I first heard this Duck-Typing Scheme from an important mentor in my career, Nat Lunn, sometime around 1990, and so I must credit the whole story to him. Thanks, Nat!