You have heard dozens of times presentations telling you that great developer experience is this and that, you’ve seeen the same almost identical list of tools, documents and other so many times. And you just take it “Yes sir! If you say so”. They don’t tell you what is developer experience. They tell you what kinf of tools might satisfy the needs of the developers.

Furthermore, more often they are selling you something and you have no understanding what is it for since you don't have a glue what is developer experience.

What you should have asked is what is the foundation of all your claims? The foundation is in the academic research, but for some parts also in experience. You should be interested to make your own judgements what is good developer experience and not just copycat what someone else has done. That’s why you need to read more, you need to think more before actions.

Second approach to Developer eXperience

For long I had the impression that the only DX definition in academic literature was the one described in “Software developer experience: Case studies in lean-agile and open-source environments” (dissertation) by Fagerholm (discussed in post #1). After browsing again Researchgate I bumped into Kuusinen’s paper “Are Software Developers Just Users of Development Tools? Assessing Developer Experience of a Graphical User Interface Designer”.

The paper also contains reference to Fagerholm’s model, but also introduced a mindmap of most relevant factors of intrinsic motivation and flow state experience to developer experience. The motivation playes a big part in developer experience. That is not in the hands of the API provider, but for sure bad developer experience can kill the joy and motivation easily.

UX and DX

UX and DX are often discussed the context. Kuusinen writes about the differences as follows: “While UX considers the context of use of a system, DX considers the context of software development, including aspects beyond software tools, such as development processes, modeling methods, and other means of structuring Software Engineering (SE) tasks.” (Flow, Intrinsic Motivation, and Developer Experience in Software Engineering, 2016)

Developer experience by Kuusinen

Kuusinen’s approach stresses the motivation and flow state’s role in Developer eXperience. The main outcome or result of the paper is that “results suggest that developer experience can be improved by fostering the developer’s interest and enjoyment, offering rewarding experiences, supporting challenge-skill balance and feeling of competence… supporting action awareness and providing a sense of control are also key factors of good DX” It must be noted that in the study focus was on GUI tool (Vaadin), not APIs. Still I consider the findings valuable and applicaple to API DX as well with some reservations.

Pretty much all of the items in the mindmap is something that API /platform provider must take into account.

Rewarding - provide small victories before the final big bang

The API at hand must provide rewards eg success feelings. It must do what it promises and solve the problem. Even before completing a major development task with your API or platform, the rewards must occur earlier, not only at the end. By providing small victories along the way, you provide rewards and keep the motivation high and enable flow experience. The picture mentions autotelic, what does that mean?

Mihaly Csikszentmihalyi describes people who are autotelic as those who need few material possessions and little entertainment, comfort, power, or fame because so much of what he or she does is already rewarding. Because such persons experience flow in work, in family life, when interacting with people, when eating, even when alone with nothing to do, they are less dependent on the external rewards that keep others motivated to go on with a life composed of routines. They are more autonomous and independent because they cannot be as easily manipulated with threats or rewards from the outside. At the same time, they are more involved with everything around them because they are fully immersed in the current of life.

Skilled with the tool

Skilled with the tool is obviously related to onboarding your API. It might occasionally require some sample apps, code snippets, guides to ease the noob developer’s path to the essence of your value proposition provided with the API. Developer always learns and pokes around with new tools and products before taking it into real use. They play with it to see the limitations, to understand it and to explore the real potential. This is why there’s so many hello worlds around the tool space.

Enjoyment

Needless to say that your API must be enjoyable to work with. Enjoyment for sure includes fluent onboarding, usage and even replacement with an alternative API. Enjoyment includes also predictability; the developer should soon after trying out your API get the feeling of familiarity and thus be able to get things right often even without checking all the details from API docs or peers. Predictability can be achieved with consistency and by following best practices in the industry. Also if industry has strong standards, then you should follow those. If working with your API is a constant pain in the ass, the developers will change the API to something else if possible. They might even consider nasty screenscraping approach or alike.

Spontaneous

This was an interesting finding in Kuusinen’s study. When things really work, the developer gets the feeling of the way time passes seems to be different from normal and do things spontaneously and automatically without having to think. This also refers to qualities which as often found in flow state experience.

Sense of control and challenge-skill balance

The developer feels s/he is sitting behind the steering wheel, not in the back seat unable to control the situation. The task at hand is a perfect fit to the skills possessed.

Conclusions

Kuusinen’s approach to DX is possibly less holistic compared to Fagerholm’s but a fresh motivation focused description backed with empirical research data. I have no doubt that the items mentioned by Kuusinen would not have a significant effect on DX. The connection between motivation, feel of control, enjoyment and easy to use tools with DX is obvious. It would be interesting to chat more with Kuusinen some day. Coming back to the definion of DX was quite refreshing. Defining DX was the topic of the #1 post in the series. Now it’s coming towards the end and the circle closes.

Some more to read from 100 Days DX