“I know what developers think!”
- famous last words of an API product owner
When software developers write software for other developers to use, it’s very easy for them to convince themselves that all developers think the same way they think. We’re all analytical super geniuses after-all, right?
Those of us who’ve had some experience with trying to get developers to integrate our products know that this is not true. Yet often the next step is to put these developers into arbitrary categories: “Startup Developers”, “Enterprise Developers”, “N00bs”, “Script Kiddies”.
In this article I hope to give you a different way to think about what sets developers apart from each other. At the core there are 4 attributes that contribute to the state of mind of a developer.
It’s easy to understand that not every developer has the same knowledge as you have. Sure, you know that, that’s why you’re writing them some documentation!
Yet, when dealing with developers it’s important to remember that there is a wide variety in their kinds of lack of experience. Developers can lack experience with your product, industry and the technology they intend to use.
I often encounter documentation (and site copy) that’s written for a developer who already has decided to fully commit to a product. It’s great to have pride and confidence in your product, but external developers might not be at that state yet.
Often developers are not yet ready to commit to paying for the pro plan, and they’re probably more likely in search of some example implementations than they are ready to deep dive into the reference docs.
When a developer reaches your site they can have various levels of motivation. Understanding their motivation, and their willingness to persist, can help you build a great developer experience for each of these types of developers.
Here’s a quick overview of some common types of developers you’ll see using your product.
A hacker could be invited by you or someone else to look at your product during a hackathon. Their persistence will be higher than a product engineer as they are likely to be driven by a competitive spirit, but their understanding of the problem at hand will be lower as they might not yet know what problem they will solve with your product.
So what’s a typical developer? “How can I target as many developers with a simple solution”, you ask?
When we look at these characteristics it becomes easy to determine the lowest common denominator for your external developers.
Sounds tough, right? Well the good thing is that I’ve never heard a developer say: “I wish this documentation was more complicated!” Providing clear, simple, and to the point documentation is useful for everyone. Providing documentation and guidance for every other level is the next step, but even that is not an impossible task.
In my next post I will go over the different documentation types and how they can help you target these different types of developers. Meanwhile, remember that different developers have different needs, and providing documentation for developers at each level is essential.
I am a freelance Developer Experience consultant. If you want to know more about my work have a look at my portfolio and if you’d like for me to help improve your company’s Developer Experience then most definitely reach out to me via Twitter or email!