- Are you a Ruby or Elixir developer?
- Do you love to write in-depth blog posts, but hate promoting them?
- Do you wish you could spend more time writing, but stop yourself because it doesn't pay the bills?
- Do you wish you had an excuse to deep-dive into an interesting topic, and explain it to the world?
...then we have an offer for you!
We're looking for a few developers who'd like to write for us. We'll pay you well (starting at $500/post), and we'll make sure your posts look good and reach the right audience.
This isn't some content-farm BS. We want to build long-term relationships with authors who care about their subject matter and their work.
We also want to encourage members of marginalized communities to apply.
Who shouldn't apply
This may not be the opportunity for you if:
- You don't have any experience using Ruby or Elixir at a professional level
- You have never written a blog post about anything related to code
- You won't be able to pitch us ideas for interesting articles
- You expect to follow a typical tech-writer workflow where you collaborate with subject matter experts to create content.
What is Honeybadger?
Honeybadger is an error monitoring company. Our mission is to help developers find and fix bugs quicker. That's why we've always loved putting out high-quality blog posts. You know, the kind that go past the surface of a technology to help you understand how it really works. Because when you're fighting a tough bug nothing beats a well-rounded understanding of the underlying techology.
What are we looking for?
We would like to establish a collaborative relationship with authors who love explaining how things work and who make complex topics graspable to beginners.
We want to work with these authors to create several series of articles. A series will contain 3-5 stand-alone articles of 500-1000 words each.
For example, a series named "Optimizing Rails Performance" might contain the following articles:
- Profiling Rails Applications
- Understanding Rails Memory Usage
- Rails Idioms That Undermine Database Performance
If you have expertise in a topic and would like to pitch a series, wonderful! If you don't have a topic in mind, we can work with you to find something that works for you.
Articles will initially be published on our blog. They may eventually be published in ebooks, in print or on third-party platforms.
Our audience is mostly "full stack" web developers. Most have experience in Ruby but also use other languages. Many are responsible for dev-ops and other concerns beyond pure development.
Skill level ranges from beginner to advanced. However, one of our missions is to raise people up and help them meet the content. So even with advanced topics we spend time explaining enough of the basics to help people understand.
Our blog is a university, not a trade school. We prefer topics that will give readers knowledge they might use years from now.
A pattern we like to use for generating interesting topics is
big => small.
- "How does [big concept] apply to [specific situation faced by readers]?"
- "What [big overarching rules] should you keep in mind during [specific situation]?"
- "This [specifc detail] of a certain programming language is weird. Here's how [fundimental properties of the system] made it that way."
Here are some examples:
- Why certain database patterns are slow, and how they're easy to accidentally do with rails.
- What exactly is unicode and how do you work with it in ruby?
- What are the rules a programmer should learn to become a good manager in a consulting shop?
- How do websockets work, why were they designed that way and can I build a toy implementation in Ruby?
We're generally not interested in topics that only cover the mechanics of how-to-do-a-thing. While it's fine if your article tells people how to set up authentication with Devise, the main topic should be something bigger, like "how do authentication systems work."
We follow a pretty simple process for most of our articles.
- You tell us what you'd like to write about
- We work together to figure out the actual article topic
- You do a first draft
- We give you high-level suggestions to improve it (usually within a week or so)
- You do a second draft
- We submit edits for your approval via a GitHub PR. (usually within a week or two)
- When you're happy with the final article, you merge the PR.
- We pay you (usually within 1 week of edits being approved)
- We publish (Around 1-2 months after the PR is approved)
You will be able to see where your articles are in the process by using our project management tool. We strive for transparency.
There are no deadlines. The pace of work is up to you.
Our goal is to pay authors a similar rate to what they would make doing development.
We usually pay $500 per article.
Here's an example to show you the kind of length and detail we prefer.
We generally split longer works into series of several articles.
We pay via PayPal or TransferWise soon after you approve our final edits to the article.
Who will you be working with?
You'll be working mostly with Starr Horne. That's me! I'm a co-founder of Honeybadger, which is less intimidating when you realize what a small company it is. I've done a lot of blogging and speaking over the years and am really excited to start nurturing this little community of writers.
Professionally, my values center around empathy and kindness. People are more important than things.
Blog posts are written in markdown and managed with git and github.
Email email@example.com. Please give me a few days to reply.
How to apply
Then, please send the following to firstname.lastname@example.org:
- A brief cover letter saying hello, and explaining the kind of things you'd like to write about.
- Two articles about some aspect of application development you've written that you're proud of. Links to blog posts are ok.
While reading the example pieces, we will be looking for:
- Is the author able to make complex things seem simple?
- Is the language used clear and direct?
- Does the writing style seem friendly? Like something I'd voluntarily spend my free time reading?
If it looks like you're a good fit, we'll schedule a call to discuss how we might work together.
- Give me up to a week to reply to your initial email.
- Don't use our support email system to ask about writing.
- Don't ask about the status of your application via other channels like Twitter, unless it's been more than a week and you're worried it got lost.
You made it this far, so I figured I should say thank you!