Types of programmers in 12 archetypes

People who deal with code can be very peculiar. What do you think of when you hear the word `programmer`? A strange but genius guy with no social skills? I can assure you that there are such people, but you are likely to meet also other types.

We had a crazy idea to try to use 12 archetypes (normally used in psychology) that were defined by Carl Gustav Jung in order to define different types of programmers.

Here’s what we came up with. Which of these guys have you on your team?

InnocentThe Innocent

Many people believe they are programmers, but, in fact, they are just dreamers. It`s good to have a dream and believe in it, still if the dreamer doesn’t sharpen his skills, he will remain a dreamer. These people usually overestimate their skills building castles in the air.

720×90 tech recuitment certification course

Regular GuyRegular Guy

A regular person is usually `good enough` – he has proper skills, performs well, but you know that this person doesn’t do his best. These programmers are not very involved, often slow but steady.

HeroThe Hero

Problems with meeting a tight deadline? Coders failing at their work? Is the project dying? Here is your hero, your Superman. A hero is a person who helps you with the most difficult cases. Such person is willing to work a lot, under pressure and knows how to fix what other people messed up. It`s like Clark Kent becoming a Superman – at first he seems to be a regular guy, though, when the situation occurs, he reveals his true skills and saves the day. There is one more type of a hero or rather a wannabe hero – the Code Cowboy. A code cowboy is a person who wants to help but is doing it in an irregular way. He is working quickly without much thinking. If it comes to a deadline, a cowboy will do everything to meet it even if it means shooting out non-lethal parts.

JesterThe Jester

You only live once so why should I care? The Jesters live their lives to the fullest. They change their job when they get bored. They are people with a ton of experience, but they don`t want to grow up. The Jesters are fun to work with but can be hard to deal if they like partying hard.

CaregiverThe Caregiver

In the world of programming, the caregiver can quickly become the Martyr. It is a person who will sacrifice himself to work. A workaholic in caregiver`s shoes. The martyrs take pride in sleeping in their workplace. They do everything to get the job done. They sometimes care so much that they don`t notice they try to lay a guilt-trip on the rest of the team.

ExplorerThe Explorer

Ninjas are people who do their work with precision and speed. They work alone, know what they have to do even before you tell them.

Justin James explains it in this way: “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!”. They explore the solutions on their own so don`t force them to work as a team member.

RebelThe Rebel

Although ninjas can sound like they are rebels, they don`t do the experiments. The one whose the motto is `Rules are made to be broken` is the Rebel, the Experimenter. Experimenters are constantly looking for new solutions, new frameworks, better languages, better code. The problem is that often the only work they do is experimenting. Breaking the rules also can confuse the rest of the team and make the work harder to do.

LoverThe Lover

`You’re the only one, my beloved code` – welcome to the world of the Hardcore Geeks and the Fanboys. They love what they do. The code is their child. The one they want to make the best in the world and the one they protect. It`s not a problem unless they are obsessed.

Aidan Huang writes that the hardcore geek is often “very much an introvert, he feels most comfortable in the world of code and programming jargon. The more code the hardcore geek writes, the more content he feels. As great as he is with code, he makes for a much better worker bee than a leader.”

CreatorThe Creator

Every programmer has to be a creator. Among creators, there is one particular type who can cause a lot of problems when he is gone. The MacGyver of programmers. The person who can fix anything in anytime, but in a way only this person can understand. He doesn’t care how his work looks like as long as it is working.

SageThe Sage

The experienced programmer who may appear outdated, but has knowledge and experience he can share with others. The Sages can seem slow but they know what they are doing and in a steady way they win the race with great results. There is one more type of the Sage – the Theoretician. They have great knowledge, know the best solutions, can spend hours on lecturing on programming, and they are more interested in options than what should be done.

Steven Benner describes such person as: “He will spend 80% of his time staring blankly at his computer thinking up ways to accomplish a task, 15% of his time complaining about unreasonable deadlines, 4% of his time refining the options, and 1% of his time writing code. When you receive the final work, it will always be accompanied by the phrase ‘if I had more time I could have done this the right way.'”

MagicianThe Magician

Coding is like magic – you write some symbols and boom there is a new thing. Some programmers are like magicians – you don`t need to know the details, the technical aspects of their job, you can trust them. They are making your vision a real thing.

RulerThe Ruler

There are different types of Rulers. One of them is the VIP – the kind of person who thinks he is the most important person in the project. Such person looks down on other team members and argues about everything that is against his vision. A similar type is the Perfectionist – a person who won`t allow the project to go further unless he is content with the results. Next two types of rulers are `the Evangelist` and `the Clever Ambassador`. The Evangelist is a person who insists on using some particular tool, language, solution and attempts to revolutionize the workplace. The Clever Ambassador is the face of the team. The Ambassador has excellent communication skills and knows how to sell the work of the team. He is also a great supervisor of the team.

720×90 tech recuitment certification course
Share the article ...
41
Share the article ...
41
  • Very cool and suits to many parts of live.

  • Pingback: 37 best articles from 2015 on recruiting programmers()

  • KellyManning

    An IBM manager I was seconded to for several years said that he had formulated a plan to convert me from a Hero into a Legend. It seemed to work because I never got any feedback about getting with that program.

    Code I produced was never obscure, or hard to follow. In fact when my employer decided to convert from CODASYL COBOL DB (similar to IDMS) and DC on a Honeywell mainframe to IMS DB DC on an IBM Mainframe my transaction programs were the easiest to follow. I even showed them examples of how to minimize the system overhead for inter language calls between PL/I and COBOL in the days before Language Environment melded all IBM mainframe languages into one run time library environment.

    I also solved a Highly Visible (every Pharmacy in the province) DB2 Name Search Query PR head ache that had eluded national experts at IBM, and elsewhere, for over a year, with 8 hours of part time query prototyping and tracing. Then it took months of white hat social engineering to get them to actually try it out in production. At that point the never ending bad PR nightmare vanished, so I asked them to put a letter saying that in my personnel file, which had some unintended negative career impacts for the people who had been ignoring my tuning advice for months. It wasn’t complex like Socket Science, it was just that they used date related Column Functions that the DB2 Optimizer did not recognize as indexable values, so DB2 pulled huge Candidate Row Sets and then evaluated the Column Functions. Adding BETWEEN low_year || January_01 and high_year||December_31 reduced the Get Page Count by 99% for an exact year search and by 90% for a +/- 5 year search. New staff at the recalcitrant branch were apparently told to always stay on my good side after that. To me it seemed like a routine Query Tuning exercise. The only glitch was that they didn’t want to listen to me, so I had to engage other people to do an in their face demonstration of the performance difference. Sometimes it is the messenger, not the message. I am great with computers, but have a communication deficit.

    My wife sometimes calls me Data or Spock at home. When I told her about being told that “this query is fully optimized, only an SQL God could improve it” she laughed and said that anyone who has worked with me knows that I was born on another planet, so they should not have been surprised.

    IBM losing most of that contract coincided with a bigger outsourcing. With IBM I had the choice of being seconded or getting a job offer from I’ll Be Moved. With the second outsourcer the choice was switching employers to MAXIMUS BC or walking out the door with 13 months severance pay and a once in a lifetime opportunity to put half of it into a Tax Deferred Canadian RRSP. I contracted with TELUS DBA team 7 for 12 months, and then got a cold call solicitation from a recruiter at CGI, had picked up the limited remnant of IBM’s original service contract. While working for CGI I got an after hours call from the 1st outsourcer, saying that their major client enrolment online transaction had been dead in the water for a day due to a failed roll back and they had no idea how to restore things to the previous version, since their attempts to do that had failed.

    I joined a conference call with staff from MAXIMUS and TELUS, including the TELUS manager responsible for all DB2 DBA support. The issue was that they had refused to use DB2 Package Versioning and had not tossed the precompiler version of the package from libraries at all levels of migration, along with the bound package version in the backup package collection I had created. They were discussing all sorts of complex Rube Goldberg solutions that posed potential stability issues to the integrity of a large, shared, DB2 subsystem.

    At that point I asked them if the old package version they needed still existed in any of the dozens of Unit Test, Integration Test or User Training environments they maintained. They said it was, so I asked them if anyone had tried binding the bound package across DB2 Servers, from Test to Prod. Silence, until one of the MAXIMUS manager asked if anyone had understood what I just said. At that point I exited the teleconference, looked up an IBM manual reference to using 3 part names when binding, with the first part being a system alias for another DB2 server, and emailed the link to the MAXIMUS programmer I had the most confidence in. He forwarded it to the TELUS manager for DB2 and they made the necessary SYSADM and PACKADM changes to do that and the application was up and running the next morning. They also started using Package Versioning.

    Sometimes it pays to Read the Fine Manual and remember obscure details of options. Other times it can limit your view of what can be done with technology. In “The Winter Market” William Gibson suggests that reading the manual limits your view of what can be done with hardware or software to what the design team thought of. That wasn’t a problem for me when I proof read IBM IMS manual drafts during IBM Early Support programs for 3 versions of IMS.