
Making Your Writing Work Harder For You - charlieirish
https://training.kalzumeus.com/newsletters/archive/content-marketing-strategy
======
patio11
This was partly in response to a conversation Thomas and I have been having
lately with some people from the Internets, about the value of blogging in
one's professional capacity. His take was "Have a blog, but don't call it a
blog." I thought that was generalizable to a larger segment of the operations
of product businesses than just blogging. They're generally called "content
marketing" these days but I hate that word -- if someone has a better one,
please suggest it.

By the way, if you're a regular-ol'-geek and wondering "I wonder if writing
about technical topics could help me career-wise", the answer is "Absolutely
yes." You can use blogging _software_ but it probably isn't your benefit to
adopt the blogging _format_ of 500 ~ 1,000 word articles displayed in reverse
chronological order about disconnected topics. Instead, you could make it a
goal to write three pieces and polish them to a mirror shine.

(Related advice that I find myself saying frequently: If you publish OSS and
expect to get anything via doing so, don't just drop the OSS on github. Spend
the extra bit of time packing it into a site with a getting-started guide, a
visual identity distinct from "Github rendering a Readme file", and the
request that interested people $TAKE_THE_ACTION_YOU_WANT_THEM_TO_TAKE.

~~~
swanson
Really like your point on OSS. Even if you don't make a whole "marketing site"
\- you can get a lot of mileage by considering your README as a sales page
(and not just a technical document).

Here's an actual example, compare the READMEs for these open source RSS
readers:

[https://github.com/samuelclay/NewsBlur/blob/master/README.md](https://github.com/samuelclay/NewsBlur/blob/master/README.md)

[https://github.com/SSilence/selfoss/blob/master/README.md](https://github.com/SSilence/selfoss/blob/master/README.md)

[https://github.com/swanson/stringer/blob/master/README.md](https://github.com/swanson/stringer/blob/master/README.md)

[https://github.com/Athou/commafeed/blob/master/README.md](https://github.com/Athou/commafeed/blob/master/README.md)

[https://github.com/feedbin/feedbin/blob/master/README.md](https://github.com/feedbin/feedbin/blob/master/README.md)

[https://github.com/gothfox/Tiny-Tiny-
RSS/blob/master/README....](https://github.com/gothfox/Tiny-Tiny-
RSS/blob/master/README.md)

Which ones jump out at you? Which ones are memorable? Which do you want to
install/contribute to/star?

(I'm biased because I wrote one, but I was very intentional which how the
README looks and reads!)

~~~
dublinben
>Which do you want to install/contribute to/star?

To be honest, not yours. I'm immediately suspicious of "open source" projects
written by OS X/iOS users and demonstrated on said platforms. Without
installing your program myself, I can't expect it to work on GNU/Linux, since
all of your screenshots are taken in Safari.

~~~
swanson
Thanks for the feedback - I'm curious if you have any suggestions for how I
can assure you that it will work on GNU/Linux? The second sentence of the
installation instructions links to "setup instructions for a Linux-based VPS".

~~~
godDLL
If you really want to broaden appeal you should do what Dropbox does on their
download page – show screenshots specific to the user's OS. If your serve the
images embedded into GitHub README from your own hosting, you can do that very
easily. But you'll have to take all these screenshots, no way around that.

~~~
cpach
That’s great advice. Thank you!

------
iamwil
I dislike coming upon writing where there's no date. Because then I can't
judge for myself from what context or perspective the author wrote something.
(Is the assertion that mobile market is growing in the context of pre 2008
iPhone, or after?)

There's many assumptions we take for granted, even when we try to write
evergreen. And sometimes those assumptions turn out to be overturned after a
while.

When I happen upon articles, essays, blog posts, etc without a date, I usually
trust it much less, and try to find similar information with a date.

The only way you'll know if your writing is evergreen, is over the course of
time. I'll read stuff from 2002, and find it's still relevant, but we need to
judge whether it is for ourselves every year. And not timestamping it robs us
of that.

------
marijn
Every work has a time context. Even if it takes 100 years for it to become
irrelevant, it is still useful for people to be able to find out when it was
written. Books need a year, pdfs of scientific articles need a publication
date. Doing your audience a disservice by not showing a date may have some
shallow traffic driving advantages, but is still a dick move.

~~~
patio11
Are you amenable to the solution "Put it in a header or give it emphasis
comparable to the copyright notice rather than the title"? I think a lot of
people agree with you in the abstract that it's a huge imposition to not have
dates on things, but are unwilling to even right click to actually figure the
date out, but they'll start doing _measurable_ discounting of the work
_immediately_ if you do the typical thing and put the date front-and-center. I
would also bet that people will simultaneously say they're not giving the date
undue attention, mostly because people are terrible at introspection.

~~~
marijn
If you mean an HTTP header, no, that doesn't work, since you never know
whether the thing you get there is an accident or an actually meaningful
value. Putting it somewhere where it doesn't stand out is acceptable. What
annoys me is if I want to know when something was written (for example because
the interpretation of a reference it makes would be different before and after
some historical event), and there is no way to find out.

~~~
patio11
<meta name="date" content="May 19th, 2014" />

~~~
gojomo
That hides it from everyone but HTML pros, and even as an HTML pro myself, I'd
typically not think to check the META if they've already designed the date
entirely out of the visible text. (I'd instead check for 1st appearance in the
Wayback Machine.)

I suspect the best hybrid strategy, for those who feel dates complete a duty
to the reader, is to put the date in small, low-contrast text near the bottom.
Perhaps also, when minor edits occur, update one or more similarly-subtle
'updated' dates. That emphasizes the material is not obsolete/stale, but live
reference material still maintained.

------
tptacek
People on the Internet get really angry about this. "Of course you should have
a dateline on your posts!" "Readers are smart enough to understand when
something has long-term value!"

Don't listen to them. Of course readers are smart enough to perceive long-term
value in a blog post. _But they don 't_, because appreciating that value
requires them to expend mental energy to fight against the blog format.
Instead, they see a blog post and:

* Assume that because it's on the blog it was written in a single draft.

* Assume that it's part of some larger conversation amongst lots of bloggers.

* Assume it's an invitation to a discussion among readers rather than your definitive take on an issue. (For extra fun: add a series of complaints about not having "comments" enabled on whatever you wrote.)

* Assume that it'll end up syndicated along with the rest of your blog posts on "Planet People Like You" or whatever blog aggregator you end up on.

* Assume that it'll be followed up on in some future post.

In general, the reader isn't wrong about this! Those beliefs are continuously
validated by the majority of blogs. Which makes me wonder why anyone would
sink days or weeks of effort into a piece only to deliberately position it
alongside every other dashed-off blog post.

I think you can get immediate value just by doing what Patrick said: write a
blog, but don't call it that. But you can do things that are much more
creative, too. Our crypto challenges started out as a text file of 40
3-paragraph challenges. We thought about putting it up on the website, but we
worried that we'd end up getting skimmed by people on (not to put too fine a
point on it) HN who wouldn't really understand them, and end up "debating our
own posts" with those people. So instead of publishing them, we accepted email
addresses for people who wanted them, and doled them out 8 challenges at a
time. More than 12,000 people signed up; we're finally releasing them in their
entirety, along with solutions in every single mainstream language and a bunch
of weird ones, in a Black Hat talk this year. It became one of our most
profitable recruiting vehicles.

It was originally a blog post. Man, that would have sucked, if we stuck a date
and a title on it and hit "publish".

~~~
jobu
Any post that involves "best practices" or any specific programming language
should have a date attached. Programming languages change and best practices
change to follow suit.

When I'm looking up a topic it sucks to get halfway through an article and
realize that half of the methods it recommends have been deprecated. If the
author had bothered to put a date on the post I would have known to avoid it.

~~~
tptacek
See, right there, you've captured it. If I write a "Best Practices" article
with a 2012 dateline on it, _the first thing you the reader will do is try to
track down the most recent piece that updates it_.

~~~
davidw
So it's better to let them spend a bunch of time learning something that's
potentially outdated?

I think it depends entirely on the material and how long it's likely to be
valid for. Basic principles of human nature, for instance, are likely to not
change a bunch from one day to the next (although research might reveal new
views on them). How to install mod_perl on Apache in order to create actual
dynamic web sites... Perhaps that's best left to the late 90ies.

~~~
grayclhn
I think that it's implicit that you're supposed to keep the articles up to
date.

~~~
jamesbritt
_I think that it 's implicit that you're supposed to keep the articles up to
date._

OK, but then why not then update the date of the article?

Every so often I find myself reading something and start to wonder if it's
still current. It's frustrating to not then find that date the article was
written or last updated.

Basically, I don't see a downside for including a date, but there are assorted
pitfalls for the reader if omitted.

~~~
grayclhn
The downside addressed by the parent is that an article dated "2012" will be
discounted by many potential readers, even if all of the information is still
current.

For something where specific versions or dates matter, nothing about the
article suggests that you not address it in the "post." If a configuration
file changed in April, 2013 then you should write about how it changed and how
to deal with the different versions. And if you're writing about something
specific to Python 3, you should be specific about that restriction. But I
don't see how dating the article as "August 17th, 2013" is going to
effectively communicate either of those nuances.

The article date is at best an imperfect _proxy_ for whether the information
is current. And the OP and parent are claiming that prominently displaying the
date (and other "blogging artifacts") cause potential readers to discount the
information more than they should. I don't know whether the argument is
universally true, but it's plausible.

------
lauradhamilton
A lot of good points in here, but personally I hate it when bloggers remove
the publish date. Really irks me, and reduces my confidence in the content.

~~~
joshkaufman
Patrick's advice about taking dates off is spot-on for optimizing conversion
rates on key pages. I've taken dates off of my most important evergreen
resources.

There's sometimes a happy medium - you can deemphasize the date with CSS or by
putting it at the bottom of the post.

Here's an example of a blog-style post on my site:
[http://joshkaufman.net/malinvestment/](http://joshkaufman.net/malinvestment/)

People who want to find the date can find the date. People who aren't looking
for it aren't likely to see it.

~~~
josephjrobison
What do you think of the idea of adding an "Update" intro text to some blog
posts that aren't necessarily evergreen resources, but aren't dated sensitive
posts.

Such as if you wrote a post in May 2012, then in May 2014 adding a quick intro
saying "Updated May 2014: I've added x, xy, and xyz, but this post is still
relevant today." or something of the like?

------
thenomad
_" You can, and should, make the strategic decision that you'll primarily
write things which retain their value."_

I'm a huge fan of Patrick's, but I couldn't disagree more on this point.

Choosing to write primarily about evergreen topics is ONE valid approach to
creating value, but it's not the only one.

It's equally useful to write about topics that people have a burning desire to
know more about, even if that desire will fade over time, provided you are
building that knowledge into your strategy.

For example, one of the sites I run provides accurate, up-to-date information
on optimal builds for World of Warcraft characters. That's the very definition
of information that becomes rapidly useless. However, the time it takes to
write those guides compared to the value it provides to me (in terms of
advertising revenue) and my readers (in terms of giving a quick, accessible
answer to a question they really want authoritative information on) makes
those guides a very solid business proposition.

Likewise, I started an information site about the Oculus Rift a while ago.
Again, everything on there is going to go out of date relatively fast - but
whilst it's relevant, it's extremely relevant. And that allows me to build the
site on a very small time investment and be in a good place to ride the wave
of the DK2 and consumer release.

This is HN, for goodness' sake. Half the things we're likely all interested in
are ephemeral. Anyone ever searched for information on Ruby on Rails
configuration? Or Heartbleed? Neither of these topics are unlikely to change
over time (said he, looking sadly at the wreckage of his Rails 1.0 sites), but
it's still a solid decision both for business and value-creation reasons to
write about them.

However, choosing to focus on evergreen topics is _also_ a valid strategy.

(The rest of the article, by the by, is fantastic advice, and by the end of
the week my main site is likely to be split into "news" and "articles", the
latter of which will have a significantly deprecated - but still visible -
date field.)

~~~
jimejim
I took away 2 things from this article and don't agree with him on everything:

1\. If you're intention is to write evergreen content, you should probably
separate it from your blog so people don't automatically assume it's less
valuable. Like it or not, the date and format matter. At the very least, I
would create a separate page to highlight the more important articles.

2\. I would make sure to include a date on some topics, like tech that's going
to change rapidly. Not every topic needs a date though, like his salary
negotiation article.

You said some of this too, but just felt like summarizing myself.

------
pknight
Removing the date from a post/article/essay is like saying FU to a reader
who's trying to research a topic efficiently.

------
aytekin
tl;dr

\- Don't call your writing "blog". Call it essay, guide or article.

\- Don't put a date on your writing.

\- Show your best writing up front.

\- Collect email addresses, send your writing by email, track conversations.

\- Keep detailed notes about your previous experiences and re-use them.

\- Don't just write for other experts. Write for beginners.

~~~
hagbardgroup
It also helps to think about it in terms of the old print formats.

Only blogging is like handing someone a stack of leaflets with some semi-
descriptive tags on the side to help you navigate through them. A good test is
to ask yourself if this would be useful or compelling if someone handed you a
print version of the text.

Blogs developed the way that they did, I think, because they really took off
as a way to socialize about the news, usually created for print or TV first.
Social networks have taken over that role. Now, web publishing is beginning to
take a more leading role rather than being wagged by traditional media. It
helps to hold your writing to the same standards of quality that you would in
a print publication.

------
dkrich
Open question: has anybody ever considered or tried publishing updated
versions of evergreen content? Textbook publishers make a great living doing
this so I'm wondering if it wouldn't be possible to apply this same technique
to essays.

For example "A guide to better salary negotiations, 2014 edition", etc. with
some minor updates to reference new examples, anecdotes, popular businesses of
the day, etc.

I think this could have the dual effect of reengaging previous readers with
content they've already read as well as keeping your content fresh and giving
you the upside of having a brand new article to (re)publish. In my own
experience, I don't mind and actually enjoy rereading articles I've read
before and enjoyed so I don't think as a reader, this would bother me at all.

~~~
josephjrobison
Yes! Moz.com has a great example of this. They do a bi-annual industry survey
and update the persisting URL with the most recent findings and create a new
page for the newly outdated survey.

Current Survey Results: [http://moz.com/search-ranking-
factors](http://moz.com/search-ranking-factors)

Past Survey Results: [http://moz.com/search-ranking-
factors/2011](http://moz.com/search-ranking-factors/2011)
[http://moz.com/search-ranking-factors/2009](http://moz.com/search-ranking-
factors/2009)

------
205guy
Why would I want my writing work to be harder? I'd rather use unambiguous
title that don't confuse my readers.

~~~
zrail
This is one of those instances where the English title is ambiguous, as you
say. The piece is about a few techniques for making a piece of writing more
effective, not about making your writing process more difficult.

------
icelancer
Taking the date out of the slug made perfect sense and I put it into place
right away. Be sure to add rewrite rules if you switch permalinks in
WordPress, as simply switching to %postname% will won't automatically 301 the
old slugs.

~~~
dwd
This worked nicely for me when I switched a while back: RewriteRule ^blog/\d
_/ \d_/(.+) http\:\/\/www\\.example\\.com\/blog\/$1 [R=301,L]

Also if you pull the authorship code from the template, make sure you don't
leave any class="hentry" unless you like seeing a crap load of structured data
error messages in WMT about missing author details. I don't remember seeing
any mention of reserved class names in the HTML spec so it would be nice if
the Googlebot was a little smarter about that.

------
jellicle
The lesson people learn from articles like this is "don't put dates on date-
sensitive web spam", or alternately "always put today's date on every
article".

Both of those are just spamming techniques.

If it doesn't have a date it's almost certainly worthless content. Having a
prominent date is actually a huge positive credibility sign.

~~~
hbien
People are quick to call other authors' work worthless. Patio11's piece you
just read was very valuable to me, but it doesn't have a timestamp on it --
did you think it was worthless? Patio11 calls TechCrunch pink slime. He may
find it worthless, but it's valuable to others.

The truth is just have an audience/subject in mind and cater towards that.
Writing a technical article that depends on current state of technology? Put a
timestamp on it. Writing evergreen advice about salary negotiation? No need to
put a timestamp on it.

------
dools
Man I hate it when people publish articles without dates on them.

------
Pitarou
Tips for reading a Patrick McKenzie essay:

1\. Get a laser printer

Sorry, Amazon, but the truth is that staring at the flickering, dancing
lightbulb that you call a computer screen wears the eyes, and can lead to
serious sleep disorders. e-ink readers are okay but, for an essay of this
magnitude, there's still nothing that beats good old fashioned ink-on-
bleached-woodpulp.

And don't even think about using ink-jet. For the price of the ink, you could
hire Patrick for a full one week consultation.

2\. Paste the text into a wordprocessor

If you're _au fait_ with LaTeX you don't need my help here. But for the rest
of us, a word processor is the way to go. And, for you Windows users, bypass
WordPad and go straight to MS Word (if you have it) or LibreOffice Pages (if
you don't). Either is fine.

(In the past, I would would have suggested WordPad in a pinch, but LibreOffice
is free and has important features that we're going to make use of.)

Now, at this point, you'll encounter a technical snag. If you just blindly
copy and paste the text into your word processor, the formatting will come out
all messed up. This is because Patrick uses '90s style tables for website
layout. This is no big deal -- just go to the webpage, open up the developers'
console, and copy-paste the text one table-cell at a time -- but you need to
be aware of it.

3\. Find and tag the section headers

There are usually 4- or 5- section headers in the text. Pick them out, and tag
them as section headers.

4\. Style your text

If you're a design maven, go knock yourself out here. The system I've found
that works for me is:

\- typeface: Arial Condensed 6 point (hate it all you want, but it's free and
it gets the job done)

\- page layout: minimal margins, 3 column

\- paragraph style: 1 cm indent, no leading or trailing space, full
justification

For the section headers, I allow myself a generous 9 points bold font size.

5\. Check your printer

Make sure you have plenty of printer ink and paper available, because this is
going to be a big job. And make sure you're not going to need the printer for
anything else for a while.

6\. Print!

By the way, don't attempt to take a Patrick McKenzie essay with you on a
plane: you'll exceed your in-flight handluggage allowance.

~~~
gohrt
Incredibly long comment just to say you find patio's writing long.

~~~
Pitarou
It's more of an homage than a comment. But, judging from the downvotes, people
don't seem to enjoy my sense of humour.

