Tech bloggers: please read this and repeat it to yourself every day until it sticks.
1) "Please read this" is redundant because if they got that far in your post, they've already read it. 2) "Repeat it to yourself every day" is trite and can be made more interesting by substituting "day" with "hour" or something else. 3) You use "this" but refer to an abstract and ambiguous antecedent. 4) If they can remember to repeat it to themselves each morning, then it must have already stuck, so yours is a nonsensical sentence.
Here's my stab at something more creative:
Tech bloggers, make an effort to follow this advice each time you write, until it becomes effortless.
Or something shorter:
Tech bloggers, sharpie this quote onto your keyboard.
Tech bloggers: be concise.
(It's directed at everyone and therefore includes Tech Bloggers)
There was noting ambiguous about the antecedent.
Most tech bloggers also don't know how to write.
My favorite? Rule No. 10: Revise, revise, revise.
I can't tell you how many times I've written something, had it published (through the newspaper I work at), then read it 2 weeks later and thought "DAMN! I should have changed that!!"
I do have a habit of reading partially through an article and then commenting ...
For example, "Rule 8. Is Secret" is (possibly) illustrating #6, #4, and the humor of it #3.
It's making points, meta-points, and doing it with a sense of humor. There are good lessons at each of those levels, and it makes you think "Wait, really? Did he really mean that?"
Rule No. 2: Don’t go searching for a project, let your project find you. You can’t rush inspiration. How do you think Linus came to “Linux”? It was just an ordinary day, and there it was — fate.
Rule No. 3: Program in domains you know. Listen to your heart. Ask your heart, Is it true? And if it is, let it be.
Rule No. 4: Never use three LOC when one will do. Be concise, use macros. Don’t fall in love with the gentle trilling of your mellifluous commands and blocks. Learn how to “kill your darlings,” as they say. With but a few deft strokes, pare it down to create: “(help land shark)”.
Rule No. 5: Keep an open source dream diary.
Rule No. 6: What isn’t said is as important as what is said. In many classic systems, the real action occurs in the API calls. Try to keep all the hard yakka out of the code. Some “real world” practice might help.
Rule No. 7: Developers’s block is a tool — use it. When asked why you haven’t upped your LOC lately, just say, “I’m cutting out unneeded blocks.” Since most people think that developing is some mystical process where code is always created, cutting out blocks is the perfect cover for when you feel like refactoring.
Rule No. 8: Is secret. Yes, check out other jobs.
Rule No. 9: Have adventures. The Algol/C mode was in ascendancy for decades before it was eclipsed by trendy fabulist “objects.” The pendulum is swinging back, though, and it’s going to knock these object eggheads right out of their Stroustrup chairs. Keep ahead of the curve. Get out and see the language landscape. You’ll be glad you did.
Rule No. 10: Refactor, refactor, refactor. I cannot stress this enough. Refactoring is when you do what you should have done the first time, but didn’t. Get that draft counter going. Remove a semicolon and then print out another copy — that’s another draft right there.
Rule No. 11: There are no rules. Except the ones you learned during your Code and Comment days. Have fun. If they don’t want to be friends with you, they’re not worth being friends with. Most of all, just be yourself.
The rules: http://www.writingclasses.com/InformationPages/index.php/Pag...
The book: http://www.elmoreleonard.com/index.php?/weblog/more/elmore_l...
The man: https://en.wikipedia.org/wiki/Elmore_Leonard
He's written a lot of books-to-movies that you've probably seen, or that your dad has.
I wasn't expecting that one.