The 4 Types of Programmers

This is pure speculation, but I’m currently thinking about patterns in programmer habits I’ve seen on teams I’ve worked on. After doing some research on the ole interwebs, I’m realizing there’s a lot of damage that needs to be repaired.

What This isn’t

Let’s get some clutter out fo the way. There’s a whole bunch written on archetypical programmers and nearly all of it – that I could find – was political, misogynistic, misguided, and wrong.

The “Two Types”

Let’s start with the “two types of programmers“. In this theory, there are only two types, the 80% who apparently hack on ten-year-old Java systems, and then the 20% who download Haskell on the weekends and actually do all the work.

There’s a logical flaw in the ‘two types’ approach. It’s all based on the Pareto distribution – the common adage as applied to, say, productivity, is that’s 20% of the people produce 80% of the work. I don’t have a problem with the Pareto distribution, just in other’s misunderstanding of it. There are two key misunderstandings that lead to the “two types”.

First Key Misunderstanding: False Equivocation

First, the thrust of the two programmers argument is that there are 20% of programmers out there who make all the posts, who use all the technology, who contribute to open source, who care about quality, and who do all the work. This is not what the Pareto principle says at all.

The Pareto principle (technically) says there is some small percent of programmers who make all the posts. There is another small percent of programmers who use all the technology. And so on – there’s nothing magical about 20% but more importantly, nothing necessarily correlated between any of these groups. It’s an assumption that if you’re in one subgroup – say the bloggers, you must be in the others – quality, productivity, interest in technology, and so on.

There’s no reason to think that. The argument falsely equivocates bloggers, or more appropriately, those who read blogs, with the productive few using the concept of ‘alpha’ programmers.

Critical damage to engine 1 of alpha programmer! Falling back to engine 2!

Second Key Misunderstanding: Context is Everything

The second misunderstanding here is similar to the first.

“Austinwiltshire”, you say “I get that maybe the groups of people who read blogs and who are productive aren’t the same. But certainly, you can’t argue with the fact that 20% of the team does 80% of the work. In one of those subgroups, like productivity, there are still alpha programmers.”

Kind of. Not really. Not usefully anyway.

The same situation occurs inside productivity as did between productivity and blog posting, except now it’s project-oriented. The top 20% of people on project A? Not at all the same people that are top 20% on project B. And so on. If you take a top performer out of his or her context, you have no reason to believe they’ll continue to be a top performer. This has actually been shown in studies that I have no idea how to find or link to.

Charles Duhigg points this out in his book, Smarter, Faster, Better. When looking at personal productivity, the only factor that consistently showed up across groups was: were you there when the early decisions were made? This is more or less arbitrary, on average, but gives a model to understand the 20% on any one project. They’re usually the people who were there at the beginning, or as early as possible, and so tend to have the whole system ‘in their head’, whereas latecomers are always trying to catch up to them.

Does this have anything to do with innate talent? No. It has everything to do with being in a certain place at a certain time.

Engine 2 critical! Brace for impact!

The Alpha Programmer Myth

This 20% bullshit is the same stuff that’s been spread about by neckbeards at the top – and I mean that term (neckbeards) literally – for years. Some people “have it” and some people “don’t”. Some people are good programmers, and the rest are just lucky to be able to call on good programmers.

On a certain type of team, you probably have noticed, there’s always one guy (and it’s always a guy) who pulls all of the weight. The master firefighter, the master designer, the sharpest coder, the best peer reviewer. If they didn’t have him, the team would be sunk. What certain type of team is this?

A dysfunctional one. What you actually have is a bully that you’re enabling.

The alpha programmer idea comes from a misunderstanding of early studies into programmer productivity which “showed” that:

The best programmers can be 10x more productive than average programmers

AustinWilsthire, “Quotes I made up for Rhetorical Effect“

I’ve gone into what’s wrong with the ‘common’ view of this adage in other posts. We’ll just sum up here and say that it’s a complete misunderstanding of the science, and it’s an intentional misunderstanding on another mission.

This mission is ultimately what underlies the “two teams” mentality, alpha programmers, 10x productivity and all the other bullshit that’s infected our culture.

Machismo – Or It’s Been Alpha Males The Whole Time

Very few people are 10x more productive than others, and you’re one of them.

That’s what this is all about, right? We read blogs to stoke our egos, we’re irritated that other guys at our company or school or whatever don’t ‘get’ us, and if only they saw how brilliant we are. We know we’re 10x’ers, and one day we’ll get our due.

Right?

All this talk of productivity has been a dick measuring contest this whole fucking time.

We want to believe that there’s a ‘certain type’ of person who can program, who really ‘gets’ it, we want to believe it’s magical, that only ‘some’ people can do it, and  you can either do it or you can’t. We want to wipe away all of our past arguments with others over coding style or language choice or something else with a clear determination that everyone else was wrong – they were 80%’ers, and sometimes they win by sheer numbers, but we 20%ers, we have to stick together.

And all this time, we’re all pretty sure – though no one’s so politically incorrect to say – but we’re all pretty sure that the guys who are the 10xers are all white males. Because I’m a white male, and I’m a 10xer, and the people I think are also 10xers are white males. QED.

Let’s play a thought experiment. You’re studying violin. The violin is hard. Every day you show up, and your teacher, Mr. Yamamoto, berates you. He explains you must not be practicing hard enough, you must not really want it because you’re terrible. His other students – all Asian – seem to play violin better than you. Sometimes, more paternalistically – he takes you under his wing. He explains it’s really not your fault – some people have it and some people don’t. You don’t have to feel bad. He’ll keep trying to teach you violin, but you might also consider something he thinks you might be better at, like hockey.

Do you quit violin?

You sure as shit do.

And so, the few brave women and/or nonwhites who enter computer science programs, or code academies, and they look around and they see a caucasian sausage factory – they struggle. They struggle because everyone struggles a little. But they read it differently – you look around and see your friends.

You see people similar to you, and they seem to get it. You can too, just try hard enough and fight through adversity.

They see people different from them. And don’t think for a second they’re unaware of the 10x myth. They’re worried – they’re worried they’re the bad programmer. Why fight through it if it’s innate, why try if you’ve hit your limit and ultimately you’re a born 80%er?

Needless to say, I’m pretty sick of this dick measuring contest, and I’m really frustrated with the chilling effect its had on our industry. Because we’re all complicit – every time a minority drops out, we get more white and more male. And eventually, we begin believing the stereotype ourselves – we may have gone into programming thinking anyone could do it. But then why did all those black women drop out? I mean, there’s gotta be something there, right?

There isn’t. They dropped out because their professors failed them, our culture failed them, and our curriculum failed them. The dropped out because all of our systems are designed by and for white men, and we didn’t think of how to adjust them for others.

When you read a blog, and it says there are 10xers, and they read the blog you’re reading – or they say there are 20%ers, and they read the blog you’re reading – you’re just playing your role in trying to ad hoc reason your way into why our field is predominantly white and male. Because you’re either a 10xer or it’s all bullshit designed to make you feel better that there’s not more diversity and you’re benefitting from that.

You’re not at 10xer.

The “Three Types”

There’s another system out there, supposedly put together by human usability and marketing types at Microsoft.

Let’s break this down.

Mort

Mort wants things to work right the first time, out of the box, and he doesn’t want anything to be too complex. He gets frustrated easily and just wants to do his little bit of rote work and get home in time to watch his reality TV programs. Mort is dumb.

Einstein

Einstein is always thinking. He wants to know the ins and outs of everything, think it through, he seems to always be leaning back in his chair, ‘thinking’. He seems to know a lot – seems smart.But he never seems to be working. He gets some stuff done, I guess. But ultimately, Einstein never seems to get everything done.

Elvis

Elvis is a rock star. He’s pragmatic, he does exactly the amount of engineering needed. He’ll put in the hours to knock out stellar code. Women want to sleep with him, men want to be him. Gay men don’t belong in computer science, duh.

Smart, and Gets Things Done(TM)

This is all dancing around the point originally invented by Joel Spolsky. You remember? That guy who ran Fogzbugz into the ground? Yeah, peopled used to take him real seriously.

Anyway, he claimed that the key to hiring was to find people who both were smart and could also get things done. This was a euphemism, of course – Joel, also a big believer in the Mort/Einstein/Elvis break down wanted to hire smart people but got sick of hiring people who were smart enough not to do things the way he wanted. So he also wanted people to get things done. “Just fucking do it”

This kind of thinking still hits the culture – it’s a combination of the 10x myth and the ‘passion’ myth, that you should find that weird autistic programmer who will work 80 hours a week for you without equity. Those are the only men who deserve jobs, after all, cause they’re smart and get things done.

Why This May Matter

So what I’m proposing is none of those things. I’m not going to give you a system where you fit into a box that says “I’m the best!”. I’m not going to give you ammunition to dismiss your peers. I’m certainly not going to come up with stereotypes that make everyone who doesn’t understand what a monad feel idiotic, and everyone who doesn’t work 80 hours a week feel lazy.

We should aim for forty hour weeks. And no one knows what a monad is. Jesus Christ, you know people are talking out of their ass when their metaphor is a burrito.

Why make categories at all? Why not just let each programmer be who he or she is and who he or she wants to be? Because that’s actually really hard. Imagine you have a new junior hire come under your wing. You want to find out what drives them so that you can keep them motivated. You want to know what their strengths and weaknesses are, so you can hone their strengths and shore up their weaknesses. More importantly, when you have more than just one junior hire, you need to know how to make the team more than the parts.

It’s said good managers play checkers, great managers play chess. You want to play chess – use everyone for what they’re passionate about and good at. When you have one or two people, usually you can spend enough time with them to figure these things out. But when you have much more, you need heuristics. You need tools and models to help you simplify the problem. Let’s say you have two people on your team you both consider your “Goat” programmers. Putting them in the category goat makes it easy to figure out how they’re different from your “Fish” programmers – it’s primarily the differences between the categories.

Fitting It All In Your Head

Let’s say you have two people on your team you both consider your “Goat” programmers. Putting them in the category goat makes it easy to figure out how they’re different from your “Fish” programmers – it’s primarily the differences between the categories. It also allows you to go into that “Goat” category and say – well Bob and Alice are both goats, how are they different? Becuase once you have a category, you can start to put your powers of soft skills towards teasing out the remaining difference.

Trying to figure out how Bob is different from everyone else at the company is hard. Trying to tell how he’s different from Alice is much easier. Using a model like this, you may be able to get people closer to the work they value and are more productive at.

Hiring Goats

Secondly, you need to analyze your work – what kind of projects are we anticipating in the next six months, what kinds of problems are we facing? Different people get thrills in different parts of the development process. If you have to hire, rather than hire only for overall company ‘fit’ or team ‘fit’ don’t you want someone who might hit the ground running gobbling up all the work that’s coming their way and asking for more?

It also shrinks the amount of time it takes for you to understand what they need and what they want to be happy. If you already prescreened for Goats, and you know Goats like grazing, then you can make sure their desk is near a nice plot of lush green grass. Nothing frustrates a newly hired goat more than trying to squeeze into that fish tank.

Chief Goat

As described below, the four types of programmers I’m envisioning here end up filling very different roles as they grow and mature in their careers. It’s mostly these drastically different career paths that you can see a major difference – and it’s an argument backward to more or less saying “Well if some people are better Head Goats and others are better Head Fish, maybe they start out naturally as Goats and Fish too.” Along with coaching people to keep the team gelled, coaching people in their careers towards parts of the projects they naturally get something out of makes the most out of their potential and keeps people happy.

The Bushman Hunting Tribe

Finally, this isn’t about reducing people. It’s a heuristic, a model, it cheats. It makes little boxes because it’s easier to think about boxes than it is people, and allows you more time to, ironically, think about people.

People can often play multiple roles on a team – they may prefer to be a Goat, but they are a reasonably good Fish. So if work changes and you need more Fish, you can coach them in that direction.

This corresponds to an archetypical theory that groups of males all tend to form the hunting tribe – the funny one, the smart one, the strong one and the leader. Likewise, teams that are lacking a Goat are going to naturally have people with Goat like tendencies shifting their work habits. So no one is stuck being a Goat, they may be happy doing multiple things. But often, a stream of work comes in, and it’s chewing grass (but not too close to the soil!) and guess what, you need a Goat.

What This Is

So… 2200 words or so in, we finally get to the system.

It asks two fundamental questions, and based on those answers, that’s where you get your categories.

What is valuable about code to you?

The first question takes what we do – we code – and asks what’s valuable in it. There are two answers here that I’ve seen. The first answer, and most common in my experience, is that code is valuable for what it does. This is the ‘as-a-means’ group. They write code primarily for what it does, for effect.

The second answer I’ve heard is that some people find code valuable without appeals to what it does. This is the ‘in-itself‘ group. They see code like any other means of human expression – and while you can certainly use literature to communicate, often literature isn’t having to justify itself to others.

Who is code valuable to?

This is the second dimension of our 4 part matrix. Both are questions about why a person codes and they ask the same question in different ways. The first asked why it was valuable as an activity, to begin with, the second clarifies valuable to whom? And yes, I used ‘whom’ right.

Unlike the first question, I usually see people evenly split on this answer. Some people believe that code is valuable for others. They write code so that others can enjoy it – either its effects or the code itself.

The second group tends to write code for themselves. They’re perfectly happy if others use it, but ultimately, they aren’t going to necessarily do something just to help someone else. They want to get something out of it too.

Everything’s a Continuum

Keep in mind, even though these questions tend to have two answers, most people are going to answer both answers, to varying degrees. No one isn’t at least somewhat happy when they see their work reused by others, and no one’s happy creating a system that does nothing either. We’re all ultimately coding for effect, for ourselves and others, and we also have opinions on the code itself.

The 4 Types

In traditional methodological style, I’ve given a hip and snazzy name to each quadrant of the matrix described above.

The Hacker

The Hacker wants to make features for people. Code, to her, is a means to an end. Ultimately she wants to see working features, and she wants to see them making people happy. This means they’re ultimately happy with things in their wheelhouse – do I know how to make this or fix this? If not, they’re willing to investigate. But too large of projects can exhaust them. They need that kick – they need to be able to say to someone – that thing that was bugging you? Yeah, I fixed it.

They love debugging and small problems that they can knock out in a day or so. They like racking up momentum, and moving things to the right on the kanban board. At times, they may be less than interested in new technologies or quality techniques like testing, unless these things can be sold and trained in such a way that it appeals to the hacker’s natural need to get shit out the door (for others), fast.

The Engineer

Contrasted with the Hacker is the Engineer. The engineer wants the code for its effects, they’re an ‘as-a-means-to‘ group just like the Hacker. But they’re primarily coding for themselves – they want to save themselves headaches later on down the line.

Engineers can take on large projects because they end up being methodical. They get a thrill out of being disciplined, following things step by step, and marking things off their list. They build the lists, methods, tools and everything else to make their own job easier. Changing requirements or design needs isn’t going to bother a Hacker, but it will bother an Engineer, because not sticking with their plan – which they put together – frustrates the hell out of them.

Engineers are happiest avoiding future work. They’ll test. They’ll peer review. They’ll have a disciplined coding style. They may or may not be sold on new technologies, depending on whether it makes their lives easier or more complex. They’re reasonably good debuggers due to their methodical nature, but they don’t really like doing it. The fact is, engineers don’t see debugging as helping someone else. They see it as fixing their mistakes. So it’s rough on their egos to have to do it.

The Artist

In the smaller half of the matrix, we have the two types of coders who value the code itself more than what it does. And in the quadrant of people who value code in itself, for others, is the Artist.

The artist wants elegance, she wants readability, she isn’t afraid of new features of complexity if they ultimately shrink the problem space into a more elegant one. She’s an expert in most new technology and libraries because code is for others. She’ll write code, intending for it to be read – even celebrated as good work. And she’ll read others code, including libraries, APIs, and other tools.

She’ll be great at emphasizing reuse – to the artist, coding is an intrinsically social activity. That means GitHub comments, it means peer reviews, it means design reviews, it means learning about other people’s projects and seeing if you can use them. It means sharing your own work with others.

Artists most want the respect of their peers, and they most want to make their peers happy with the code they produce. Artists, like the type below, Builders, may have a tendency to exhaust themselves trying to build the most elegant system. But unlike Builders, Artists are going to be unhappy on any team where they and their work isn’t valued by others. An artist who brings an open source library up in a meeting only to be shot down by someone else who’d rather build it in-house is going to believe they aren’t adding value.

Artists enjoy refactoring, collaborative design, and peer review.

The Builder

Because it’s there

George Mallory

Builders value code in itself, and they program ultimately for themselves. They see the problem that code solves as challenges to their own ability and talent to see if they can devise a solution. The solution to them isn’t merely – can it do the thing. That way lies hackers – no, the solution, to the builder – is everything. It’s doing the thing, and how you did it.

Ironically, while the Builder is happy to use off the shelf components in building their master system, if that off the shelf component solves a problem the builder finds ‘interesting’, they’re probably going to reimplement it themselves.

Builders can solve big problems. Compared to Engineers, builders may even solve big problems for which there’s no good solution. Big familiar projects are Engineer’s wheelhouse, while big unfamiliar projects are the Builders.

Builders will not shy away from scope or challenge. They can get bound up in it, and it’s something to worry about. And, unlike other developers who may get bound up and need help – the real challenge of a Builder getting bound up is no one can help them. If they’re stuck, you’re stuck. The project is stuck. They’re often going to be your best expert on a domain – that’s why they’re doing their work. And if they don’t know, you’re fucked. You’re stranded on Mount Everest.

Builder’s aren’t the biggest fans of debugging, as, like Engineers, they take bugs as a personal affront to their ability to solve the problem. But nearly every other activity they’re happy doing – design, testing, review – so long as they see a challenge in it. If it’s not interesting to them, they’re going to lose energy, fast.

Summary

Categorizing developers is tricky. Often, in the past, it’s done nothing but reinforce biases that keep our field predominantly white and male.

My categories are not that. They’re speculative – I may be wrong. But they’re also each bringing something to the party. They have strengths and weaknesses, they’re best in a team with other people. I’m not about hiring Elvis and being done with it. You have to hire them all – and more importantly, as they grow, you’ll definitely see their strengths and weaknesses grow.

Hackers, Engineers, Artists, and Builders – they all do the same thing, Code. But for different reasons, and for different people. Those reasons can help figure out what motivates someone to do their work, and help you tailor the workflow to them so that they get out of it what they want and they’re most productive.