Tip: keep the long posts, with a good hook at the beginning and a summary at the end with key points highlighted at the end.
Example: http://danieltenner.com/posts/0005-starting-up-with-a-friend... (still on the HN front page)
Example: http://danieltenner.com/posts/0005-starting-up-with-a-friend... (still on the HN front page)
But you're right that longer posts are more likely to 'catch' the reader
I'm a big fan of keeping things as brief as possible, but from what I can tell it's not the best format for the web. I've only seen it work for people who have huge followings already (e.g. seth godin). Even there, most of their posts don't take off...
I could be wrong of course! Good luck to both of us :-)
Sorry -- I'm still getting that out of my system.
Seriously, as smombat points out, posts are much better if you tell the story of how you got to where you are and why you made the decision you did. That gives the rest of us some context. For the most part, broad, sweeping statements are false. Especially in IT, where there's too many edge cases. So the details of your particular situation are what adds value to the reader.
It's all good stuff, no doubt, but without a frame to pull the reader in it loses a lot of impact.
It's a style thing. Do what comes natural to you. I didn't like your post, because to me there was nothing there. I already know that teams that don't think about the big picture and just push to release get caught in a tweak-debug-release cycle. That's just me, though. Personally I would have enjoyed learning if you started off with a design, what happened to it? Who was driving your release cycle? How often was too often for you? Did you have a master release plan that you threw away, or did you never think that far ahead? Etc. It's the details of the thing that matter: everybody already knows the one-liner (or think they do)
That's just me. No worries here. Glad to see you writing and submitting. Look forward to reading more of your work.