Background on Personas

I joined the Developer Division User Experience Group on January 13, 2003. At that time, the three, now famous Mort, Elvis and Einstein, personas had just been developed by the team. I benefited from the wealth of research the team had done with developers and had a shorthand way to quickly come up to speed about our developer audience. 

The first public reference I can find of the developer personas is “Who are you? Mort, Elvis or Einstein” on September 25, 2003. Unfortunately, the author describes the personas from his memory of reading the profiles “a long-time ago” and intuition. The characterizations are wrong, but it seems many people believed them.

Steven Clarke, a fellow researcher on the DevDiv Ux Team, has accurately and succinctly described the three personas:

Systematic programmers tend to follow a defensive coding style. They do not make assumptions about the code they are writing, the platform it runs on, the class libraries that they are using etc. For example, they do not assume that a class library will behave as advertised. Instead, systematic programmers will test the library in a safe environment, inspect the library source code etc before using it in a production environment. Systematic programmers desire programming languages and APIs that give them full control over the execution of their code and that do not hide important details from them, even if it means they have to write more code and take more time to understand how the code works. They value being able to get under the covers and tinker with components or even replace them.

Pragmatic programmers tend to be less defensive than systematic programmers. In many cases, they are comfortable trading off control for productivity as long as they are aware of the existence of the trade off. Rather than spend the time understanding the full working details of an API, they will prefer to learn as they go, building up an understanding of the API, programming language etc in the context of the work that they are doing. They value being able to get under the covers and tinker with components should they need to, but will prefer not having to do so.

Opportunistic programmers value productivity features in a language, API and IDE very highly, often higher than anything else. Unlike systematic programmers, they place less value on having complete control over their code, since for opportunistic programmers, the cost of control is added development time. They particularly value 3rd party controls and APIs that allow them to concentrate on the business problem that they are trying to solve, rather than on configuring the control or specialising the API so that it meets their requirements. They don't really value being able to get under the covers and tinker with components - they would rather look for some other API or control that met their needs instead of modifying controls or APIs that they already have.

Another summary of the three is:

THE SYSTEMATIC DEVELOPER: Writes code defensively. Does everything he or she can to protect code from unstable and untrustworthy processes running in parallel with their code. Develops a deep understanding of a technology before using it. Prides himself or herself on building elegant solutions.

THE PRAGMATIC DEVELOPER: Writes code methodically. Develops sufficient understanding of a technology to enable competent use of it. Prides himself or herself on building robust applications.

THE OPPORTUNISTIC DEVELOPER: Writes code in an exploratory fashion. Develops a sufficient understanding of a technology to understand how it can solve a business problem. Prides himself/herself on solving business problems.

The first thing that should be noted is that the names don’t really matter and that there's no reference to programming language.  While each of these corresponds to a name, it’s really about the work styles and behaviors of the developer.  The names are just shorthand to make communication easy.  However, the shorthand can’t be used if everyone isn’t on the same page about the work style.  The second thing to note is these are not full descriptions of the personas. There is a lot more to them than these quick summaries.

Over the years, there has been a lot of controversy over these three personas. I speculate that one of the main reasons is that people don't fully understand the personas and the depth that is available about each one. They just get this quick snapshot, hear a few things from others, and form a weird and inaccurate view of each persona.  However, it’s interesting to see it unfold in blogs and the media. It's even more interesting that  these personas are so famous they even have their own Wikipedia page. Who knew that an internal tool would be so powerful (and so misunderstood) outside the Microsoft walls?

The Power of a Name

While I stated above that names don't really matter, it's sort of a lie. The names are meant to be memorable and offer a way to talk about developers in a personal way. The developer personas are some of the few widely known personas across Microsoft... because of the names. Even if people in other divisions don't know what work styles they stand for, they do remember Mort, Elvis and Einstein and bring them up. I haven't seen any other name stick like these. As a little quiz, do you know who Abby, Ichiro, Frank, Anna and Miles are? What groups use them and who do they represent? 

Although there is controversy around personas; if used correctly, they still remain a very powerful tool.


Evolution of Personas

While we still have our three famous developer personas described above, we also have additional personas.  Ellen is an example of the first persona added after the famous three and we dub her the “vigilant tester”. In fact, we have 19 different personas in use in the Developer Division today.

Another big change that has happened with our persona work is how we have expanded our thinking. Our drive is now what “People in Context” are doing. As many observers have noted over the years, depending on the context in which they are working, they may have a very different work style. While this is hinted at all over the place in the blogosphere, there’s no reference to how this applies to personas directly and how we use it to design products. "People in Context" does just that.

“People in Context” gets more complicated than just the old personas, so I’m going to spend the next few blog posts breaking it down.


Interesting reading on our Developer Personas:

Climate change and developer personas by Steven Clarke

Making effective use of personas in design by Steven Clarke

Why profile users and not tasks? By Steven Clarke

Ellen by David Williamson

Applying personas by Nikhil Kothari