Types of Programmers: Interpersonal
Podcast: Play in new window | Download (53.8MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
As developers we are a rather unique bunch of individuals. Either development attracted us because of certain personality characteristics or we developed them based on the software development world. In either case we have a lot of interesting personalities within the community. These personality traits and styles come together to form certain archetypes.
To the outside world these archetypes might seem quirky and strange. Some personality types are strange even within the development community. Rarely will you find someone who is completely a particular one but you’ll notice these traits, some stronger than others, in most of the developers you meet.
While researching the different archetypes of developers we broke them down into three groupings: Coding Styles, Knowledge Expression, and General Personality. This is the second of three episodes talking about the types of programmers you’ll meet in your career. It focuses on the various interpersonal styles you’ll encounter. If you haven’t done so, go back and listen to our episode on coding styles.
If you are familiar with Carl Jung’s 12 archetypes you might have noticed some similarities with a few of the ones mentioned. Take some time and reflect on which one you identify with and what your strengths and weaknesses are. This is not an exhaustive list of interpersonal archetypes. Instead it’s a group of the ones you are most likely to encounter within your career. While there are others out there you can use this list to better understand your coworkers, managers, and friends in the development community.
The Bearded Wizard
This wizard is the neck beard hidden away in the basement whom you only call on when you have a balrog to defeat. While verbose story tellers who have trouble staying on topic in meetings, these developers are the biggest hitter typically brought in on a project when something difficult or crazy needs to be built quickly. Also knows as magicians, their code is like magic, you don’t understand the technical aspects but just know that it works. When not having them solve the unsolvable problems have these developers working on some obscure area of the codebase, otherwise they will distract your workhorse developers with their stories of building their own Linux kernel.
The literalist is a person who likely knows a lot of details about the system and codebase, specifics so odd most others don’t even know them. However they have trouble when it comes to generalizing or focusing on the business use or how the users plan to interact with the system or app. They tend to get into the weeds and can’t see the forest for the blades of grass. Literalists do great with very detail oriented tasks that other developers find tedious but can’t be automated for whatever reasons.
The Last In First Out
The LIFO will give your task or project their full attention so long as you are the most recent person to ask for their assistance. Last person to ask anything of them gets their full attention regardless of priority. These people have trouble with larger or more time consuming tasks as they get easily distracted by the next thing coming along. The trick to successfully working with them is to isolate them while working together and act as a buffer for interruptions until they are finished.
Fanboys put way too much time into the things they do from anime to console gaming; obsession would be an understatement. The fanatic coder has their favorite language or framework and will never even think about changing, even asking them is an insult. The hipster only writes in VIM, even though they are given an Enterprise Edition of Visual Studio and work solely in .NET. It’s easy to fall into being a fanboy, especially when you are passionate about code or life, so to avoid being annoying find people with similar interests so you can discuss your passions over lunch or breaks.
Jesters take the phrase “work hard, play hard” to heart and live their lives to the fullest. They don’t want to grow up but surprisingly have a lot of experience because they tend to change jobs when they get bored. One particularly troublesome jester is the aging rocker who dresses and acts like they are still in their 20’s well into their 40’s. They can be problematic when they are coming into work tired and hungover almost every day, flexible schedules and remote work options tends to help them find their best time to code.
The martyr goes beyond a mere ‘workaholic’ taking pride in spending all night in the office sleeping in their chair. They lack the ability to shut down and have a life outside of coding so they spend all their time in the office or coding at home. Eventually the martyr will begin to resent coworkers who are able to have personal lives and may even try to guilt trip them into working more. Working with a martyr can be difficult because at first they will make the rest of the team look bad to management, but to really deal with this archetype management may need to enforce a no overtime or restricted overtime policy.
The ruler thinks they are a natural born leader, while they may be one they are not in a leadership or management position on the team or project. It may be a lack of or inept leadership that brings them to light, but they will attempt to take over the team. Some rulers do so because they think they are the most valuable member of the team whereas others are perfectionists not allowing the project to move forward or they may insist on using a particular language, tool, or framework. Strong leadership from management will prevent a ruler for derailing a project, the best way to get them working is provide them a small project to manage themselves but set the deadlines for them.
The 17 Essential Qualities of a Team Player
John C. Maxwell
“You can lose with good players, but you cannot win without them.”
For the next couple of months we’ll be going through John Maxwell’s The 17 Essential Qualities of a Team Player. We will not go through each one as that would take 17 weeks and you can read the book faster than that. However each week I’ll highlight a one of the qualities that stood out to me as I read through the book. This first week we’re going to look at the very first quality, there is a reason Maxwell put it as number 1. That is adaptable. “If you won’t change for the team, the team may change you.” He starts with a story about a very adaptable man in the music industry, Quincy Jones, and how his adaptability allowed him to work with some of the best musicians from Frank Sinatra to Micheal Jackson. He even branched out of music and produced movies and TV shows including one of my childhood favorites The Fresh Prince of Bel-Air. Maxwell then lists out four qualities of being adaptable. First is teachable, they are always learning and willing to take on the role of the student to grow. Second is emotionally secure, they are not afraid of change and accept new situations and responsibilities. Third is creative, when difficult times come creative people find a way to make things happen. Finally is service minded, adaptable people are focused on serving the team not just their own agendas. Maxwell concludes with three ways to become more adaptable: build a habit of learning, reevaluate your role, and think outside the lines.
Tricks of the Trade
A tool doesn’t have to be perfect to use it. It just has to be better than what you have. It’s real easy to look at something and think that because it doesn’t perfectly match everything you see in the world, that it won’t help you. The fact is, if something works better than what you have, you should use it, even if you can see exceptions up front. In fact, if you know the exceptions up front, you are probably better off using it than you are using something that you think works better, but which you don’t fully understand (you’ll see the holes in any implementation once you understand it). Nothing ruins good things quite as thoroughly as hoping for perfect things.