Wednesday, March 11, 2009

Programmer Personas

I came across an interesting (and short) paper by Microsoft user experience guru Steven Clarke called "What Is an End User Software Engineer?" It discusses the idea of programmer personas and how Microsoft has leveraged that concept to (re)design Visual Studio and various APIs for better usability.

A persona captures assumptions around work styles and motivations. Not all programmers are motivated by the same things or have the same goals. A sales engineer might have a different set of problems to solve than a senior developer in R&D, and might be accustomed to working in quite a different way. Yet both may have to code against the same libraries using the same tools. Is it possible to satisfy both groups of programmer-users? Are there API-design or tool-design best practices that apply across the board regardless of persona type? What do we know about the things that work for one programmer persona but not another?

The formulation of persona types is obviously somewhat arbitrary, but it's interesting that Microsoft did go to the trouble to observe programmers working not only in usability labs but in their "natural habitats" over a period of 12 months in order to arrive at three main personas:
  • 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.
Clarke discusses Microsoft's usability philosophy in greater detail in a 2005 Dr Dobbs Journal article that I think is still quite relevant today. Check it out when you get a chance.

For people in the tooling and API-design business, there's a lot to think about here. Ask yourself: Do you know what the personas of your users might be like? Are you taking that information into account in your API, SDK, and tool designs? Do you do serious usability testing of your APIs and development tools before putting them in the hands of customers? If not, why not?

Giving programmers usable tools, it seems to me, is the first step to making programmers more productive. And that benefits everyone.


  1. A very simplistic categorisation but interesting. If I had to apply it to myself I think I started off as OPPORTUNISTIC, moved through PRAGMATIC and have now progressed (perhaps a bit too far) towards SYSTEMATIC.

  2. I agree, the taxonomy is rather cursory. It totally misses my own category: THE LAZY DEVELOPER.

  3. Hi,
    I am Programmer with is absolutely FREE chess server where you can play chess,create your own tournament with players online. No Gambling and explicit talk. This website is purely meant to increase the fan-base of chess and for entertainment. I Need your help to promote the FREE chess server around the world. I would like to be on your blog as i found it a useful and informative resource. By adding you will recognized and added as a top resource on our chess server. I really believe in FREE flow of information. I have included the code and title.

    Please email me back with subject line of your URL for the featured resource code. This is to avoid spam and to make sure you get the award.

    I hope you understand and co-operate with us.

    Thank you,
    Sophie Vierra

  4. It will be useful for you to check this out before writing critical essay. I used it in college in order to get a high grade.


Add a comment. Registration required because trolls.