If you have a marketing background, taking your first job in the world of developer tools has got to be one of the clearest examples of “drinking from the fire hose” imaginable. I’ve been programming for more than 20 years, and keeping up with the in-group jargon takes effort from me.
For you? Yikes. My sympathies.
So in that spirit, I’m creating a guide to help make at least one aspect of your job easier. Today I’m going to explain to you what the dev.to community site is, who hangs out there, and how to make use of it in your content marketing strategy while being a good citizen. And I don’t mean that I’ll do this via hand-waving. I’ll give you data-driven specifics and concrete tactics.
By the way, I don’t think the usefulness of this guide is limited to newbie developer marketers, or even marketers at all. It’s just that, compared to you veteran dev marketers and engineers, the newbies will likely view this as essential, rather than complementary.
What Is dev.to, Anyway?
Let’s start the guide with me lobbing a softball to myself. What is dev.to?
Well, let’s start with their “about” page.
DEV is a community of software developers getting together to help one another out. The software industry relies on collaboration and networked learning. We provide a place for that to happen.
If your background involves any content marketing, I probably had you at “help one another out.” This is a place where your buyers go to produce and consume helpful content.
Collaborative communities are fairly common anywhere on the modern internet, but they dominate the programming world like nowhere else. (They also have a history that pre-dates the modern internet in the development community, but I’ll hold off on showing my age and save that topic for another day.) So participating in these communities to reach engineers with content marketing is essential.
DEV started out as “ThePracticalDev,” a Twitter account. From there, account owner and eventual dev.to creator Ben Halpern set about deliberately creating a community and a site.
The rest, as they say, is history. I mean, I doubt the founders would blithely hand-wave the last five years. But through their efforts, the site now gets almost half a million visitors (per ahrefs) through organic alone.
Who Hangs Out There? Understanding the Persona
So who are these half a million organic visitors (and probably way more in direct traffic)? Who, specifically, hangs on dev.to, if we niche down a little further than “software developers”?
DEV’s Philosophy
To understand that, it’s important to understand the site’s overall vibe and philosophy. On their code of conduct page, you’ll find the following statement:
In the interest of fostering an open and welcoming environment, we as moderators of DEV pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
This isn’t idle boilerplate (emphasis mine). The broader development community, paradoxically, tends to be both very helpful to fellow DIYers while also being disproportionately nasty to one another at times. Go to a lot of popular content aggregation sites and other communities, and you’ll find some of the most weirdly angry and insulting trolls imaginable, really letting someone have it in the comments for a seemingly-innocuous article like “Getting Started with Ruby on Rails.”
Not so on DEV. It is arguably the most positive and friendly development community on the internet.
The People Their Philosophy Attracts
I don’t know which is the chicken and which the egg, but this has coincided with a community that skews beginner and enthusiastic contributor. While grizzled software veterans (like me) do hang out there, you’ll find a lot more people ranging from “aspiring developer” to “entry level developer.”
Marketers, this has implications not only for your users’ psychographic profile, but also for the “tech stacks” that are most popular on DEV. Take a look at the top “tags” on DEV, by articles published, as of the time of writing:
When you filter out the meta topics, which are interesting in their own right (beginners, tutorial, discuss, productivity), what remain are exclusively “front end” (we development) technologies.
To seasoned programmers, this makes sense. Web development technologies are both marketable and not as formidable, in terms of a learning curve, as other things. With a site that disproportionately appeals to developers on the lower end of the experience scale, you’re going to disproportionately find so-called “front end developers.”
So, broadly speaking, you will find developers here on the lower end of the experience spectrum, working with web development technologies.
This isn’t to say those are the only developers that hang out there. Indeed, in the next section, I’ll show you that you can gain traction without really speaking to that persona. But that’s who checks in with the greatest numbers.
What Kind Approach and Content Do Well?
Let me pause here and offer some bonafides, both for credibility and for the sake of data. DEV doesn’t make your follower counts public, nor does it show views publicly, to my knowledge. But I don’t mind sharing my own private stats.
A Case Study of My Content
Here’s a screenshot of what my dashboard looks like. Some quick stats:
- 121 posts, though 54 are auto-create drafts (more on this later), which means 67 published posts.
- 41,912 views, or about 625 views per post.
- 2,119 reaction engagements, or about 32 reactions per post.
- 5,249 followers.
Now, it’s worth mentioning that my content production on DEV has been highly efficient, but my audience targeting has been highly inefficient. Let me explain what I mean by that.
First, the efficient part. I’ve written a well-followed software blog for the last 10 years, and all of my DEV content has just been me syndicating articles I’ve written in the last 3 years or so. In other words, I’ve created these views and this following entirely with already-existing content.
Now, the inefficient part. My audience skews heavily to very experienced, enterprise software developers and I write a lot about freelancing, business, and consulting. I’m decidedly not speaking to the core DEV audience with most of these posts.
Still, the results are pretty promising.
A Look at Popular Content
I’ve already shown you the most popular tags on the site. You’ll do well with content about web technologies, aimed at relative beginners with those technologies. Discussion of productivity and career (especially around tech interviews) also resonate with the core audience.
But let’s actually look at some of the top posts, as measured publicly by engagement. I reviewed several of the top tags, but here’s a screenshot of the top posts in #webdev for all of history.
This is a good representation of a few common themes:
- Educational, beginner content reigns supreme.
- Cheatsheets, practical tips, surprising use cases, and other slightly-more-than-beginner content comes in a close second.
- Round-ups and posts with numbers in the title are over-represented in the most popular articles.
- You actually find relatively few strong opinion pieces in the top rankings, which draws a stark contrast to places like Hacker News, Reddit, etc.
To underscore this, consider my the most viewed posts under my byline on the platform:
- Resume Skills for the Developer with Upward Ambition (not a listicle, but seems like it would be from the title)
- How to Write Software: 5 Lessons Learned from Running a Business
- Get Started Quickly with Python Logging (published under my account, though I didn’t write it)
- Politeness or Bluntness in Code Review? Settling the Matter Once and For All
The first three track like clockwork to my observations, whereas the last one is a bit of an outlier. But I will say that code review is a thing more often done to newer engineers than by them, so the topic will draw undercover interest from that segment.
So the gist is that beginner to intermediate how-to content, aimed at web developers, possibly in list format, will do the best.
Being a Good DEV Citizen as a Marketer
Before I get to recommending a concrete strategy for posting there, however, I want to slow everyone’s roll just a little bit. You can get some real attention on the platform, but if you start carpet bombing them with product marketing, your best outcome will be that everyone ignores you. Worst case might be a ban-hammer.
It’s a community with rules, both explicit and implied. And when it comes to content marketing—especially in the developer world—I can’t urge you enough to err on the side of pure education over conversions, even with dollars at stake.
DEV is a welcoming community, and that welcoming includes companies and brands. They accept sponsorships and encourage companies to participate and even syndicate content canonically (they tell you how, right in their FAQ). But they won’t tolerate spamming, and the community won’t react well to borderline-spamming that doesn’t quite arouse moderator action.
Here’s how I’d play it, as a brand.
First of all, make a human the face of your company on DEV. You’ll attract a lot more followers that way, as opposed to posting as a brand. (I learned this firsthand by posting as both “Erik Dietrich” and “DaedTech.”).
In fact, Michael Tharrington, community manager at DEV, recommends you first create a personal account using your own name and picture, then create the organizational account and add yourself to it. You’ll get more engagement this way and the community will feel more connected to you.
Specific Dos and Don’ts
I’d also suggest that promoting your product or brand is fine, but be completely transparent about it. And, above all, make sure that the content you’re providing is helpful and educational in nature. What cool things will the developers reading be able to use your product to do?
Here are some examples of good corporate citizenship:
- Someone from Raygun curating existing DEV content, no product plug.
- Duomly, a training outfit, posting video and written content that falls under “web development beginner how-to.”
- Bearer, posting a generally helpful topic, and lightly mentioning their value prop at the end.
- This post from WayScript, about using their offering to accomplish a goal.
All of these posts have some engagement, which indicates community acceptance. But do note the numbers dropping as things get more “product-marketing-y.” Take note of that and create your strategy accordingly. And remember, you’re not just doing this for the referral traffic; you want to put your brand in front of the community.
On the flip side, here are some things I’d suggest avoiding, specifically. I’m not going to find people to put on blast here, but take my word that I’ve seen all of these.
- Don’t publish teasers and ask readers to click through to read the rest of the article. This looks like what it is: gaming the community for clicks-through.
- Avoid puff pieces about how great your offering or company is.
- Steer clear of competitor comparisons and probably just avoid mentioning your competitors altogether.
- Stay away from opinionated rants that have even a whiff of negativity. This is a very upbeat and positive community.
- Don’t pretend to be an engineer if you aren’t one. Marketers do post there, so you can post. But if it’s technical content, create an account for your engineers and give them the byline.
DEV Content Strategy
With the background in the books, let’s talk strategy specifics.
1. Create an Account
First things first. Create yourself an account.
If you have a Twitter or Github account, you can authorize that way. But a traditional username/password combination is also an option.
It’s really a pretty straightforward proposition to get going.
2. Decide Who Gets the Bylines
Once you’re signed up, you can poke around and get a feel for how things work. The site itself has a nice FAQ and a pretty vibrant, helpful community for you to ask questions.
But before you go too much further, I’d figure out who you want to have the bylines for articles that you’re posting. And that, in turn, requires you to think through what content you’re going to post there.
Don’t paralyze yourself with analysis, but do formulate some kind of plan. If you’re looking to cross-post everything from your blog for instance, and your blog has multiple internal contributors and guest authors, that means you’ll potentially have to poke a bunch of different people to create accounts and help them manage content.
You can mitigate this somewhat by creating an organization for your company, adding them to the organization, and administering the content yourself. That’s what we’ve done at Hit Subscribe, and on behalf of a client to boot. So we have some experience with this, if you have follow-up questions.
If that seems too intense, you could think about having a common organization account. You could publish everything you write to that account, and give bylines in italics at the bottom of the article. However, you do run the risk of reduced engagement this way. People engage a lot more with humans on DEV than with brands.
3. Sync Your Feed to DEV to Make Publishing Easier
As you think through your strategy on the platform, one setup hack I’d urge is to sync DEV with your company’s blog.
The idea here is that you can actually tell DEV about your site’s RSS feed. (If you don’t know what an RSS feed is, you should probably do a little digression and learn about that. But tl;dr is that it’s a way for readers to subscribe to your blog.)
If you go to the settings page, and select “publishing from RSS”, you can set your site’s RSS feed. This will have the effect of causing DEV to automatically import everything you post to your site as a draft on DEV, with canonical linking already set up. Here’s what that looks like for me, with my site, DaedTech.
(By the way, make sure to uncheck the second checkbox pictured—give yourself the referral traffic from internal links, rather than sending it back to DEV.)
With this simple bit of setup, anything you post to your company blog will appear on DEV as well, just waiting for you to set it to “published.”
4. Find Helpful/Beginner-y Content and Repurpose
So now, you’re basically setup on DEV, synced, and ready to start publishing stuff. At least, you’re ready to start publishing stuff from your site’s blog or original content.
But there’s one final bit of content prep work I’d suggest. Go and hunt for what I’ll describe as “found content.”
If you’re not an engineer, enlist their help with this. Do you have any internal coding standards documents, onboarding materials, lengthy explanations in pull requests, or helpful emails from inside the engineering organization? Things they think could be dusted off and repurposed as helpful introductory content?
As a marketer, it’s probably second nature for you to think of brand voice, keywords, content length, and all sorts of other things. DEV kind of liberates you from that.
Here’s a wildly popular post in the #beginner tag. It weighs in as a “two minute read” and is just a bunch of links with brief descriptions. I doubt you’d ship this on your blog, but on DEV it not only works, but does quite well at driving engagement (and probably follows for the author).
This isn’t to say that you can dump nonsense on the site. The content needs to be valuable. I’m just saying that a lot of the traditional considerations around SEO and blog posts won’t apply as much and that more concise shares and forms of content can easily help you build a following here.
So find anything your engineers have written that you think other engineers, outside of the organization might find valuable and queue it up for publication.
5. Create a Publication Schedule
Now that you’ve got blog posts for syndication, ideas for original content, and repurposed content in your back pocket, you’re ready to create a publication schedule. Yes, a publication schedule. Don’t just carpet bomb DEV with 100 cross-posts and miscellaneous content.
Depending on the amount of content you have at the ready, I’d target one or two posts per week. Plan to publish them on Tuesday, Wednesday, or Thursday mornings at around 9 or 10 Eastern Time.
This timing makes the content fresh at a time when many US-based engineers are settling in at the office (assuming that happens again after 2020) or home, thinking about work, but still warming up and procrastinating slightly by reading their feeds and community sites. In other words, this timing will tee up the most likelihood for engagement when the content drops.
Planning this out every week at a consistent time will give you an engagement advantage, and will establish you as a regular contributor that people can follow and expect to hear from.
6. Create a Backlog of Discussion Topics or Questions for #discuss
You’re not quite done with your planning, but we’re certainly getting there. You’ll be done as soon as you queue up some items to pose in the #discuss tag.
If you check out the top posts (as of the time of writing) from the last month here are the types of questions posed (founder Ben Halpern is quite good at this):
- What are some “classic reads” in programming?
- What are some side project suggestions?
- And what are your favorite coding podcasts?
He basically just poses those questions, with maybe a sentence or two of explanation. And those three questions combined for 575 reactions and 200 comments.
This is a great way to do two important things for your presence on the site:
- Create a high degree of “bang for your buck” engagement.
- Be a good citizen. A high-value community contributor doesn’t just blast the site with repurposed content—you need to comment, discuss, and engage with people.
And the best way to do this isn’t to try to think of some discussion question every week on Tuesday morning. Do it instead by spending a couple of hours brainstorming them with some engineers, logging them, and queuing them up. I can’t guarantee that’s what Ben does, but I’d wager dollars to donuts it’s what he does.
7. Sanity Check Posts Before Sending Them Live
Finally, it’s time to start shipping stuff.
DEV uses markdown, as you’ll discover during your drafting. If you’re comfortable with markdown, that’s great, but, if not, you might want to enlist some early help from folks in your organization and consult the DEV editor guide. This will smooth out any issues you might have in drafting.
Of course, as with any publication platform, you want to give things a sanity check preview and that applies to DEV-specific and found/repurposed content. But I’d suggest giving an extra careful pass to anything that you’ve syndicated from your blog with the automated RSS import. It’s a pretty slick utility, but it can choke a little on more exotic layouts from WordPress.
Finally, speaking of syndication, I’d suggest one more sanity check. If you have a low domain authority site, and you’re syndicating a post you really want to rank for, I’d pump the brakes on syndication, even with canonical linking. Canonical is a suggestion to search engines—not a command.
I have seen instances on various sites, including DEV, of the syndication outranking the original, even with canonical linking. It’s unusual, but it does happen. And it’s not worth the risk for you with particularly strategic keywords for your brand.
Generally speaking, if you have higher DA or if you’re not super worried about the post from an organic perspective, you can go ahead with syndication and canonical linking. But if you have any organic interest at all, I’d suggest two things:
- Give the search engine a few weeks to index and get used to the original on your site before syndicating.
- In addition to the canonical link, explicitly link back to the original in the post text as I did here.
8. Set Aside Engagement Time for Your Posts and In the Community
Finally, I alluded to this earlier, but I want to briefly call it out in its own section for emphasis. Set aside some time to participate in the community, with your content and in general.
Having a queue of discussion questions is a great way to get started. But you want to go beyond that.
Assume that, as your following and presence grow, people will comment on your content. Respond, follow up, and be friendly, as you would on your own blog.
But I’d also suggest following some folks, participating in discussions, and finding articles to comment on yourself. This is obviously easier if you have an engineering background, but you don’t need to. I see plenty of marketers and non-techies mixing it up in discussions that don’t require that background. Heck, #productivity is one of the most popular tags.
Get Yourself on DEV
That’s the overarching picture of DEV and DEV strategy. I’ll close out by suggesting that you really, truly should do this.
There are a lot of niche techie communities out there that might or might not make sense for your brand, given the particulars of what you sell, to whom, how advanced it is, and what price point you have. And I’ll probably cover plenty of them in future posts.
But DEV is honestly pretty universal because it speaks to beginner to intermediate devs. Any company writing code is employing people who fall into this demographic.
And, even if you’re selling things to advanced or niche users, remember that today’s code newbies are going to be your buyers tomorrow. And do you want to be the one helping them along in their journey, building trust with them as they go? Or do you want one of your competitors doing it instead?
