Understanding DevelopersFebruary 23rd, 2017Cristiano Betta5 minute read
"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
- Motivation
Experience Levels
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 product
A 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 industry
A 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 technology
A 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.
It is essential to realize that developers at your company are likely to be very different than the external developers trying to use your product. Using developers at your company as a reference point is likely to result in a product incomprehensible to external developers.
Motivation Levels
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
A product owner visiting your site probably has a product solution in mind that they want to implement. Their motivation is high as they know what problem they intend to solve and what product it will serve. Their focus will be on a complete overview of services, technologies supported, service levels, and pricing.
Product Engineer
Medium motivation / Low persistence
A product engineer visiting your site probably has a problem to solve. Their motivation is of medium level as they need to balance your product versus others on the basis of effort. For these developers your product needs to be easier than your competitors, and it needs to be easier than rolling out a self made solution.
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
An explorer visiting your site is a developer looking at new technology on the radar without an immediate problem at hand. Their motivation is extremely low as they have no direct problem or product to apply your product to, and they probably landed on your site via a link sharing site.
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!