If you want a handy outline for a persuasive blog post (or any other communications medium), try the "Decker Grid".<p><i></i>*<p>1. Opening: SHARP (a "hook" to catch reader's attention), your point of view, general action step (what you're asking them to do), and what the benefit will be.<p>2. Main body (1): Key point, sub-point 1, sub-point 2, sub-point 3<p>3. Main body (2): repeat<p>4. Main body (3) repeat<p>5. Closing: restate your point of view, suggest a more specific action step, restate the benefit, and end with another SHARP (memorable hook).<p><i></i>*<p>SendGrid's Elmer Thomas published a comprehensive write-up of the Decker communications training, including the grid, here: <a href="http://sendgrid.com/blog/principles-of-a-killer-hackathon-demo/" rel="nofollow">http://sendgrid.com/blog/principles-of-a-killer-hackathon-de...</a>
I've had this experience. I've written a long, rambling post that I like, but failed to include the final paragraph that makes explicit the point I originally wanted to make. Or I've found myself with paragraphs that just don't quite go together.
I used to be a big advocate for unit testing, but lately, I think they are often a waste of time. They are great if you already know what you want to make and want to make sure you get-it-right-the-first-time. But if you're exploratory programming, designing as you go (which is one of the advertised uses of TDD), then you're likely to end up with 4 times as much test code as real code that all has to change drastically once you realize your initial assumptions were wrong. At that point, it's often easier to just scrap it all and start over than it is to figure out if the failed tests are because of bugs in the code or mismatches between the newer code and older tests.
Interesting.. .I had never considered the parallels between (technical) writing and coding, but this is often what happens when I write. And I guess this could be extended to include outlining vs. specs or pseudocode. . .for those who write code and/or prose in a more structured process.<p>And I guess some steps could/would apply to some "non-technical" writing, as well. And it's what good (in my opinion) good English teachers do, too. Thinking back to one of my favorite high school teachers (who happened to teach English) and my (college) freshman English composition instructor.
This is a good idea -- I can certainly say that I've written stuff that would be improved by refactoring. Can I encourage people to write actual unit tests for any code presented, too? I usually take my code snippets from a small standalone project, with unit tests and a build script (Maven, as I usually work in Java), placed in a git repository that I link to.
Isn't this just a checklist? Something like (for a tutorial type post):<p>1. Are the steps outlined clear enough?<p>2. Are appropriate screenshots included?<p>3. Are error messages explained?<p>etc etc?
I don't know that blog posts necessarily are (or should be) structured enough to lend themselves to 'unit testing' in any way which makes that term relevant. What OP is describing seems to be basically previewing the post first before publishing it?