As an author, it’s a mistake to make wild assumptions about what the reader already knows about the technology, and why it’s useful. Don’t just ‘show the rooms’, but explain why they are interesting and how they might be used.
Beyond these fundamentals, I’ve written before about the simple ‘rules’ for writing a compelling blog post, and of the need to avoid hyperbole, colloquialisms, and acronym-overload, in favour of simple, plain English that can be understood internationally.
I’ll take a moment to talk about what makes you likely to show up on Curated SQL. My expected reader is someone who has a few minutes to kill during the day and is looking for technical content. They might occasionally have more time to dig into interesting topics, but more frequently, I’m imagining somebody on a pre-lunch coffee break. To make things easier for those readers, I’m looking for four things:
- Is the post concise? Coffee breaks won’t last long enough to watch a webinar. This is most flexible criterion; if it’s interesting but a bit lengthy, I’m still liable to include it.
- Is the post technical? We’re geeks; we want to learn something even on coffee break. Non-technical posts can be great, but they aren’t really in the Curated SQL purview.
- Is the post at least somewhat novel? If I’ve linked to someone taking a cursory look at Querystore, I’m probably not going to link to another overview of that product unless there’s something new in there. With that said, “novel” is a hard goal; what’s new to me might be old hat to you, so there’s a balancing act here.
- Is the post well-written? Poor writing makes technical content more difficult to understand, so sometimes I’ll skip an otherwise-interesting technical post and wait for somebody else to post a better version.
With that said, I gladly accept submissions via Twitter (@curatedsql).