Programmers enjoy a reputation for being peculiar people. In fact, even within the development community, there are certain programmer archetypes that other programmers find strange. Here are 10 types of programmers you are likely to run across. Can you think of any more?
Note: This information is also available as a PDF download.
This programmer type looks like a short-list candidate to play Gandalf in The Lord of the Rings. He (or even she!) has a beard halfway to his knees, a goofy looking hat, and may wear a cape or a cloak in the winter. Luckily for the team, this person is just as adept at working magic as Gandalf. Unluckily for the team, they will need to endure hours of stories from Gandalf about how he or she to walk uphill both ways in the snow to drop off the punch cards at the computer room. The Gandalf type is your heaviest hitter, but you try to leave them in the rear and call them up only in times of desperation.
#2: The Martyr
In any other profession, The Martyr is simply a “workaholic.” But in the development field, The Martyr goes beyond that and into another dimension. Workaholics at least go home to shower and sleep. The Martyr takes pride in sleeping at the desk amidst empty pizza boxes. The problem is, no one ever asked The Martyr to work like this. And he or she tries to guilt-trip the rest of the team with phrases like, “Yeah, go home and enjoy dinner. I’ll finish up the next three week’s worth of code tonight.”
Watch out for Fanboy. If he or she corners you, you’re in for a three-hour lecture about the superiority of Dragonball Z compared to Gundam Wing, or why the Playstation 3 is better than the XB 360. Fanboy’s workspace is filled with posters, action figures, and other knick-knacks related to some obsession, most likely imported from Japan. Not only are Fanboys obnoxious to deal with, they often put so much time into the obsession (both in and out of the office) that they have no clue when it comes to doing what they were hired to do.
#4: Vince Neil
This 40-something is a throwback to 1984 in all of the wrong ways. Sporting big hair, ripped stonewashed jeans, and a bandana here or there, Vince sits in the office humming Bon Jovi and Def Leppard tunes throughout the workday. This would not be so bad if “Pour Some Sugar on Me” was not so darned infectious.
Vince is generally a fun person to work with, and actually has a ton of experience, but just never grew up. But Vince becomes a hassle when he or she tries living the rock ‘n roll lifestyle to go with the hair and hi-tops. It’s fairly hard to work with someone who carries a hangover to work every day.
#5: The Ninja
The Ninja is your team’s MVP, and no one knows it. Like the legendary assassins, you do not know that The Ninja is even in the building or working, but you discover the evidence in the morning. You fire up the source control system and see that at 4 AM, The Ninja checked in code that addresses the problem you planned to spend all week working on, and you did not even know that The Ninja was aware of the project! See, while you were in Yet Another Meeting, The Ninja was working.
Ninjas are so stealthy, you might not even know their name, but you know that every project they’re on seems to go much more smoothly. Tread carefully, though. The Ninja is a lone warrior; don’t try to force him or her to work with rank and file.
#6: The Theoretician
The Theoretician knows everything there is to know about programming. He or she can spend four hours lecturing about the history of an obscure programming language or providing a proof of how the code you wrote is less than perfectly optimal and may take an extra three nanoseconds to run. The problem is, The Theoretician does not know a thing about software development. When The Theoretician writes code, it is so “elegant” that mere mortals cannot make sense of it. His or her favorite technique is recursion, and every block of code is tweaked to the max, at the expense of timelines and readability.
The Theoretician is also easily distracted. A simple task that should take an hour takes Theoreticians three months, since they decide that the existing tools are not sufficient and they must build new tools to build new libraries to build a whole new system that meets their high standards. The Theoretician can be turned into one of your best players, if you can get him or her to play within the boundaries of the project itself and stop spending time working on The Ultimate Sorting Algorithm.
#7: The Code Cowboy
The Code Cowboy is a force of nature that cannot be stopped. He or she is almost always a great programmer and can do work two or three times faster than anyone else. The problem is, at least half of that speed comes by cutting corners. The Code Cowboy feels that checking code into source control takes too long, storing configuration data outside of the code itself takes too long, communicating with anyone else takes too long… you get the idea.
The Code Cowboy’s code is a spaghetti code mess, because he or she was working so quickly that the needed refactoring never happened. Chances are, seven pages’ worth of core functionality looks like the “don’t do this” example of a programming textbook, but it magically works. The Code Cowboy definitely does not play well with others. And if you put two Code Cowboys on the same project, it is guaranteed to fail, as they trample on each other’s changes and shoot each other in the foot.
Put a Code Cowboy on a project where hitting the deadline is more important than doing it right, and the code will be done just before deadline every time. The Code Cowboy is really just a loud, boisterous version of The Ninja. While The Ninja executes with surgical precision, The Code Cowboy is a raging bull and will gore anything that gets in the way.
#8: The Paratrooper
You know those movies where a sole commando is air-dropped deep behind enemy lines and comes out with the secret battle plans? That person in a software development shop is The Paratrooper. The Paratrooper is the last resort programmer you send in to save a dying project. Paratroopers lack the patience to work on a long-term assignment, but their best asset is an uncanny ability to learn an unfamiliar codebase and work within it. Other programmers might take weeks or months to learn enough about a project to effectively work on it; The Paratrooper takes hours or days. Paratroopers might not learn enough to work on the core of the code, but the lack of ramp-up time means that they can succeed where an entire team might fail.
#9: Mediocre Man
“Good enough” is the best you will ever get from Mediocre Man. Don’t let the name fool you; there are female varieties of Mediocre Man too. And he or she always takes longer to produce worse code than anyone else on the team. “Slow and steady barely finishes the race” could describe Mediocre Man’s projects. But Mediocre Man is always just “good enough” to remain employed.
When you interview this type, they can tell you a lot about the projects they’ve been involved with but not much about their actual involvement. Filtering out the Mediocre Man type is fairly easy: Ask for actual details of the work they’ve done, and they suddenly get a case of amnesia. Let them into your organization, though, and it might take years to get rid of them.
#10: The Evangelist
No matter what kind of environment you have, The Evangelist insists that it can be improved by throwing away all of your tools and processes and replacing them with something else. The Evangelist is actually the opposite of The Theoretician. The Evangelist is outspoken, knows an awful lot about software development, but performs very little actual programming.
The Evangelist is secretly a project manager or department manager at heart but lacks the knowledge or experience to make the jump. So until The Evangelist is able to get into a purely managerial role, everyone else needs to put up with his or her attempts to revolutionize the workplace.