We launched our Engineering Blog back in November 2015. A year later, we published 50 articles and reach in average 100 visitors on any week day. Time to reflect on what we learned!
This article explains how we organize the Engineering Blog, get the time to write articles, and what kind of stories drive the most traffic.
1. Focus on Engineering — not on Us
From the start, we decided to launch our Engineering blog separated from our product blog. In hindsight, this has been one of the best decisions!
Not having to worry about direct branding effects for the product or the company allowed us — as developers — to stay ourselves. We simply write for other developers about what we would like to read.
It especially removes the necessity to over-polish articles. Instead, we can just write like developers write. In short: use developer lingo instead of trying to win a marketing award!
Sometimes, we do use references to our own product to illustrate a point but generally prefer to use generic examples or open-source products with which readers are already familiar.
2. Integrate writing into the development workflow
Developers are hired because they’re great in writing code — not because they are enthusiastic bloggers. Hence, asking developers to blog on “interesting topics” might create a lot of overhead and frustration.
From “interesting stuff” to “what I wanted to share anyway”
Hence, we changed our approach. Instead of writing about “interesting topics” we started writing about “interesting stuff we are doing right now”. Soon we went one step further to writing about “interesting stuff I’m doing right now — which I wanted to tell my colleagues about anyway”.
A great example is how we blogged about entering the world of Polymer and Redux — a rather new field combing two popular technologies:
- After figuring out how to make the two technologies work together, we wrote an article that explains the basics. The article was mainly targeted to our fellow developers but sparked considerable interest by others.
- We ran into a particular issue on how to use selectors. We wrote a blog post summarizing all approaches that we had tested and shared it with the community for discussion (we got the perfect solution as a response).
- As we dived deeper into the technology, we blogged about various issues that we encountered.
- Once we had completely adopted the new technologies, we wrote a piece on how to properly refactor the code (which acts also as internal documentation).
By that time, we had written so many articles that it become overwhelming for new developers to absorb the content. We therefore created a presentation that provided the overall story.
Minimize, minimize, minimize
We minimize the overhead for each individual developer also in other ways:
- Developers are not required to have somebody “proofread” articles before publishing.
- Anybody can write about a good story/tip that somebody else came up with but doesn’t have time to write about. This avoids “punishing” developers for coming up with cool stuff — independently if they like to write about it themselves or not.
- We normally use free Flicker images to illustrate posts (remind checking the license and add credits!)
3. Write with a narrow focus on a topic of wide interest
Having clarified how to minimize the overhead of writing, one key question remains: What are the topics that are worth blogging about?
Let’s have a look to the Top 10 of our most read articles (as reported by Medium statistics):
- How to Move a Private Repository from Bitbucket to Github (512 readers)
- Polymer loves Redux (500 readers)
- Cordova + iOS 10: NSCameraUsageDescription missing (441 readers)
- How to view XLIFF files with Excel (421 readers)
- Who blocks my Youtube embed (Cordova/Phonegap)? (369 readers)
- How to access dynamically created Polymer elements in dom-repeat/dom-if (364 readers)
- Polymer + Cordova iOS — 80% faster (357 readers)
- Localize Polymer applications (262 readers)
- Don’t get fooled: Is iron-list really a drop-in replacement for dom-repeat? (240 readers)
- Will Material Design bring back the Golden 90s? (231 readers)
The read-ratio of these posts ranges from 70% to 90%. For example: our top article on Bitbuckt to Github migration attracted 689 viewers of whom 74% actually read the article (512 readers).
Clustering the Top 10 reveals an interesting pattern:
- 80%: Mini tips (how-to’s, bug fixes)
- 20%: Broader topics
Even more striking: although we blog mainly about Polymer (a frontend technology) — only one of our Top 5 posts is about Polymer. The others are on technologies that are far more widely used like Bitbucket/Github, Cordova, XLIFF.
Hence, if driving traffic is the goal: The best posts have a narrow focus but are on a topic of wide interest.
4. Use keyword-rich titles
Talking about traffic, we also analyzed where our readers come from.
For all Top 10 articles, Google drove 80%+ of the traffic with two notable exceptions:
- The Material Design piece had been linked by a specialized aggregator.
- The Localize Polymer article received most of its traffic from a link on the open source project, which it describes.
It shouldn’t come as a surprise that articles with a keyword-rich title (aka SEO-friendly) did in average much better than articles with a newspaper-like title.
Although the following articles with newspaper-like titles have a similar read-ratio and draw a similar amount of traffic from Twitter, LinkedIn, and Medium — they all lacked the Google traffic compared to the Top 10 articles:
- 403: Cursed by CORS (22 readers)
- Why does Polymer eat my HTML tags? (52 readers)
- Less (animation) is more (50 readers)
Even titles that normally do well in digital media flopped for us, e.g. 3 Reasons not to mix App Translations with Formatting (19 readers).
Therefore: Don’t get too creative with your titles but simply mention the terms by which users would google for it. Something that shouldn’t be too hard for articles with a narrow focus.
Bonus tip: A good starting point are often the keywords that you used when initially trying to find a solution on Google/Stackoverflow. If you didn’t find a result in a reasonable amount of time, chances are good that others looking for the same keywords might be interested in your solution.
Want to learn more about coding? Have a look to our other articles.