Why did I do it?

This question has been posed to me couple of times. There’s three reasons. I’ve been interested about DX for some years now. I started writing a book about DX around Oct 2018 “Build for Developers”. The landing page for the book is still online. I just got stuck and there was always an excuse why I don’t have time to write. I do have 6 underage kids (between 1 and 13 year of age) in the house. That causes some friction in the process. Some of the material in this blog is from that time as well. I had to have a different method to get the book material written.

I initially wrote some articles to LinkedIn and Medium. Medium has been acting up and putting walls for the content so an alternative had to be found. LinkedIn is somewhat easy and great place to write content, but still the audience is biased. My solution was to get a dedicated domain (100daysdx.com). I’ve done a few sites with Jekyll and I found a good foundation for this site from Github. There you go, all that I need. Write the posts as markdown files in github and let the jekyll handle all with Github.

The 100 days idea was borrowed from UX field. A friend of mine has done 100 Days Design challenge some time ago and I though to mimic the idea. Just write a post every day for 100 days. That would force me to do some writing and reading every day. I used around 1 hour each in writing. The weekends I read academic articles. Some of them are listed in literature section.

The result is around 380 pages of raw material for a book. I just need editorial help to convert it into a book.

Obvious discoveries

While writing every day there’s no time for retropectives or more detailed analysis of findings. Even now I’m not ready to write the “big conclusions” chapter. I need time and I need to read couple of times with thought what the hell did I write. When you are writing every day after the normal working day in the evenings, you just want to find the topic fast and then write it. Anyway, here’s a few things that have already surfaced from the experience.

1. You are not the center of the universe - developer is

Your product is not the focus of DX. It’s a tool either killing or enabling the developer experience which is more than your API’s experience. Your customer is in the center. The developer.

Understanding the customers (developers) you need to use ethnogprahy. Some insights of what is a developer can be found from #11 - Draw me a developer

Don’t be product focused but try to become customer focused. Cross the chasm and become enabler of developer experience. Great industry top 1% APIs enable the developer to enter flow state and stay there, not hinder it.

Read more from #67 - Developer eXperience maturity model

2. DX is more than your product’s developer experience

Your product’s developer experience is probably one third (cognition) of the complete developer experience. Most likely the developer is using multiple API products and then your percentage drops even more. You are offering one tool among plenty of other tools. You can’t control the whole developer experience.

Read more from #84 - Theory of Economics of Developer eXperience

3. Understand the context

Developers have tools, practices, tech stacks they use daily. Your product should fit into that and not to cause any friction. If majority of your customers want to use Postman in thee learning, make sure you make that easy for them.

Your API must provide value. Solve their problems, make things easier to achieve.

Just publishing API is hardly enough. You must support the onboarding, learning and value creation processes.

The greatest API providers support also migration to other solutions (for example in case of API retirement). The support you provide must be based on self-service tools and services since that is expected. You don’t know when the developer knocks on your door.

4. It’s not just technical

DX is mostly mental and aim is to support and enable the flow state experience. One of the major goals of your product’s DX is to increase the customer’s productivity, enjoyment and success. The soft side of DX is too often neglected since it’s not technical, but fuzzy psychology and impossible to describe with bits and bytes.

But that soft side is the core of Developer eXperience. That soft core is wrapped around with technical, business, marketing.

Developer experience is in the developer’s head, it’s moods, emotions, intuition and learning as well as experimentations. It’s a process which contains more than just your product or tools.

5. DX is a 360 concept

This illustration is work in progress version of my developer experience 2.0 definition. In the center is the developer and DX defined by previous scholars.

Around the developer I have gathered aspects which affect the developer experience. Some are product centric, business related and some developer relations related. I refuce to consider DX to be just developer portals, API docs and code examples. It’s more versatile concept.

6. Stereotypical ivory tower personas are not enough

Empathy is the key. You can’t understand the developers, their pains and gains without empathy. Your developer personas should be alive. Make them data driven and to see does your product fit to their world and needs. Make the personas feel like real people. If you don’t have any passion towards the personas, you are likely not to feel any empathy towards them.

Personas do not remove the need to discuss and interact with real people. Be in contact with your customers as much as possible; listen, ask questions, analyse and use the insights gained. Build a developer program which is data driven and attractive to developers. Your product must provide value - the same applies to developer program too.

7. Developers have economic influence

Some say that developers just take what is given and thus they don’t have any economic influence. That is not reality anymore. According to research developers make more and more decisions.

38% of developers directly approve technology purchases

The managent listens carefully what their experts say. 45 percent of the developers are in position to make recommendations for the management.

What I regret

Regret that I was not able to engage developers more to the discussions around the topics. That requires time and resources, but it was the best part without a doubt. I can so vividly remember the discussions in Twitter. Without doubt that was the best part of this project. As a research method I can recommend it. Engaging the people you write about is the best way to get empirical information. It might be hard to get people engaged, but you need to get the first developers and after that others will join. I knew some developers so well that I boldly just tagged them into to the post/questions. That worked really well. If you want to see those discussions, you can find most of them by following #100daysdx hashtag.

Would I do it again or recommend to others?

Yes! and no… Be prepared that you will most likely have obstacles in writing every day. You will get sick or something else. Put your priorities in order. Family and health are more important than writing. I had to breaks in the writing. First one was weekend with wife watching track and field competition in Stockholm. Second break was longer due to pneumonia. It took me 4 weeks to get well, but I did resume writing before that.

It’s 100 days and that it is a long time! Don’t be too hard on yourself. If it requires to take a break, then do it and continue after that.

What about now?

Now I will celebrate a little. I did the 100 posts and it’s time to take a break, let the unconscious mind to work. I’ll continue with the DX topic. The site will stay up for now. The source is in Github and served as github pages so the only cost for me is the domain.

One marvelous thing happened after the summer. I think was around post 40 or something. It became clear to me that I want to do more research on DX and write my second PhD.

Next step is DX Doctor

My next project is already under development. It’s called “Doctor of Developer eXperience”. The site is sketched and the content will be video clips. I mean raw video clips, no editing and no reservations.

I will of course write some academic articles. The videos will discuss the topics in the articles. Focus of the research is wrapped around thee economical aspects of the Developer eXperience. All the content will be accessible fromhttps://dxdoctor.net/

In addition to that I will productice the material and findings from the research as online courses. The courses will have a small price. More about that in the https://dxdoctor.net/

Plan is to have the dissertation ready by 2025. Then I can use unoffical title “Doctor of Developer eXperience”. So if you consider to do something similar like the 100 Days DX, be prepared for “brilliant” ideas like let’s write another PhD Thesis… Oh, my wife still does not know about this. I’m doomed.

Some more to read from 100 Days DX