How To Create Better Content for Developers

They are much more likely to pour over pages upon pages of tedious documentation than be lured in by attention-grabbing clickbait headlines.

Developers are a difficult audience to create content for. Sceptics by nature, developers tend to value authenticity over all else, meaning that they avoid fluff like the plague.

They are much more likely to pour over pages upon pages of tedious documentation than be lured in by attention-grabbing clickbait headlines.

In fact, clickbait titles like "React is Dead - Here's What's Going to Replace It" may end up attracting negative publicity and turn developers off from ever returning to any content you create.

As previously stated, a tough crowd. How, then, do you create content that genuinely engages developers?

To create content that's worth a developer's time, you need to be keenly aware of specific problems related to developer experience. Once you're aware of these problems, an educational problem-solving approach can go a long way toward building and nurturing developer trust.

Building that initial bond of trust is crucial if you want to see long-term results in terms of engagement.

The majority of Circuit's team consists of developers themselves who are aware of the pain points experienced at different stages of the development cycle.

But perhaps more importantly, the team behind Circuit has years of experience curating technical content for some of the world's most recognisable tech publications under the In Plain English brand. With over 3 million monthly readers across our publications, we are uniquely positioned to understand what content genuinely appeals to developers by addressing pain points - and what does not.

Keep in mind that research data is constantly changing. Patterns shift, and our team is always learning.

However, based on our experience so far, here are some pointers to help you create better content for developers:

1. Understand your audience

This can't be stressed enough. Now, this may come off as content writing 101 - know who exactly it is you're writing for.

But here's the twist: Developers aren't like other audiences.

Traditional content writing wisdom does not apply to developers. For example, while big emotional power words in the title may work fine for other audiences, they tend to fall flat on developers. A simple "how to" title, on the other hand, that solves a specific problem that developers face on a daily basis can work wonders.

Other nuggets of content writing wisdom, such as transforming features into benefits, are highly context-dependent.

Because developers are tech-savvy, they are often aware of what features do, so you do not need to talk down to them. Coupling features and benefits may be a better option in many cases (but this is not a hard and fast rule!).

Understand the kind of developer you're writing for (beginner, intermediate, or advanced professional), the space they operate in (Web Development, Data Analysis, Artificial Intelligence, DevOps, Cloud, etc), and the specific pain points they experience within that space. Once you have that understanding, tailor your content to address these specific pain points.

Here's an example of where traditional content writing wisdom failed us. While writing an article for a DevOps-related service, we decided to make use of power words in the title. We settled on, "Accelerate your cloud DevOps workflow with [technology]."

However, while distributing this content on relevant platforms, we discovered that it failed to generate significant interest or clicks. So we changed the title to "DevOps made easy with [technology]," and the views and clicks increased fivefold.

This is not due to a hunch. With a little bit of effort spent on keyword research, you'll discover that making DevOps easier or accessible is a common concern among devs within that space. Whereas promising developers the moon with words like "accelerate" don't really work.

To better understand the developer mindset, you can conduct market research, survey your existing customers, or engage with developers on social media or online forums.

For example, the Evans Data Corporation often conducts surveys within specific developer niches. It even has an interesting report on the time developers spend on reading newsletters which you can find by scrolling down here.

2. Focus on providing value

This partially overlaps with the previous point. As mentioned earlier, developers are very savvy at detecting insincere motives. If your only motivation for creating content is to generate clicks and views, you won't get very far with developers.

Let's say that you get lucky and write that one clickbait article that generates 10,000 views. It's quickly going to turn into a game of diminishing returns.

Such articles may make an immediate impact, but they are not articles that people will return to. In the worst-case scenario, people may just associate your name with fluff and clickbait content and refuse to engage with anything you have to say in the future, even when it's worthwhile.

Here's what you need to know: developers have busy lives and aren't the type of people who are always looking for "trending" content.

On the other hand, with a little SEO and keyword knowledge, if your content can serve as an answer to specific developer queries by landing on the first page of Google search results, it's much more likely to do well in the long run.

Long story short, rather than attempting to sell some bridge or extraordinary claim, the content should attempt to be educational in a way that addresses specific developer concerns.

Here's an example of an article we wrote that's been consistently ranking on the first page of Google search results and has now become the very first result.

image

The content is purely educational, answering a common developer query while reviewing five possible options in detail. It avoids any pointless fluff, instead focusing on providing developers with resources and information that they will actually find useful.

Even if such content does not generate an immediate buzz, if it is written well and incorporates proper keyword usage, people are bound to return to it in the long run via Google searches.

Because every developer, beginner or advanced, searches for answers on Google.

They frequently visit Stack Overflow, but if your article ranks on the first page, there's a good chance that many devs will check it out instead and - if impressed by the content - even return to it over time. This leads to a steady flow of incoming traffic that pays off in the long term.

As of the time of writing, the article above has received over 4,000 views. Organic traffic ensures the view-count will keep going up, as long as the question addressed remains relevant to developers.

An important caveat to remember though is that if your content lacks substance, no amount of keyword research can help you rank high. This is why we emphasised an educational approach over thinking in terms of clicks and views. Adopt the mindset of a teacher instead of a blogger and address specific developer concerns.

There's no one way to provide valuable educational information to developers. You can content around technical tutorials, best practices, and case studies.

You can also create content that helps developers to solve common challenges, such as debugging tips or advice on how to improve code performance.

3. Keep content concise (but don't skimp on technical details)

Keeping your writing simple, to-the-point, concise and readable are again all parts of conventional content writing wisdom. But, as is customary with developers, such wisdom comes with a twist.

Make no mistake: it is critical to avoid being overly verbose or even using "power words," as previously mentioned.

But here's the catch: while your writing should be as simple and to the point as possible, for developers, simplicity does not mean skimping on technical details.

For instance, here's an article about creating surveys using React and SurveyJS.

image

The title "How to Build Dynamic Surveys with React" is straightforward and effective. It contains the keywords that developers looking to build forms and surveys using React frequently search for.

It's brief. The piece's subtitle, on the other hand, reads: "Build dynamic forms and surveys in React with the open-source SurveyJS and RESTful services."

Consider the terms "open-source" and "RESTful services" - developers are familiar with these terms. The use of such technical terms adds authenticity to the piece rather than making it inaccessible to developers.

It implies that you, as a writer, understand what you're talking about.

So the TL;DR of it is: keep your writing simple and concise, but do not skip out on technical details when necessary. But bear in mind that this is also context-dependent.

If your target audience consists of beginner devs, the level of technical details they would be comfortable with will be different than advanced or seasoned developers. So adjust according to the situation.

You can also use visuals, such as diagrams, charts, and code samples, to make your content more engaging and easy to understand. But more on that in the next point.

4. Add more than just words

To create content that developers will want to read, you need to make it engaging and interesting.

But again, bear in mind we're talking about making the content interesting for devs. Meaning that whether you write like Faulkner or Hemingway is less important than including relevant flowcharts, screenshots and code examples - for example, in the form of gist embeds - wherever required.

Break down the process into steps.

For each step, include the relevant code snippets or gist embeds. If you're creating a full-fledged app, it's a good idea to include a link to your GitHub repository with the entire code at the end.

Take a look at this article here which is about building a GraphQL eCommerce app from scratch.

The piece's introductory section first explains the problem, then provides relevant hyperlinks to the technology stack used. It then provides a high-level overview of the approach it will take, followed by an architecture diagram.

It then briefly describes the three main sections of the architecture - the frontend, backend, and backend-for-frontend - before moving on to explain the code in detail with screenshots.

TL;DR: Maintain a clear and simple writing style but augment your piece with diagrams, flowcharts, screenshots, and code examples wherever necessary.

5. Promote your content

Creating content that's good enough to stand on its own is the first step--but often, that's not enough.

Unless you have a high domain authority and an established audience, the content you create is likely to be lost as a drop in the internet's sea of information.

This is why you should promote your content on relevant platforms. Social media platforms like Twitter and Facebook are of great help here. You can join Facebook groups catered toward software development in general, a particular field like web development, or even a particular technology like React or Angular.

But perhaps the most helpful platform is Reddit. You can use relevant subreddits to promote your content.

For example, if your piece is about using React, you could try sharing it on r/react or r/webdev.

But a word of caution here: these subreddits have strict rules and direct promotion may be frowned upon. Do not create an account solely to promote links to your own content. Make sure to engage and contribute to the community.

Be a user, not a self-advertising bot.

Along with that, you can also reach out to publications on Medium such as JavaScript in Plain English or Better Programming, sponsor your content on a tech newsletter with a wide reach, or partner up with influencers or other companies to promote your content and reach a wider audience.

6. Engage with your audience

After you've promoted your content, you can take the additional step of engaging with your audience and encouraging interaction.

This includes responding to comments and questions, as well as providing additional information or assistance to help your audience get the most out of your content.

Reddit can be a great platform for this because most questions on developer subreddits are from developers themselves.

Engaging with other developers in the comments allows you to establish yourself as a genuine contributor to the community.

This will make it easier to share your content there - but also gain feedback on areas where you can improve and truly understand your audience, their needs and pain points.

Conclusion

Creating content for developers can be a difficult task, but it is doable with a little effort and understanding.

As a general rule, the best developer content is created by developers themselves.

But regardless of the approach you take, the most important thing to remember is that you are not trying to "sell" or "promote" your content; rather, your content will have a better chance of success if you take an educational approach that addresses real concerns and particular problems that developers face.

When writing for a technical audience, your goal shouldn't be to promote your own brand but to share and democratise knowledge.

For years now, that has been the motivation behind the endeavours of the Circuit and In Plain English team. Taking that as your overall approach and incorporating the other suggestions mentioned above to produce high-quality content can go a long way in helping you create highly engaging content for developers.

PS: The Circuit team take pride in being self-critical. We are our own harshest critics. As a result, we'll keep this post updated as we gain more insights from our research and findings.

Enjoyed this article?

Share it with your network to help others discover it

Related Posts

How Developer Marketing, Developer Advocates, and Developer Relations Can Work Together

How Marketing, Advocates, and DevRel collaborate to drive adoption of your product

What is the Difference Between Developer Marketing, Developer Advocacy, and Developer Relations?

All you need to know about developer marketing, developer advocacy and developer relations: similarities, differences, responsibilities and how they work.