Characterizing Software Engineering Work with Personas Based on Knowledge Worker Actions

I've been using learner personas to sharpen my conception of who I'm teaching for almost a decade, but until I read Ford2017 a few years ago it never occurred to me that (a) programmer personas would be just as valuable and (b) they could be empirically grounded in this way. Ford et al adapted a pre-existing taxonomy of knowledge workers' tasks to describe what programmers do, used interviews and surveys to find out how often programmers do them, and then clustered the results to come up with seven personas (all descriptions taken directly from the paper):

• Acantha, the Autonomist Acumen is known for her autonomy and keen abilities to make good judgments when writing code. Her long tenure as a software engineer has supported her decision making abilities. She spends the majority of her time writing code independently on personal projects and also spends a significant amount of time working on internal projects. On average, more than 20% of her time is spent in the Authoring knowledge worker action.
• Lilo, the Continuous Learner is known for her interest in learning and getting adapted to a new team early in her career. She spends, on average, more than 23% of her time in the Learning knowledge worker action. She takes a great interest in watching online lectures to brush up on the latest frameworks and technologies that she may be able to add to a new project. At this stage in her career she is often assigned tasks rather than choosing tasks to work on. Though she may be an entry-level engineer with little professional experience at the large company, she takes an initiative to get caught up quickly on team projects.
• Isabelle, the Investigator is best known for being the top investigator on her team. She spends the most time, over 30% on average, in the Analyzing knowledge worker action. She spends much time in the trenches of projects debugging and making sense of code. Isabelle recently changed from being one of the top experts on her team to being a novice in her new team. However, this has not impeded her success as she was able transition smoothly and adapt the same techniques of connecting with peer developers to ensure success on her new team.
• Cameron, the Communicator is considered to be a communicator because of her ability to distribute her time evenly and early in her career while securing the logistics of her work environment. She is able to spread her time across all knowledge worker actions well. However, since she is so early in her career she also seeks guidance from her program manager and others on how to approach tasks. Cameron spends a lot of time communicating about how to set up and approach her work through emails, meetings, reports, and presentations, but that sometimes gets in the way of writing code.
• Iman, the Interactive is known for her activity with collaborative code writing style but also for her dynamic level of interaction that goes on within her team in terms of the Co-authoring knowledge worker action. Aside from being very helpful in code reviews, much of her tasks to complete come from everyone else. On average, many of her tasks come from management questions, source code from other engineers, and also spontaneous conversations within her team.
• Ava, the Advisor is known for the high value she places on being helpful to others and giving feedback. On average, she spends over 20% of her time offering feedback. She has significantly more professional experience, identifies as an expert, and puts out more fires than others when her team is in need of an emergency product fix. Her professional experience shines through the most as she has more years at her large company than others. Her ability to put out fires and help the team in unplanned emergency situations demonstrates how often she gets interrupted while working.
• Ciara, the Team Coder embodies this idea of being a team coder for her immense amount of time in the Co-authoring knowledge worker action (sometimes over 40%). She spends a significant amount of time producing code for her large company with a team by her side. Her major tasks are to sift through bug reports and fix them with source code check-ins. Ciara does not spend a lot of time in emails, meetings, or presentations because she is busy testing bug fixes.

The authors don't claim that personas or the boundaries between them are fixed: for example, they point out that nobody starts as an expert and say that, "Participants…mentioned…having to switch between modes on a project. Some emphasized that it depends on what project has demanding deadlines at that particular time." Having these personas is still very useful as a way to help people think about why teams are and aren't working and how different individuals' careers might develop.