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 identify a developer according to this spectrum, and describes how best to manage each developer personality-style.
Tame Ducks: Tame Ducks are the backbone of any dev team. They’re competent, though not adventurous coders, inclined to reach for a StackOverflow answer when confronted by any unusual technical requirements. Tame Ducks are generally easy to manage, get on with the job, etc., but tend not to ask questions or push back on quite-clearly absurd requirements. They produce decent working code, but won’t come up with the most innovative solutions. Great maintenance coders.
Wild Ducks: Wild Ducks are frequently those legendary “10x” developers. They are your innovators who will break new ground, but it’s hard to get them to follow rules, comply with standards, etc. Unfortunately, about 3 time out of 4, the code they produce, while brilliant, will be code that was simply not required. They just thought it seemed like a neat idea. The code will also be utterly incomprehensible to lesser developers, a reality that your Wild Duck will treat with disdain and contempt. Give them the tough stuff to code, but have it translated into something more maintainable afterwards by one of your smarter Tame Ducks.
Lame Ducks: Lame Ducks are often junior developers (i.e. any dev with less than 5 years’ experience) who are still struggling to figure out just what software development is all about. Older Lame Ducks are the developers for whom it’s merely a well-paid job, a 9-to-5. Lame Ducks frequently have difficulty telling the difference between a good solution from StackOverflow and a bullshit answer. 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, in time becoming a Tame Duck, or they will Ship Out and become consultants.
Quacks: Quacks talk a good project, with a 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: place the Quack firmly between a Wild Duck and a Tame Duck. The Wild Duck has exquisitely sensitive bullshit-detection sensors, 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, and to provide the Quack with a model way out of their ignorance. The Quack will almost certainly soon move on, though on rare occasions it has been observed that the Quack 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!