Many organizations may mistake the versatility of software engineers as universal skills they all have. However, there is no one-size-fits all solution for software engineers. Basically, let’s not match software engineers with descriptions but use practical knowledge of the work they are doing to describe the many roles software engineers can take on.
To clarify how software engineers vary, we adapted Reinhardt’s knowledge worker actions to what software engineers do.
What is a knowledge worker anyway?
According to Reinhardt….
Knowledge workers have high degrees of expertise, education, or experience, and the primary purpose of their jobs involves the creation, distribution, or application of knowledge.
But for the purposes of our work let’s just simplify it to mean people who think for a living, also known as golden-collar workers. In addition, software engineering in one of the many careers that require workers to use their creative abilities to solve a problem.
Conducted Interviews + Surveys
We wanted to make sure our questions about how knowledge workers use their time was appropriately fitted for software engineers. To ensure this, we rephrased knowledge worker actions to be in the context of software development, such as the Feedback knowledge worker action now specifically referring to examples such as code review and architecture reviews.
We then interviewed 21 software engineers and received survey responses from another 868 software engineers to figure out a day in the life would look like. More specifically, we asked them what a typical day would look like for them in terms of hours, who they collaborate with, to what extent, their inputs/ outputs, and perceptions of autonomy on tasks.
Analysis
We then coded interview responses about task execution and analyzed survey responses starting with hours spent. Specifically, we performed k-means clustering on how many hours they spent performing Software Engineering knowledge worker actions in a day. Using the resulting 7 clusters, shown in the figure below, we identified significant differences between clusters based on how the software engineers described their work.
Member checking. We performed member checking by following up with interview participants about their specific time spent to determine how they align with the defined personas. We were able to group all software engineers into one of our determined personas.
Interesting Findings
Collaboration Styles. In brief, we found an interesting connection between how software engineers spent their time collaborating both within and outside their teams with other roles, performing code review, and being active participants in meetings.
Personas. We reviewed our cluster and cluster descriptions and inferred 7 personas of software engineers. You can find the described persona and a brief quote from a corresponding participant.
Acantha, the Autonomist Acumen ← Cluster 1
Acantha is known for her autonomy and keen abilities to make good judgments when writing code. On average, more than 20% of her time is spent in the Authoring knowledge worker action.
You know, I’m very much a risk-taker and I’d much rather ask for forgiveness. I’d much rather cross the line and wait for somebody to catch me. I’m willing to cross the line, and I do, and occasionally I get my hand slapped. I’m in this wonderful position.
Lilo, the Continuous Learner ← Cluster 2
Lilo 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.
I mean it’s usually scoped but we don’t know the A, B, C’s of it, like where to start, how to start and any such things. But it usually starts with talking to different people. We know at least one contact who would then redirect us to multiple other contacts or they redirect us to some other people.
Isabelle, the Investigator ← Cluster 3
Isabelle 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.
It depends on what kind of task. For example, to fix bugs in theory you need to reproduce the problem and to just do a debug step-by-step, going into the very developed source code to figure it out. That takes a long, long time sometimes.
Cameron, the Communicator ← Cluster 4
Cameron 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.
The concentrated work time usually involves coding. Right now it involves learning, collating documentation, arranging resources for the people who are gonna come after me.
Iman, the Interactive ← Cluster 5
Iman 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.
So we do all the code review ourselves – that’s a very important part. [Another] is the stand-ups, which have to be done – not every day, but twice in a week, we have meetings. And that’s very important because as we are still in a preview tool, so we have a lot of discussions
Ava, the Advisor ← Cluster 6
Ava 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.
That’s where people have an actual coding problem and they don’t know what to do to proceed, and you’re trying to give them advice or “here’s an example of code you can follow,” or “go read this article.” You’re kind of trying to hand them enough information so they can go solve the problem.
Ciara, the Team Coder ← Cluster 7
Ciara 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.
My role, in particular, has three things that we focus on. One is basically our automated test runs. This helps us keep the business running. Basically, when the service team deploys changes or updates stuff or new content comes in, we have a suite of tests that run four times a day. So a lot of times something might roll out and because they’re the service team, they don’t really do as much robust testing from the client-side.
What do we gain from this?
Inclusion through persona use. With our determined personas, software practitioners and researchers now have a resource to reference when encouraging a broader thinking of who users are. This can, in turn, encourage practitioners to be more inclusive of the many types of users.
Transient Modes. Software engineers may in fact transition through personas. We now have support for how to document that transition through hours spent. In the future, it may be interesting to conduct a longitudinal study that captures these transient modes based on types of projects developers work on.
Interested in the details?
I did this work as part of a summer internship in 2016! The research paper, Characterizing Software Engineering Work with Personas based on Knowledge Worker Actions by Denae Ford, Thomas Zimmermann, Christian Bird, and Nachi Nagappan was recently accepted at ESEM, ACM/IEEE 11th International Symposium on Empirical Software Engineering and Measurement. This year’s symposium will take place in Toronto, Canada on November 9-10, 2017. A preprint of the paper is now available online.
As always, comment (or email us) to let us know what you think about the work!
fordable 