Last week, I traveled out to Colorado to give a keynote at Glue Conference on the hierarchy of developer needs.

Video:

Slides:

Hierarchy of Developer Needs on SpeakerDeck

It is a talk that I’ve wanted to give for a while, and what better place to debut it than one of the best developer conferences out there? However, as I rehearsed it, delivered it, and talked to developers afterwards, I realized that I had so much more to say than my slides and script allowed.

Motivations

Let’s address about the motivations behind this talk. I’ve been a part of various developer communities for my entire career – I’ve been on both sides of the developer/API provider divide. Whether I was working on machine learning or mobile, the goals have always been the same:

  • Come up a cool idea
  • Design the system
  • Hack it together

When I first started out, “community support” meant a once-a-month post on a SourceForge forum, and very few of those posts were answers to questions. We’ve come a long way from those days, but we can do so much better.

I started thinking about not what people were doing wrong when supporting their developers, but why, and how they could fix it.

Extending the hierarchy of needs

To really start thinking about what developers need, we need to go back…way back. Let’s go back to Psych 101 and take a look at the Maslow’s hierarchy of needs. For those unfamiliar, the hierarchy describes a ranking with the most basic, fundamental needs at the base, and tiers up into the need for self-actualization. It’s commonly visualized like this:

Creative Commons image courtesy of Luc Galoppin

Now, the hierarchy is acknowledged as being out of date, but can we still use it as a tool to formulate our support for developer communities? I propose that yes, we can. What do users of our APIs, our platforms, need from us, to become self-actualized users? In hitchhiking on the Maslow’s hierarchy, can we determine where we are lacking in our approach, and use it to do better?

Ego creep

There’s a real temptation (and I’ve been here myself, so I speak from experience) to identify with the users of your API. Oftentimes, we draw from our lives as developers and our inherent sympathy with the needs of our our user base to claim to know what they need. This is not only bad for your developers, it’s also egotistical and patronizing.

It’s what I call ego creep.

Ego creep is much like feature creep. It starts with the best of intentions, with the idea that you’re making things better, but wind up making things worse overall. In some ways, ego creep is a superset of feature creep. We introduce extra features because we know what our users want before they do. We abstract away objects into overly simplistic wrappers because our developers don’t need access to the underlying resource. It’s us knowing what’s best for others.

The first step to drafting a hierarchy of developer needs is to abandon ego. Admit that you are not your developer, that you don’t know what their needs are, that you don’t know their patterns, and you’ll be ready to start the conversation.

Drawing a portrait

A great developer experience means different things to different developers. Anyone who has worked on a team knows that we all approach problems differently, process through stumbling blocks in wildly different ways, and prefer different tools to tackle it all. So how on earth would you know how to help out your developers if you don’t know who they are?

I’ve traversed across the spectrum in the get-to-know-you tactics, from informal socialization to the rigorous analysis of surveys and tabulation. The option to choose largely depends on a few things:

  • Urgency
  • Budget
  • Fidelity desired

Should the urgency and budget allow for it, I like collecting mixture of qualitative and quantitative data. Hard data is hard to beat when it comes to informing large initiatvies like a client library rewrite, but it’s also difficult to elicit off-the-cuff remarks or rants without an in-person or one-on-one conversation. In either case, it’s critically important to engage with a broad cross-section of developers, and not just those who are currently using your API. If they aren’t using your API right now, and they could be, why is that?

Needs of developers shift drastically depending on their schedule, industry, and stack, to name a few. If you don’t have at least an impressionist portrait of your developer, how can you expect to support them?

Drafting your developers’ hierarchies

Okay, you’ve sketched out a rough portrait of our target developers and you’ve opened up a dialogue with them, so now you’re ready to draft your hierarchy and start making them productive with your API. Your hierarchy should then inform your priorities when creating resources and fixing bugs. However, if your discussion with various developers didn’t give you a heads up about this already, I’ll be explicit about it here:

There will not be a single hierarchy that fits all developers.

The needs of different categories of developers will be drastically different from one another. Goals differ. Motivations change. I created a few different hierarchies to start to address these divergent needs, two of which I show below.

I picked these two developer profiles to illustrate how different their hierarchies can be. The first hierarchy represents the enterprise engineer, who wants to make sure that she incorporates your API that makes the integration the most performant, secure, and stable. On top of an excellent set of docs, she needs to know that if something goes wrong, she’s got recourse in support. Libraries and SDKs are nice to have and will maximize her efficiency, but she can work directly against the API.

The second hierarchy represents the self-educator. This developer doesn’t necessarily have a project in mind for your API, but she wants to get up to speed so that when the project comes along, she can assert her existing skill set. Courses and tutorials are her entry point. Reference docs are good to have, but she learns more by examples and completing exercises than reading documentation.

Are these two hierarchies definitive? No. They’re a starting point!

This is not the end

Steve Citron-Pousty, Developer Advocate for OpenShift, made an excellent point about any hierarchy: the whole thing is meaningless if you don’t provide a great getting started experience. John Musser, founder of API Science and ProgrammableWeb, used a phrase that fits this perfectly: time to first hello world (TTFHW). If that time is too long, your developer will go elsewhere.

What does this all mean? A fantastic developer experience is always going to be a work in progress. You’ll always want to reduce your TTFHW. Your developer will change. Their needs will shift. You’ll have to change your approach along with it. Having to rethink your developer experience doesn’t mean that your previous one was a failure!

Move fast. Keep engaging.

This is the end

If there’s nothing else you learn from this, let it be that there are no shortcuts. I had a couple people admit to me after the talk that they hoped to find out “the recipe” for providing a fantastic developer experience to their developers. Anyone who tells you that they have this recipe is flat out lying to you.

A template for developer experience cannot replace having an open dialogue with your developers and actively listening to them. You appear disingenuous if you try to tell them what you’re giving them them while skipping those steps. So start talking to communities, engaging with them, and keep evolving and refining your developer hierarchy.