November 29, 2007
Earlier this week I wrote about The Two Types of Programmers. Based on the huge number of comments, it seemed to strike a nerve. Or two. This surprised me, because it was never meant to be the inflammatory, provocative diatribe that many people interpreted it as. It got so out of hand that Ben Collins-Sussman, the original author of the post I quoted, was driven to post a followup clarifiying his original post.
Many of the commenters were offended that I somehow lumped them into a vast unwashed eighty-percent sea of vocational programmers. Here's what's particularly ironic: the very act of commenting on an article about software development automatically means you're not a vocational eighty-percenter. Trust me. I absolutely was not calling any of my readers inadequate. I don't say that because I'm a world class suckup; my blog isn't some kind of special case or even particularly good. I say it because if you're reading any programming blog whatsoever, you're demonstrated a willingness to improve your skills and learn more about your chosen profession.
Thus, if you read the article, you are most assuredly in the twenty percent category. The other eighty percent are not actively thinking about the craft of software development. They would never find that piece, much less read it. They simply don't read programming blogs-- other than as the result of web searches to find quick-fix answers to a specific problem they're having. Nor have they read any of the books in my recommended reading list. The defining characteristic of the vast majority of these so-called "vocational" programmers is that they are unreachable. It doesn't matter what you, I or anyone else writes here-- they'll never see it.
The problem isn't the other 80%. The problem is that we're stuck inside our own insular little 20% world, and we forget that there's a very large group of programmers we have almost no influence over. Very little we do will make any difference outside our relatively small group. The problem, as I obviously failed to make clear in the post, is figuring out how to reach the unreachable. That's how you make lasting and permanent changes in the craft of software development. Not by catering to the elite-- these people take care of themselves-- but by reaching out to the majority of everyday programmers.
That was my point. I'm sorry I did such a bad job of communicating it. But on the plus side, at least it got people thinking and talking about the issue.
Some people objected to the very idea of categorizing programmers into groups of any kind. But there's a rich history of doing exactly that, with interesting and sometimes unintended consequences. In early 2004, Nikhil Kothari wrote about three personas Microsoft came up with while working on Visual Studio 2005.
We have three primary personas across the developer division: Mort, Elvis and Einstein.
Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems. He focuses on productivity and learns as needed.
Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learning while working on the solution.
Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem, and typically learn in advance before working on the solution.
These personas helped guide the design of features during the Visual Studio 2005 product cycle.
The description above is only a rough summarization of several characteristics collected and documented by our usability folks. During the meeting, a program manager on our team applied these personas in the context of server controls rather well:
- Mort would be a developer most comfortable and satisfied if the control could be used as-is and it just worked.
- Elvis would like to able to customize the control to get the desired behavior through properties and code, or be willing to wire up multiple controls together.
- Einstein would love to be able to deeply understand the control implementation, and want to be able to extend it to give it different behavior, or go so far as to re-implement it.
I can't quite date exactly when these personas came to exist at Microsoft. Wesner Moise has an even earlier reference to these personas, wherein he amusingly refers to himself as "used to be an Einstein." Wes, old buddy, I'm afraid you're the archetypal Einstein, no matter how much you might think otherwise.
These personas have been controversial for years; they've sparked a lot of intense discussion. Evidently there's a fine line between "persona" and "stereotype":
The Microsoft developer personas that include Mort, Elvis, and Einstein are ultimately an ethically bankrupt mechanism to pigeonhole software developers into the kind of overly simplified categories that a typical marketing staffer is comfortable with. While intended to help this particular parasitic segment of the corporate world to behaviorally model the psychological predispositions of software developers at their work in an unrealistically simple way, it has instead turned into a system of limitations that developers have begun to impose upon themselves to the detriment of the advancement of software development practice and industry. It appears to be a bid by developers to rid themselves of the capacity for rational thought in favor of tribal identification with corporate brands and software rock stars.
Personas, in and of themselves, are not a bad thing. I've written before about the importance of API usability, and personas let you get a leg up on usability by considering the different audiences that will be using your code.
But I can empathize. As a long time Visual Basic and VB.NET developer by trade, I truly resented being lumped in with Mort. I'm not just some clock-punching code monkey-- I actually care about the craft of software development. So what if I happen to write code in a language that doesn't brutalize me with case sensitivity and curly-bracket megalomania? My language choice is ultimately no more meaningful than the choice between caffeinated cola beverages, so it's an illusory difference at that.
Paul Vick works on the VB language team at Microsoft and he echoes some of my concerns:
The fundamental error I think most people make with the personas is that they see them as mutually exclusive rather than points along the experience spectrum. When I'm working on the VB compiler, I'm definitely an Einstein, thinking at a very high level. When I'm working on stuff like the VBParser sample, I'm generally an Elvis, thinking at a somewhat lower level. And when I'm writing batch scripts or ad-hoc data analysis tools, I'm definitely a Mort, hacking around to figure out what I'm trying to do.
The point really is that most people are usually Mort, Elvis and Einstein all at the same time, depending on what they're doing. And by building tools that target one or the other, we're artificially segregating people's work into buckets that don't really map onto their daily lives. (I would also argue that the past several releases of Visual Studio has emphasized some personas over others.) Finding a way to better serve people as they move through the flow of the day-to-day work is something that is need of some serious attention.
Mort, like the twenty percent analogy Ben originally came up with, is more than a persona or a stereotype. It's a call to action.
I think the solution is to quit pandering to Mort with our condescending paternalistic attitude, and instead demand better from Mort. If the capabilities of the average developer truly is as bleak as many make it out to be, we shouldn't just accept it, but work to raise the quality of the average developer. "Average developer" should describe an acceptable level of competence.
We have to realize that Mort is responsible for a lot of important systems. Systems that affect the general population. When I hear of recent cases of identity thefts at Choicepoint, especially those caused by lax security such as using default passwords for the database, I think of Mort. When I read that $250 million worth of taxpayer money has gone into an overhaul of the FBI Case File system, and the system has to be scrapped, I think of Mort.
Given this much responsibility, we should expect more from Mort. So Mort, I hate to say this, but software development is not like working the register at McDonalds where putting in your 9 to 5 is enough. I am all for work-life balance, but you have to understand that software development is an incredibly challenging field, requiring intense concentration and strong mental faculty. It's time for you to attend a conference or two to improve your skills. It's time for you to subscribe to a few blogs and read a few more books. But read deeper books than How to program the VCR in 21 days. For example, read a book on Design Patterns or Refactoring. Mort, I am afraid it's time for you to quit coasting. It's time for you to step it up a notch.
I firmly believe it is our job to leave the craft of software development better than we found it. If you're anything like me, you wrote horrible code when you started out as a fledgling programmer, too. But through concerted effort and practice, I was determined to suck less every year. I'll admit this is sort of painful, because us programmers aren't exactly known for our people skills. But we owe it to our craft-- and to ourselves-- to reach out and help our fellow programmers, at least in some small way.
Being a professional programmer is more than just writing great code. Being a professional programmer means helping other programmers become professionals, too. We're all in this thing together. Not everyone can be reached. But some can.
Posted by Jeff Atwood
I must confess that I found the part about the three personas inaccurate and rather uncomfortable to read; no man is one thing. On Monday you're an Einstein, on Tuesday you're a Mort... you cannot (entirely) reliably or accurately classify people and especially software developers. We are fickle creatures :P. Therefore I defiantly refuse to be labeled.
I don't buy into this "3 persona" classification scheme, but I do agree that the vast majority of software developers out there are content with forgetting all about software development once they step out the office. That is just the way things work. You can't force people to take more interest in software development.
Perhaps the best approach in trying to help the "80%" is to offer people the chance to improve their skills, and let them decide if they want to take it.
Above all, we should all remember (by "all" I mean software developers) that between the colors black and white there is an infinite number of shades of gray.
Really, it isn't about the personas - they are good for giving people a laugh, or scaring people into action for a little while when they discover they find they are a persona they don't want to be.
I think what it all really comes down to is advice that Bob Martin gave me and the company I work for when he was here giving us some training (of which I am grateful for and that the company I worked for payed for it)
Be a professional. This means take pride in your work and always be learning. Think of a doctor. We don't want our doctor's to stop reading and leaning. There is always something new to know. It should be the same for programmers. The problem is that we have come to be perceived as simple cogs. So we need to change that: be a professional, and by being a professional others will emulate you, and slowly the field will become a respected profession, not just a field of employees.
And once that is done, the personas will fade away.
I've blogged about this; you can find it here: http://my.opera.com/alex_boly/blog/2007/12/04/ranting-types-of-software-developers.
To put it briefly:
- the Microsoft model is broken because it doesn't encourage every programmer to learn more about what is happening under the hood; it just gives the impression that programming is easy
- I have a hunch that if we analyze the way the 80% got so many, we will find out that they worked with tools promoting the idea that programming should be easy.
- There is only one situation I can think of where the 80% programmers are better for business: when the company is not selling software but man-hours. In this case, the profits scale with the numbers.
I had to stop, because I got really tired writing about it ;-). It's a difficult subject, but one that is important for us all.
Joel Spolsky held a speech at Yale about software development (see http://www.joelonsoftware.com/items/2007/12/03.html).
I like what he says about one of the lectures he took on programming, and it is related to our discussion:
"The best thing about CS323 is it teaches a lot of people that they just ain’t never gonna be programmers. This is a good thing. People that don’t have the benefit of Stan teaching them that they can’t be programmers have miserable careers cutting and pasting a lot of Java."
This completes my point above ;-).
Yup, I got Mortitis, I swear to the humble programmer gods that be that I want to produce the best code ever. I muck around in VBA, basically created my own job, converting to VSTO. And going to school full time for a BSIT. I read this religiously, and even pay attention to some of the comments, until a bunch of folks decide they want to be offened by an unoffensive post. It is well known that there is a 20% 80% split in almost any industry. I did 10 years military service and 20% were warriors, 80% just wanted a paycheck in a peacetime service enviroment. The 20% did 80% of the work, and fixed a nearly broken service from the inside out. So if you belong to the 80 you weren't here, if you were in the 20 you got awfully annoyed at nothing.
I didn't find the post offensive or controversial. On the contrary, I quite often find myself coming across people who, having not succeeded in some other field, jump into programming and do a bad job at it. In that respect, reading the previous post was more of a bitter experience.
However, I found the whole discussion and this follow-up quite stimulating and refreshing. It reminded me of the eternal duty we have to leave things better than you find them.
Good follow-up Jeff, though I personally think it wasn't needed. I knew what you were trying to say the first time around. :)
I find that every morning I wake up and go to work believing what you mentioned in your closing statement, that "not everyone can be reached. But some can." However I only come home from work still carrying that attitude maybe 2 or 3 days out of the week. Perhaps that's why I'm becoming more selfish and spending less time blogging/sharing/presenting and more time researching, building and playing. Perhaps if I tried to blog in the mornings, rather than the evenings I would find it easier to write and share.
Hey all of you..... I am just a student bearly a 20percenter but i am improving day by day as you people coment so keep up the good work :)
Really good. And very true.
"Thus, if you read the article, you are most assuredly in the twenty percent category."
This is going up on my wall next to last year's Time cover where they named me man of the year.
Maybe I've just been extremely lucky, but I haven't met many developers that I'd put into the 80% bracket. Could it be that there are less than 80%? Maybe the numbers are even reversed? Thing is, I think most people want to do a good job. They might only work 9 to 5, but while they're working they want to do the best they can, especially in this field. Hell, you've got to be a geek to want to be a programmer, so you're going to want to do a good job, right?
And Jeff, sorry about this, but if you're serious about reaching out to the masses then you can't suddenly jump onto your high horse about VB and VB.NET. Yes, the C languages force case-sensitivity on you and you have to use curly braces (god forbid), but VB forces you to use bizarre words like Sub and End Sub (how do you tell where a block begins and ends at a glance?).
I normally enjoy reading your blog, here's hoping that this is the last of this rant.
hmm, so I am a 20% type. And as well, I am an Elvis type. hmm.
I don't quite see myself in that 20% group, but if the definition says I am then I guess I have to accept the fact and try to become an evangelist to the unconverted :)
Richard (who loves MS Access!!!)
Thanks for another great post Jeff, I've only recently stumbled upon your blog but I've devoured nearly 2 years of posts in the last few days. I'm thoroughly in the same camp as far as developer personalities goes; the 80%-20% split seems pretty fair to me, perhaps even a little generous (towards the 80%). I think you did a pretty magnanimous job of explaining what the difference is, and why it's not a bad thing.
I agree that software development, in my limited experience at least, has a larger percentage of genuinely-excited people than your average profession, and we *need* all types of personalities, not just the bit-breathing kernel hackers and compiler writers, to make the software economy run. The key to getting your point across on a delicate matter like this is to choose words carefully, and be very clear that the discussion is about diversity, and why it's a *good thing*, and not elitism.
As my favorite spin on/use of the original Einstein/Elvis/Mort paradigm, I've linked to this post from my latest blog entry about making effective technical presentations at:
The post is entitled "How To Become the Illegitimate Lovechild of Don King and Steve Jobs (In 3 Easy Steps)." Keep up the good work!
Great post Jeff, I agree with it.
I do agree that depending on the particular job at hand, an Eintein can switch into "Elvis", or even "Mort" mode as needed.
And I also agree to the fact that a Mort will not switch into "Elvis" or "Einstein" regardless of the work at hand.
But the problem is not technological, is the attitude to better yourself. And that is what the 20% needs to address.
With the most humble of opinions I offer this comment...
I think this article is a perfect illustration of why IT is viewed as a cost center vs. a profit center in any company.
The purpose of IT is to facilitate business vs. tell the business to change the way you do things.
The problem with the 20%'ers is that they do not and continuously fail to understand this basic concept.
I think ...I am an Elvis who is also a Mort with flashes of Einstein.
I guess what I am trying to say is that every type of a programmer has a virtue but most assuredly the Einstein’s have no virtue in the real world. Let’s leave the Einstein’s to Microsoft’s and Oracles of the world.
Just because it can be done does not mean it should be done.
I will give you a real life example: We were tasked to develop a system that creates a help desk ticket and that system should have the capability to go assign tickets to various inboxes and the manger can see all the tickets have to go through a work flow process.
Well, the dude / dudette ( that’s what I will call the programmer ) decided to build everything from scratch i.e. a system which has classes called inboxes, classes call called inbox assigned and so on..and just to top it off the dude goes and pings the network to see if an inbox has received any new tickets etc.
Well, my question about hey what about Moss..was met with the strongest of objections simply because the dude wanted to implement Domain Driven design.
At least in the Mort / Elvis and most certainly not an Einstein’s opinion a classic case of it should not be done simply because it can.
That being said the last line of this article was absolutely beautiful…leave the craft of software development better than we found it. Might I also add that if I have 1 more byte of knowledge about anything today then I did yesterday I consider it a successful day.
Jungian psychometrics is a lot better than these layman-conjured personas. Mort would likely coincide with ISTJ, Elvis with INTJ, and Einstein with INTP (Einstein was himself an INTP.)
You will find NT's (especially INT's) largely in the 20%. These are iNtuitive (abstract) and Thinking (thought-centric,) collectively called the Rationals. ISTJ and other types likely fall in the 80%. They are Sensing (concrete) and so programs are more likely to be lines of text on a screen to them than structures in their mind. They manage because they are aided by their Thinking, but again that thinking is more likely to be about what's on the screen than what's in their mind. You cannot exactly blame them for being who they are, and consider that they are no more deficient than you are superfluous. Could they have chosen a better vocation? Probably.
They are not beyond help, as long as we realize that what we mean by help is our own definition and not theirs. They probably are, as you say, unreachable. But there are things that are loud. Things like money, jobs, and bosses. And maybe coworkers.
(the four temperaments)
As my favorite spin on/use of the original Einstein/Elvis/Mort paradigm, I've linked to this post from my latest blog entry about making effective technical presentations at:
The post is entitled "How To Become the Illegitimate Lovechild of Don King and Steve Jobs (In 3 Easy Steps)." Keep up the good work!
Excellent article, Jeff... and one which I couldn't resist doing a rewrite of:
I only hope my fellow trans-brothers and sisters take it in good spirits... just having a little fun. :)
Oops. Never mind.
Essentially, the joke substituted the abbreviations CD, TG, and TS for Mort, Elvis, and Einstein, making the article mirror an unspoken elitist attitude at the fringes of our community. It's an amusing parallel if you happen to be a transgendered coder with a healthy self-deprecating wit. BUT, taken literally, it doesn't go over well.
Remind me not to tell religious jokes while I'm in church. Some of these people are actually here to pray! D'oh!
From the formatting of this post it looks like Phil Haack's call to 'reform Mort' is a continuation of Paul Vick's blog post on the subtlies of the issue.
the very act of commenting on an article about software development automatically means you're not a vocational eighty-percenter.
Then why was 'commenting on software blogs' not part of your original definition. Now you're just making shit up to cover your arse.
RE: I firmly believe it is our job to leave the craft of software development better than we found it.
I definitely agree with that.
I got good grades at uni, but I've never been happy with my production code since entering the workplace. Over 4 years after I graduated I've finally started reading the GoF's Desgin Patterns. I haven't even finished the second chapter and I already wish the guys who originally developed the software I'm currently maintaining had read as much. I plan to read Refactoring next year after I finish my Youth Ministry evening classes. That's actually a coincidence. I've been wanting to improve as a youth worker in my church and I've been wanting to improve my code for the last couple of years and I've finally got round to doing something about it. Perhaps someone should write 'Purpose Driven Software Development'.
As for Mort, Elvis and Einstein, I like to think I'm an Elvis (and I wish I could do Winamp AVS presets like El-vis), but I want to be able to work more like Mort, but in a good way. e.g. I know HTML and I know how to ftp from the command line, but I'd rather use blogger. Plus, fogbugz isn't completely for Morts, but it was one of Joel Spolsky's design goals to make it easier to use than Notepad.
I've found that differences between the two groups is as minor as differences between human and monkeys. Actually less because a good mentor can coach/mentor/brainwash/whip the rest into over-performing. Main problem seems to be that most engineers just don't understand that human brain is too dumb to use as-is. Training the mind to make up for shortcomings (mold) then cutting up the problems to manageable sizes (fold) is what engineering all about IMHO. Emotional problems are much harder to fix though. So far, I've had zero success in pulling one out of his/her own world of misery.
The majority of programmers are just rats on a wheel waiting for the next piece of cheese. I've spent quite of few years in the industry and it still amazes me how quickly things change day by day.
You spend all this time constantly keeping up and what has it brought you? Just another new technology, object model, new syntax to learn. That's why young people are the best programmers, because they haven't gone through the cycle. Once you have taken a few spins on the technology wheel, you are not so ambitious anymore, just wiser.
So, the ability to adapt is a great strength of any programmer.
It is difficult to classify programmers because *anyone* can become a programmer. You don't need any formal training. A few books and a compiler and you are on your way. Should those people be looked down upon because they do not have any formal training? They need a paycheck too.
So, in the end whether your writing a compiler or writing HTML, you are just a programmer. Stop looking for the perfect code, because there is no such thing as perfect code. Code is code, humans judge, machine don't. Compile and unit test, and fix those bugs and hopefully everything works out in the end.
I think you need an entirely new classification for Wesner Moise.
Here's light years ahead of any developer I've ever seen.
If design is bad, designer failed.
A programmer is not a developer. He is just a programmer. The people who mastermind the requirements and the purpose of the software are the developers. So we should never ask a programmer to develop our software. We should only ask him to program it.
Software engineering should not be a craft but an industry. Industry is more efficient than crafting. If you like crafting more than industry, welcome to year 1700.
People are not encouraged to be Morts though they should be. Instead you are left alone to cope with things, because of the lack of good organizational structure. Therefore you need your best einsteinical skills to survive in an environment of half chaos. But instead of that, people should be encouraged to be Morts, even helped to be Morts. Not weak Morts, but powerful Morts. When you have streamlined processes, your Mort is more efficient than 10 Einsteins in a crap company.
Software engineering tools should support all the aspects of software engineering. But the tools should also divide the aspects so, that it is easy to distinguish what functions belong to which aspect.
A programmer should not have all the functions of software engineering tool in front of him - only the functions that are required to program the software. Likewise, a designer should see only the functions that are needed to design the software. And what comes to creating a good architecture for software, the software engineering tools should again display only the aspect of software architecture.
If I am a programmer and start a SET, I don't want to see myriad possibilities from all of the fields of the industry. I just want to do my job as a programmer. But if I am an architect, I want to really see what goes into that aspect. If I am an architect, I don't want to just open an plain old IDE an start coding.
But asked more concretely: Who creates for example new graphical user interface widgets? The programmer, designer, architect, Mort, Elvis, or Einstein? The answer is that all of them make their own share of the job. The architect creates the overall frameworks for creating new widgets, the designer designs the widgets, and finally the programmer programs the widget. Then the Mort uses the widget for lots of simple applications, the Elvis uses the Widget for many complex applications, and the Einstein uses the widget for some scientifical applications.
There are Morts, Elvises, and Einsteins at all levels of software engineering. Still the engineering process should be as simple as possible, but not simpler, plus the process should take into account and divide all the aspects of the field. The simplicity draws the process towards Morts while creating new room for all of us to think more like Einstein.
Right on Jeff.
It's sad that "The Two Types Of Programmers" was seen as a partitioning function, but it highlights that improving our craft requires focus both on technical AND on social aspects.
Find mentors that awe you and keep you passionate. Strive to be the best peers we can be, and perhaps others will see us as mentors.
Whatever percentile you belong to, engage each other as a community. Only collectively can we drag our monkey-brains further into the technologies that will make our lives better.
if your an 80%er, it doesnt mean you a bad programmer, just as if you are a 20% doesn't mean that you happen to be good.
I consider myself a 20%, and always have been one. From the very day my parents bought me a VIC20 for christmas, I was a 20%er by taking time to read the "intro to basic" book, and then getting the Byte programming magazines (blogs wern't around in that day!).... Could I code then?....hell no!- I didn't know my 'for-loops' from my subroutines, and could hardly write code to count to 10!.....But, though, I wanted to learn. Not because someone would pay me more, or because my job depended on it, but simply.....because!... this, I think, puts me in the 20% category!
So, I guess, if you're a 20%, you've probably been a 20% from day one..... Ironically, I can see myself eventually going over to the 80% side, and let younger people with fresher minds dictate the way, when, simply, I CBA to learn anymore, and more important things, like Family, start to take my passions!
"maybe we should roll programming back a thousand years.." - Jeff
I don't have a budget for training new software developers, but of course someone has to show the newcomer the tools and processes that are in use in the company. If the newcomer keeps asking more advice and help, that is kind of being mentored. The newcomer could also be on lower salary the first few months and that time he should learn from the others and do simpler tasks.
Then software auditing sessions are a good way to check how the newcomer is doing. And auditing sessions don't cease after the apprentice becomes more skilled. Engineering practises should be so easy, that the newcomers can get into them without starting to farm wierd solo tricks.
It helps if you have skilled friends, but it is not the most efficient way to try find some friends and use work time bribing them to reveal any tricks.
Today people can read stuff from books, web, and earlier pieces of software code, so you don't need a mentor showing you things all the time. But I would say, that a company needs some kind of expertise management scheme, where people don't just play hero and do what tricks they find amusing. Everything needs to be under control.
Plain old mentoring is not even good enough, because you cannot trust that expertise flows from person to person - or at least doesn't flow in a orderly and standard quality fashion.
We can use some mentoring. But we don't go 1000 years back in time, because then we would loose being an _industry_.