In my experience, having a "good" blog is less about writing consistently and more about PUBLISHING consistently. The way you do that is write when inspiration strikes, but keep a "bank" of ready to go posts that you can post on a schedule, even when you aren't inspired or are on vacation. This is especially easier if you aren't talking about topical subjects or current events. (which most tech / programming writing fits.)
Two ways that I see to build audience in technical blogging:
Publish frequently, from your bank of content
Have "long tail" content that is usually around a very, very specific item - like an obscure error message and how you solved it.
On the second one, I used to be in the habit of writing a post for my blog whenever I bumped into something that I couldn't google / stack overflow quickly. I found that if that blog had the specific error text I was dealing with in it, it would get hit / commented on for YEARS, as other devs ran into that exact same problem. (And they were usually relieved / very happy to find the article.)
It's also a good practice to have because in 6 months you'll go "why the hell did I code it that way?" and you can go look up the error message you encounter again when you rip out and refactor that code. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In my experience, having a "good" blog is less about writing consistently and more about PUBLISHING consistently. The way you do that is write when inspiration strikes, but keep a "bank" of ready to go posts that you can post on a schedule, even when you aren't inspired or are on vacation. This is especially easier if you aren't talking about topical subjects or current events. (which most tech / programming writing fits.)
Two ways that I see to build audience in technical blogging:
On the second one, I used to be in the habit of writing a post for my blog whenever I bumped into something that I couldn't google / stack overflow quickly. I found that if that blog had the specific error text I was dealing with in it, it would get hit / commented on for YEARS, as other devs ran into that exact same problem. (And they were usually relieved / very happy to find the article.)
It's also a good practice to have because in 6 months you'll go "why the hell did I code it that way?" and you can go look up the error message you encounter again when you rip out and refactor that code. :)