Eric S. Raymond (of hacker fame) has proposed a list of archetypes.

Although originally for classifying hacker styles, commenters suggest (and I agree) that most of the styles are applicable to people working with software generally.

ESR also thinks most people are a combination of these styles -- usually one primary style with one or two secondaries.

(Note: This is just the current list. It might change.)

---

Algorithmicists: Very good at algorithms and sustained, intricate coding. Have mathematical intuition, and are one of the two types (with Architect) that have the highest tolerance for complexity. They like the idea of correctness proofs and think naturally in terms of invariants. They gravitate to compiler-writing and crypto. Often solitary with poor social skills; have a tendency to fail by excessive cleverness. Never let them manage anyone!

Tinkers: Hackers who are drawn to crossovers with the physical world – will design hardware as cheerfully as software. One of the two types (with Prankster) most likely to be lockpickers and locksmiths. Know practical electronics (including analog and RF), adept at reverse-engineering. When you can get them to pull their heads out of the details (which they may resist pretty hard) they make terrific whole-systems engineers.

Architects: The guys who are fascinated by, and very good at, blocking out architecture in complex systems. Kings of the productive refactor. Have an acute feel for design patterns and can see around corners in design space. Strong drive to simplify and partition; “It’s not done until it’s elegant.” The Architect failure mode is to lose sight of the ground. Architects don’t necessarily have communications skills; if they do, they can make worthy team leads.

Sharpshooters: Tenacious detail-obsessives who are most comfortable with a bottom-up view of code and like rifle-shooting bugs more than almost anything else. In past times they would have been happy writing assembler. Polar opposite of the Architect, very productive when paired with one (and vice-versa). Not a good bet for managing anything.

JOATs: The great strengths of the jack-of-all-trades are adaptability, fast uptake of new ideas, and mental flexibility. The JOAT doesn’t do any one thing better than the other types, but can do a bit of everything – including people and social engineering. The JOAT failure mode is to try to do everything themselves. A JOAT is more likely than other types to make an excellent team lead, as long as he or she remains aware enough to delegate deep technical decisions to others.

Pranksters: Their natural bent is adversarial – they’re great at thinking up ways to disrupt and subvert systems (or just put them to unexpected and hilarious uses). They gravitate to infosec and test engineering. The really good ones can social-engineer people more ruthlessly and effectively than any of the other types.

Castellans: Supreme control freaks who get their power from focusing on what they’re responsible for and knowing it inside out. Castellans memorize manuals; they love language-lawyering, process automation, and vacuuming up domain-specific knowledge about whatever they’re working on. Old-school sysadmins are often castellans: “That will never happen on my system” is their promise (and of course Pranksters love to prove them wrong).

Translators: The type that bridges between human and machine: tends to excel at UI/UX development, documentation, policy and supply-chain stuff, requirements analysis, user training, and so on. Highly social, less hard-core technical than others, but in a way that helps them help other hackers understand how non-hackers see and interact with technology. Some of them make good project managers, but like JOATs they need to understand their technical limitations and mostly leave the hard decisions to types that naturally swim in deeper technical waters. Of all the types, Translators are the least likely to self-identify as hackers even if they are intimate with the culture and working within it.

---

What do you think? Seem reasonable? Missing any archetypes? Do you recognize yourself in these?

Me, I'm an Architect/Translator... but not quite the kind of Architect described here, who is highly concerned with increasing elegance down to the code refactoring level. I'm more of an engineer Architect: I can just see how systems-of-systems need to be structured, from the top on down, to satisfy multiple requirement modes such as functionality, performance, cost-to-build, and maintainability.

Once a system design meets those specs, though, that's good enough for me. I might do one or two more passes to make sure I haven't missed any opportunities for significant improvement, but then I stop. There is always so much more to be done in a practical sense (either on this project or another) that once I've got the pieces generally working together, I move on rather than attempting repeated refinements toward perfection. I think there can be value in that quest for elegance; it's just not my style of Architecting.

Part of Algorithmicist sounds a lot like me... I guess I should absolutely not be community manager, then? I have no way to be a tinkerer, and absolutely do not care about making things elegant, so I'm not an architect. JOAT sounds like me - a bit of everything, not good at any one thing in particular (and ESPECIALLY with trying to do everything myself). Prankster and castellan are both out. As to translator... almost certainly not. I hate designing UI.

In summary, I think I'm a JOAT with a side order of Algorithmicist. I could also be your version of the Architect, Flatfingers - the Engineer.

I think I'm definitely a JOAT. Just not limited to programming, but overall. I can lead people, but also enjoy to sometimes just sit back and take orders. I know a little of everything, I love to accommodate new knowledge, but I'm not the type that knows something in and out. More like the "I don't need to know it all, I just need to know where to look it up" person.

If I were a programmer and not merely working with code I imagine I'd be a translator with dose of architect. If I'm thinking of ways to improve the codes I have it's to get them to a kind of structure which is in principle easily perceived and documented while being 'pleasingly' elegant