Knowing when your writing sucks

I recently started a series I called the Bullet Point Series.

https://dev.to/granthair5/bullet-point-series-intro-2hpo

This series was awful.

The topics of conversation were too vague.

The bullet point lists were far too long.

Part 1 came before the intro.

The whole thing was a mess.

But I thought I was being really clever. Oh yeah short sharp blog posts is what people want that will really take off I thought.

I could not have been more wrong. My implementation sucked. My writing style was lazy. It felt robotic and un-personal. That makes it very difficult for people to relate.

I gave this series a few weeks, no one read it and it fell into the abyss so at that point I had 2 options:

1: Continue writing in the hope that maybe I'll get lucky and this idea will really take off.

2: Call it quits and know when to back out and try something new.

I chose option 2 due to my programming background. Sometimes instead of following Alice down the rabbit hole the best option is to say "Nah forget that" and walk away to the pub. I usually choose this approach when tackling "impossible" bugs in a technique I like to call "next day programming"

Usually, the next day that "impossible" bug doesn't seem all that impossible but if you continue to bash your head off the wall chances are you won't break down the wall you'll just end up with a headache.

So, to the handful of people that read the bullet point series I thank you but I am more grateful to those of you who chose not to read it because I feel we learn more from the stuff that doesn't work or the mistakes we make than the glory we can easily become accustomed to.

Stay tuned for more non bullet point series posts and I hope you all enjoy what is to come.

Thanks, 👋