Developer
Journey
I have not found a lot of references or a formal definition for
Developer Journey on the web. So here is my personal take on it.
To define the term in perspective to writing an application around
a concrete API that the developer has in the beginning no previous knowledge
let’s look at what the words means by themselves:
The developer in this case is a self-motivated, often external
software development professional and/or aficionado.
The journey is the inauguration to the specific software ecosystem
that exists around a specific API or platform. More literal, it is the trip
someone has to take from becoming aware of a specific API, or a category of
APIs including selection of a specific API from a set of competitors, finding
out how to implement a certain idea, signing up for API access, implement
(hack) the first simple use case around the API, make it to a fully-fledged
app(lication), publish it, and eventually monetize
it.
Overall it is about how developers experience their first and
repeated encounters with an API and how they and their perceptions of the API
change along the way. The journey starts with a first encounter or before with
just hearing or reading about it, goes on through onboarding to releasing an
application using the API in question.
Some factors that are influential are API Discovery (How do potential developers find out the API exists
at all?), Developer Evangelism (How
do they find out if they want to use it?), API
Onboarding (How do they sign up? How easy is it to implement the first
“Hello World”? Do they get an SDK is case the API is very complex?), Developer Relationship Management (If
they stick with the API how do they receives update about changes and
enhancements? Is the price right, are terms and conditions in a way that they
want to stay with it? Do they get any help to publish and advertise their
applications?)
Developer Experience (DX)
The way I would see it, it is the part in a Developer Journey
that is most closely related to the concrete hands-on experience of an
API integration developer (be it a mobile app development hipster or a
traditional SOA-type integration developer) and the daily ups and downs of
developing an app(lication) around a certain API and
platform.
It is influenced by key elements as the technical design of the
API (how RESTful is it, how adequate for a purpose,
certain protocols and common practices respected) and documentation (is it
concise, well-structured, interactive, …).
Purely technical / API centric DX discussions derive from UX, and
interaction design. In this case the user is the developer and the
interface being used is an API. In this context there is currently a lot of
discussion proper ReST style of APIs, “hackability” of URLs, etc. When you extend the term to SDKs
or libraries that wrap an existing, the discussion is not so much about the
URLs, RES and HTTP, but on the interface this piece of software provides to the
potential user.
DX - Additional reading
For DX there is some published material available. Some additional
can be found in the attached article (PDF) which takes it very scientific and
was presented an IEEE conference (http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6225984). If you want it somewhat lighter look at the Pam Fox
presentation in SlideShare (http://de.slideshare.net/wuzziwug/developer-experience), or the UX Mag article (http://uxmag.com/articles/effective-developer-experience).