Help me to be productive

One of the aims of great developer experience(DX) is to increase the productivity of the consuming developers. Great and clear design and process increases the productivity of API builders (internal DX). I’ve touched the productivity topic already in the beginning of the 100 Days DX series in post 2 “I have a productive day when…” and I’m not going to repeat the topics in there. Instead I will discuss the perceptions of productivity. Often the view is management point of view, but this time I took the developer point of view.

According to fresh research results (2017) based on survey (N=413) perceptions of the productivity can be grouped to 6 distinct groups. As it has been discussed before, developers are not a homogenious group, but instead they vary a lot. This is supported also by the mentioned research. Why this matters? When you are crafting the initial developer personas, you should be familiar with the ways of working of your target group.

In-depth understanding

I’ve said it a thousand times, but you really need to go deep with understanding the developers’ life. If you just rely on superficial data easy to grasp, you get superficial personas. Devil is in the details and you need to feel empathy towards the developers. Empathy requires in depth knowledge of the subject and then you can craft better fitting solutions for them. You need depth in the understanding. If your past is not in code level development, it will take time.

Now, lets look at the groups. Note that even if developer might fit into one of the described types today, the situation might be different next week even if we speak of the same developer. Some tasks require adoption of certain approach in longer projects.

The social developers

The social developers feel productive when helping coworkers, collaborating and doing code reviews. To get things done, they come early to work or work late and try to focus on a single task.

I see that this type developers most likely are fond of pair programming too. They need people around them to feel comfortable. They are most likely active in the online groups and services as well. They are probably inclined to ask a peer first if they bump into problems. They also most likely forgiving if your documentation contains some small holes and inconsistencies, because they can always rely on their peers.

The lone developers

The lone developers avoid disruptions such as noise, email, meetings, and code reviews. They feel most productive when they have little to no social interactions and when they can work on solving problems, fixing bugs or coding features in quiet and without interruptions. To reflect about work, they are mostly interested in knowing the frequency and duration of interruptions they encountered.

The lone developers naturally need the most your API Docs and other supportive material. They expect their answers to be answered without interaction with people. This is prrobably the stereotype user of all develeoper portal developers. No interaction needed with humans, all needed info found easily and clearly written format, tools and libraries are documented and easy to use, registration is self-service. All this developer needs is your developer portal, cave in the basement and enough internet bandwidth (and some Club Mate/coffee/tea). Or then the developer is on the beach under an umbrella. You never know.

I would expect these developers to be the most ruthless towards your service if the available information to be inaccurate or flawed. Reason is clear, it’s stopping them frrom being productive.

The focused developers

The focused developers feel most productive when they are working efficiently and concentrated on a single task at a time. They are feeling unproductive when they are wasting time and spend too much time on a task, because they are stuck or working slowly. They are interested in knowing the number of interruptions and focused time.

I would label these developers as the “max performance” seekers. You as a API provider can irritate these developers pretty easily. If they need to read lines after lines of documentation before getting to the point, they are wasting time == not productive. You need to provide code examples after code examples to offer half-ready materrial to use. They need to find (search) the solution to their problem fast and easily. Your search engine is key performance factor here.

The balanced developers

The balanced developers are less affected by disruptions. They are less likely to come early to work or work late. They are feeling unproductive, when tasks are unclear or irrelevant, they are unfamiliar with a task, or when tasks are causing overhead.

These developers are like the stereotypical 9-5 workers. They are like japanesee trains. Reliable, steady, factory-alike performers. They are the workhorses (as a crowd) for you. They expect all to bee clear when they develop the solution.

The leading developers

The leading developers are more comfortable with meetings and emails and feel less productive with coding activities than other developers. They feel more productive in the afternoon and when they can write and design things. They don’t like broken builds and blocking tasks, preventing them (or the team) from doing productive work.

These developers most likely evaluate your service and APIs before they are given to other developers. They are making recommentations for the management and thus key persons in making decisions on which APIs to use. They are not evaluating only your product but your company as well. They most likely seek out what other developers have said about your APIs and service. At this point we might be referring more to product experience than pure developer experience which is included the previous.

So, who are you serving?

In the above is 6 types of developers most likely looking at your APIs and service. How do you serve them and which of them? Of course the above are all stereotypes and in real life the approaches and types are mixed.

Some more to read from 100 Days DX