Programmer Typology
The following two statements were posted in an [Atari forum thread] in response to somebody's question about the "flowcharts" that are mentioned as such pivotal recruitment devices in How to Recruit a Programmer.
The postings have been edited for typos and layout, but are otherwise unaltered. Feel free to scroll down and comment.
...and don't take this too seriously, please. It does raise an important point on the subject of the mentioned "flowcharts" though. Be sure to read the comment section too.
Programmer Typology
Grimfort writes in an initial statement:
I myself consider there to be two categories of programmer.
There is the code monkey who takes all your flowcharts, descriptions and other diagrams, and types it into code; that is, a copy-and-paste coder.
The other is a developer who actually designs the classes/ideas around the system based on the input from the game designers. These are the coders that put their experience and skill into designing the system to look good, run smooth and be easy to impliment.
Give the developer an idea of what you want, you're obviously looking for a programmer because you can't do it yourself or have no time. Let them use their skills – that's their job.
If you are going to give detailed diagrams, ensure they are just a suggested way of design.
DFlor elaborates on that in greater detail:
Actually, I have two different categories of programmers:
- The Automaton
Someone who was created by the university system and schooling. These programmers know only how to do specific tasks, and otherwise have no minds of their own. These are the type of programmers that could write an entire quicksort routine from memory and use it over, and over, and over... These are the kinds of guys that have eighteen different certifications.
These programmers are incapable of deviating from the norm – if you have them do something that goes beyond anything they've done before, they're out to sea without a paddle. For instance, if you want a progress indicator for the above quicksort, they would spend days doing it because it's not documented in any of their books.
These programmers are good for grunt work, work no true programmer wants to do. Converting data (the formats of which are well defined), implementing user interfaces, etc...
For these programmers, a flowchart or some sort of document is essential, because they need to know exactly what they need to do. If you want them to build a house, you need to go as far as to tell them how many inches between each nail.
- The Free Thinker
These programmers are generally self-taught, rebelling against the establishment and the educational systems. All the methods, all the reasoning, all the programming creativity was not given to them – they had to learn it through trial and error. These programmers probably didn't actually study computer science in school (I've known patent lawyers and musicians that are damn good programmers), and the only reason they would get a certification was because an employer asked for it.
These programmers need to be told what to do in the most superficial of ways, and then left to their own devices as to how to do it. You tell them where you want to go, and they'll pick the way that suits them to get there.
These are the kind of guys that you can simply tell "build me a house," but you do have to keep an eye on them or else they'll build the house for themselves.
"Automatons" need a flowchart or a exceedingly detailed scope of work, design document, etc... They need to be told down to the most vivid detail what you want. And, believe me, they will do it down to the most vivid detail – if you accidentally state that a pistol can carry 300 rounds of ammo instead of 30, 300 it will be until told otherwise.
"Free thinkers" could make do with a simple design document, and you'll get to see how things progress through subsequent builds.
If you think I'm exaggerating this, you haven't worked in the industry long enough.
Comments
Mychaeel: I found those comments worth preserving so they wouldn't just glide into the oblivion of a forum archive or get crushed in a Great Purge.
Foxpaw: I can't say that I completely agree with the above.. I started out with and would consider myself to be in the second category of both of those descriptions, but I've still taken some courses at University. Most of the stuff was things I had already discovered, but in the two years I've gone so far I picked up a couple of concepts I may not have come up with myself: the red-black tree (which, admittedly, I don't use, but it's still cool) and linked lists. (which I loathed at the time but now love) I find that employers like to force people into the "code monkey"/"automaton" role because the designers have their own vision of exactly how they want things to work out. Once when I was working on an online game I suggested that we change the implementation of the weapons (basically the weapons were hard-coded) to a modular, configurable system that would be completely backwards compatible but would allow for future expansion. This request was flatly denied as it was "unnecessary." I implemented it anyway, with full backwards compatibility, and told noone. 
inio: I agree with this to an extent. However, I think these two posibilities represent poles on a continuum rather than boolean abolutes.
Mychaeel: Having studied computer sciences obviously doesn't immediately discount anyone as a "code monkey," but you'll get more of them out of university than there are self-taught ones. If somebody has the mindset of a code monkey, they usually wouldn't have become self-taught programmers in the first place. Again, as inio says, there are gradual differences, not just black and white.
Haral: I'm trying to put into words exactly why I don't like the above description. Maybe it's because of the overly elitist attitude of the author, but I think it's more than that.
I am self-taught. My parents were programmers and refused to teach me a single thing, as they wanted me to learn how to find my own solutions. This is something nobody else can teach you. You have to learn to do it yourself. People can give you tips, recommend resources, and give you encouragement. However, nobody is going to teach you to find solutions on your own because then it wouldn't be on your own.
Programming is a constant state of learning and thus it's all about finding your own solutions (somebody has gotta find them, and if it's not you, why are you even in the picture?) Because learning to do this is something you must do on your own, universities will never be able to directly teach you to do this. This is why so many CS students will idiotically say "we haven't learned that yet" rather than going and doing it.
However, it has nothing to do with universities. They can't teach you that, but they can still be a valuable resource. After all, our brains are all running different interperaters and sometimes you just can't parse that load of crap you just read... other humans with that understanding can help adapt it into something you can understand too.
So I wouldn't even call this 'programmer typology.' There's only one kind of programmer: the one that writes code. This so-called 'code monkey' can be replaced by downloadable modules.
Dante: Most people in my university don't have enough coding practise. They used Perl/Java/Prolog/Pascal/... for the things they needed it to pass their classes (like red-black trees 
. But most of them wouldn't even want to code for a project, let it be a mod or some other thing. But it's their right to some extent, since cs != programming.
I think code monkeys are people with other professions like mappers. Like I create little cubic levels to test my code, they create little cubic sourcecodes to test their maps (or so). The problem with this is that maps share common code while code doesn't really depend on anything else than code. Ok, I'm getting OT here...
Mychaeel: Obviously nobody wants to be called "code monkeys" themselves, so I guess the definitions will vary wildly to satisfy anyone. – I believe the described difference is more comparable to that between a novel author and a technical writer: Granted, you need the same basic skills and the creative demands of good technical writing are not to be underestimated, but in the end they are not comparable to the creativity and effort the author of a good novel has to put into developing and writing an intriguing, complex and most of all believable story (especially if it's not set in our contemporary world).
EntropicLqd: Heh. I have three categories of programmers. Those who write code you know will need to be re-written from the ground up before it goes live, those who write code that will do the job as long as you don't need to extend it in some unexpected direction, and those who write code that meets all of the stated requirements and can be easily extended in unexpected directions. The differences between them can be seen in the care and thought put into the split/categorisation/composition of data structures and program function.
Mychaeel: I suppose that categorization could be considered orthogonal to the one at the top of this page – I even suppose you're equally likely to get any of those three sorts of code from either of the two alleged "types" of programmers described above.
EntropicLqd: Heh - it's more of a probability curve to be honest. The alleged first type of programmer is much more likely to produce my first category of code than my final type (if they can manage it at all). In my universe the second class of coders we have here would be pretty much incapable of writing anything that fits in my first category (even if it's a prototype). As already observed the two main programmer categories are very much at opposite ends of a "programmer type" spectrum. Most programmers will also have their "type" oscillate around their "base position" over time.
