Read the original thread!
This blogpost started out as a Twitter thread. If you'd like to read through that instead and respond to those tweets, feel free!
👋🏻 Howdy! If we haven't met yet, I blog here, albeit very sporadically. I also moderate the Lunch.dev and Frontend Horse Discord communities, both of which are full of content creators. I'd love to share what I've learned about technical blogging over the past few years, in the hopes that it could help you out as you consider blogging.
1. It's perfectly fine to blog just for fun.
For many, maximizing readership is part of the blogging experience. This is especially true if your goals for blogging are to expand your reach and promote yourself. However, you don't have to focus on that if that's not what you're about. Sharing what you've learned for others (or your future self!) to benefit from is reason enough to blog.
On that token, a lot of blogging advice is great, but assumes you're trying to growth hack your readership. Follow that guidance if it fits, but you're by no means obligated to if that's not what you're after.
2. Start out on a premade platform.
If you're just starting out, I think your goal should be to practice blogging and see if it's something you enjoy. Blogging platforms like Dev.to and Hashnode handle the platform and audience parts for you, so you can cut directly to figuring out whether blogging is a good fit for you.
Some bloggers object here, stating you should own your own content rather than be beholden to a platform. I generally agree! However, I don't think that that's something a brand new blogger should be focusing on. Figure out whether blogging is right for you, then think about how you'll own your content.
(And for what it's worth, Dev.to gives you the tools you need to syndicate your own content down the road if that's what you decide to do)
3. If you decide to own your own platform, keep it boring.
If you're building your blog as a way to learn some tech, great! It can be really, really tempting to use a bunch of the hot whizzbang technologies du jour to build your blog exactly the way you want. But to paraphrase Flavio Copes in his post The pros of using a boring stack, if you're focusing on creating content regularly, pick the tools you'll finagle with the least.
4. Use semantic markup.
Your disabled readers, RSS users, search engine results pages, and future self will thank you.
5. It's totally okay not to have a cadence.
If you're looking to maximize your readership, then okay, cadence is pretty important. And if your personal goals are to blog regularly, then great!
But if you're blogging for fun, it's totally fine not to stick to a cadence, I promise. It's December as I write this, and my last blogpost was from August. I've tried a few times to stick to an every-two-weeks cadence, and I found that the cyclical nature and the pressure to write something, anything, was burning me out. Now, I mostly just write whenever inspiration strikes, and that works for me.
Regular cadences might encourage some writers, but they're not for everyone.
6. You'll be amazed what some people don't know yet.
Earlier this year, I wrote a post about skip links. I wrote it because I had thought that skip links were fairly common knowledge until I spoke to several web-savvy people who had never heard of them before. The post was shared more widely than I expected, too.
The curse of knowledge is such a real phenomenon in creating technical content, and few topics are "too" basic for someone to find helpful. You never know who will be one of today's lucky 10,000 thanks to you.
7. Sometimes, 80% > 100%.
A blogpost that makes 80% of a topic easy to understand is often more helpful and shareable than a 100% comprehensive guide that is confusing.
I struggle with this a lot. I don't want to leave tidbits out of my blogposts, but I also don't want my posts to become absolute behemoths.
There will always be caveats and extra context that you just don't have room for in your posts. Trying to include every possible tangent so you can be 100% comprehensive can really detract from the core point you're trying to make.
8. It's okay to ignore some feedback.
Accept corrections and suggestions gracefully, but also… not all feedback will fit the voice and scope you're going for, and that's okay!
I had this experience with a post I wrote recently. I asked some experts for feedback on my content. The post I had written was short and to the point, and glossed over a few things in favor of clarity. The feedback I received was largely about more tangents I could include to be 110% comprehensive.
These folks were very kind to lend me their feedback, but I realized that they really weren't my target audience, and in many cases, I felt that integrating their feedback would make the post less clear for my target audience.
If you ask folks who are already familiar with the topic, be prepared for feedback that doesn't align with your target audience. Consider it thoughtfully, but consider taking it with a grain of salt, too.