There comes a point in the life of every software engineering organization when your team wants to start sharing more information externally.
You want a chance to give back for the all hours you’ve saved after finding a 7 year old blog post where someone solved the exact problem you’ve spent all day trying to crack.
Perfect, you should start an Engineering Blog! Tons of organizations do it, so the path should be obvious… right? Maybe. Rentable recently went down this path and discovered there are tons of options out there. Many options do the same thing. Some have a million features that you don’t need. Some need a ton of setup. Some require that every article you publish, by definition, is a Medium Thinkpiece™. It seemed fitting that our first post highlight the journey we took to get here.
A caution: Tech moves fast. The blogging landscape we surveyed today will not be the same tomorrow. Solutions that seemed great yesterday could soon be eclipsed by bigger and better things.
Choosing a Domain
Alright, so you’ve decided you’re going to start an engineering blog, but how are folks going to get there? Depending on your needs, there are a few different directions you can go.
First off, I’m going to assume you want some amount of custom branding here. If you don’t care and want a spot to start publishing articles, Medium or Wordpress.com both provide free services where you can post from their domain. For example: “medium.com/your-orgs-name” or “yourorgsname.wordpress.com.”
Some fine folks on GitHub have put together a fantastic list of company engineering blogs that we can use to come up with some ideas.
To keep things simple, there are three main options:
- Host it on a subdomain of your main organization’s domain, this is what we’re doing. Example: “engineering.yourorg.com”
- Host it on a path of your main organization’s domain, this is a bit more complicated, but will likely result in a more positive brand and SEO impact. You’ll need to use a reverse proxy if this is your choice. Example: “yourorg.com/blog”
- Host it on a different domain than your organization’s domain. For teams that don’t have easy access to adding new DNS records for their organizations domain, this might be the way to go. Example: “yourorg.engineering”
Let’s take a closer look at the subdomain data from GitHub.
We can see that the majority of engineering blogs are not using a subdomain and are being served on their chosen domain. The “engineering"and “blog"subdomains are the most popular. The “tech” subdomain comes in a compelling third place, and popularity drops off for the remaining domains.
Alright, so what about paths?
Taking a look at the top 5 above we can see that most engineering blogs are not being served on a path at all, meaning they’re either being hosted directly on a domain or subdomain with no extra routing. In the case where a path is used, “/blog” and “/engineering” are the most popular .
We can’t really draw any conclusions about the implications of these different choices from their prevalence, but if you’re interested in the popular choices, you can’t go wrong with “engineering.yourorg.com” or “yourorg.com/blog”.
Hosting
Okay, you’ve got your domain figured out, now what? Next we need to figure out how our blog’s content will actually be served.
Once again we have a few main options:
- External, you don’t handle the infrastructure and have limited options as far as configuration; cheap and easy setup
- CMS (content management system), very configurable, your choice between self-hosting or paying for a SaaS offering; definitely the most robust solution
- Statically Generated Site, cheap hosting and no web servers, a minimal solution that will be familiar to engineers
Let’s dig into each of these.
External
The absolute number one option here is Medium . We’ve all read something on Medium at some point, it has decent discoverability and lets you start an organization-level blog with many authors. Lots of successful engineering organizations like Airbnb , Coinbase , and PayPal use Medium to host their blogs
Other less desirable options here are “build your own site” solutions like Webflow, Squarespace, and Wix. I wouldn’t recommend these platforms for your blog when there are already purpose-built solutions for creating blogs and newsletters.
CMS
The two big players here are Wordpress and Ghost . Wordpress is a household name and responsible for hosting a shocking 43% of all content on the web. Ghost is the new kid on the block, built on more modern technologies and offering a very similar solution to Wordpress.
Wordpress is a proven technology, has a massive community following, and a huge ecosystem of plugins that will let you do almost anything you want, I mean… almost half the internet is built on it.
It’s biggest benefit: It’s very flexible.
It’s biggest disadvantage: It’s very flexible.
Out of the box, Ghost claims to offer a 19x speed advantage over Wordpress, a claim I haven’t validated but wouldn’t doubt based on prior experience. Ghost focuses on blogging and publishing.
Both Wordpress and Ghost are open-source, have SaaS offerings, and can be self-hosted.
Statically Generated Sites (SSG)
There are a lot of options for static site generators. The big ones you’ve likely heard of are: Hugo , Jekyll , and Gatsby , and next.js. A few of the smaller players are eleventy, vuepress, and hexo.
To be honest, you can go too wrong here. At this point you’re going to be generating static HTML and hosting it somewhere. Once you’ve got everything up and running, your main interactions are going to be drafting and editing posts and pushing them out to the world.
Here are my main thoughts:
- Hugo is fast and well adopted.
- Jekyll has been around for ages, also well adopted, but slower than Hugo.
- Gatsby is more featured than both Jekyll and Hugo, but we also don’t need a lot of features here, we’re publishing simple articles.
The site you’re reading right now is using Hugo. It was simple to set up and the claims are correct, it’s fast.
If you choose to go with an SSG, there are a ton of options for hosting:
- Firebase
- Netlify
- GitHub Pages
- Cloudfront Pages
- AWS Amplify
- AWS S3 + AWS Cloudfront
In our case, we’re an AWS shop and decided to go with S3 + Cloudfront to match some of our existing workflows.
Recommendations
I hate to say “It Depends”, but… it depends. The recommended solution is going to vary from organization to organization.
If you’re looking to get off the ground immediately, aren’t concerned with fine grained control over SEO, design, or other configurations, go with Medium .
If you’re willing to pay for a robust SaaS solution with lots of control that will grow with your team, go with Ghost .
If you want to be self-sufficient and deploy a minimal solution that will fit in with your engineering-centric processes, go with a statically generated site using Hugo , Jekyll , or Gatsby .