“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.
- Product Experience
- Industry Experience
- Technology Experience
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.
Level of experience with your productA developer could be familiar with your product or not. In general developers in your company are a lot more familiar with your product than those not at your company. It is safe to assume that anyone reaching your site for the first me has no familiarity with your product at all.
Level of experience with your industryA developer could be familiar with your industry or not. In general developers in your company are a lot more familiar with your industry than those not at your company. If an external developer is familiar with your industry they are likely to either be from the industry or have used a competitors product.
Level of experience with technologyA developer can be new to development or a seasoned expert. In general the developers in your company are very familiar with the technology used in your company, but experience might vary on other technology stacks. External developers could approach your company with vast amounts of experience, or no experience at all, or technology experiences parallel to your company's offering.
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.
Product Owner High motivation / High persistence
Product Engineer Medium motivation / Low persistence
Hacker Medium motivation / High persistence
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.
Explorer Low motivation / Low persistence
The “Typical” Developer
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.
- They are unfamiliar with your product
- They are unfamiliar with your industry
- They are unfamiliar with the technology they intend to use
- They are low on motivation and persistence to use your product
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!