Types of programmers in 12 archetypes

By November 3, 2015 September 7th, 2018 IT recruitment, Recruiting Tips
12 types of programmers

People who deal with code can be very peculiar. What do you think of when you hear the word “programmer”? Is it a strange but brilliant guy with no social skills? Of course, people like this exist, but you are also likely to meet other types of programmers as well. We had a crazy idea: take the twelve archetypes traditionally used in psychology as defined by Carl Gustav Jung and use them to define various types of programmers.

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

The 12 types of programmers

types of programmers the innocentType of programmer #1: The 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, but if the dreamer doesn’t sharpen their skills, they will remain a dreamer. These people usually overestimate their skills and end up building castles in the air.

types of programmers the Regular Guy

Type of programmer #2: The Regular Guy

A regular person is usually “good enough” – they have the right skills, perform well, but you know that they’re not doing their best. These programmers are not very involved and are often slow but steady. The Regular Guy can be one of the most difficult types of programmers to motivate, but with the right approach, he or she can make your company grow. 

types of programmers the Hero

Type of programmer #3: The Hero

Problems with meeting a tight deadline? Coders failing at work? Is the project dying? Here is your hero to the rescue, your Superman or Superwoman. A hero is a person who helps you with the most difficult cases. These types of programmers are a godsend in the times of crisis. They are willing to work a lot, even under pressure and know 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 but when a critical situation occurs, he reveals his true skills and saves the day. There is also one more type of a hero or rather a wannabe hero worth-mentioning here – the Code Cowboy. The code cowboy is a person who wants to help but does so in an irregular way. He works quickly without much thinking. If it comes to a deadline, the cowboy will do everything to meet it even if it means cutting off non-essential parts of the project. 

types of programmers the Jester

Type of programmer #4: The Jester

You only live once so why should I care? Jesters live their lives to the fullest and prove to be one of the most tricky types of programmers to manage. They change their job when they get bored and typically have a ton of experience but don’t want to grow up. Jesters are fun to work with but can be hard to deal if they like partying hard.

types of programmers the Caregiver

Type of programmer #5: The Caregiver

In the world of programming, the caregiver can quickly become the Martyr. It is a person who will sacrifice themselves for their work, a workaholic in the caregiver’s shoes, to put it mildly. 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 the fact that they’re trying to guilt-trip the rest of the team.

types of programmers the Explorer

Type of programmer #6: The Ninja/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. Based on our observations, they’re one of the most valuable types of programmers out there. 

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.

types of programmers the Rebel

Type of programmer #7: The Rebel

Although ninjas can sound like they are rebels, they don’t experiment. One of the most creative types of programmers is the Rebel, also referred to as the Experimenter. They are driven by the motto “Rules are made to be broken”. 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 can confuse the rest of the team and impede team productivity.

types of programmers the Lover

Type of programmer #8: The Lover

“You’re the only one, my beloved” – welcome to the world of the Hardcore Geeks and the Fanboys. They love what they do. The code is like their child. They want to write the best code in the world and they don’t like less-than-perfect solutions. This can be a problem because a lot of work is based on finding “good enough solutions” rather than the perfect ones due to limited resources. 

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.”

types of programmers the Creator

Type of programmer #9: The Creator 

Every programmer has to be a creator. Among creators, there is one particular type who can cause a lot of problems when they are gone. The MacGyver of programmers, this person can fix anything in no time but in a way only they can understand. To them, it really doesn’t matter what their work looks like as long as it is working.

Types of programmers the Sage

Type of programmer #1o: The Sage

The experienced programmer may appear outdated but their knowledge and experience can be shared with others. The representatives of this archetype can seem slow but they know what they are doing and by working steadily 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 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.'”

types of programmers the Magician

Type of programmer #11: The 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 or the technical aspects of their job but you can still trust them. They are making your vision a real thing.

types of programmers the Ruler

Type of programmer #12: The Ruler

There are different types of Rulers. One of them is the VIP – the kind of person who thinks they are the most important person in the project. They often look down on other team members and argue about everything that is against their vision. A similar type is the Perfectionist – a person who won’t allow the project to go further unless the Perfectionist is content with the results. The next two types of rulers are the Evangelist and the Clever Ambassador. The Evangelist is a person who insists on using a 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 and supervise.

Types of programmers: conclusion

Do any of these developer archetypes sound familiar? Do any of the types dominate your workforce? The best idea is to welcome various types of programmers to your company, as non-homogenous teams are typically more productive. Remember that each of these types of programmers come with their advantages and disadvantages which makes them more likely to perform under certain conditions. 


  • Very cool and suits to many parts of live.

  • KellyManning says:

    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.

To help you cope with the impact of COVID-19, we’re rolling out complimentary access to video interviews for all customersREAD MORE