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.
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."
This is so true. I think the bulk of my consulting work comes to me via my blog - I've put basically no effort into seeking it out. A conversation which happens with some regularity:
Bossish person: "We are having trouble with $MATHY_STUFF. Do we know anyone who can help us with it?"
Codeish person: "I've been following these tutorials on chrisstucchio.com..."
I'll disagree with patrick a bit about "a visual identity distinct..." and formatting, at least for people who never touch the frontend. The people looking for you probably don't care that much.
Here are some fugly blogs of people you'd almost certainly hire:
I think you're right about appearances, but design isn't the core of Patrick's point. If you called your posts "short tutorials" and had a little section on your site that listed your "short tutorials", your work would probably get cited more, and do a better job of marketing your services.
In particular, some clients will eyeball your list of short tutorials, and see "A/B Testing", "HFT Algorithms", and "Ad Placement Optimization" and immediately form positive associations that they won't by paging through your old blog posts, which is something I just had to do to write this paragraph that very few casual readers will actually do.
You write something, you think it has lasting value, you should say so. It's a corollary of "ask for the sale".
I've been planning to build that anyway, simply because some people tell me they've read articles 1 and 3 on a topic, but missed 2 (and 2 would have been useful). It's just harder to motivate myself to reformat my blog than to try out the Julia language. But it'll be useful to people, so I will do it eventually.
You are misunderstanding one thing, however. People don't google "chris stucchio" and then find the tutorials - I think that's the use case you are discussing. They google "python monte carlo simulation" and find a tutorial in blog post format. They learn that I exist if they pay attention to the URL.
"Fugly" was probably overstating things - you need to do something non-default to be ugly. Stephen Diehl is default bootstrap. Ben Tilly has no CSS file.
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:
Not sure the point you're trying to make. I opened all of them at once and just scanned each of them and the one most appealing to me is the one with the detailed changelog and list of credits. The least appealing was the one with the superficial graphics and screenshots, which turned out to be yours. Maybe I'm biased since I don't really enjoy working on the front end, except for maybe a few games side projects (but I would never make games as a career).
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.
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".
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.
Just taking your screenshots from Iceweasel/Chromium instead of Safari would be an easy step. It shows that you've tried your project on a GNU/Linux platform at least once. I don't use any Webkit-based browsers, so it doesn't help me at all if you've designed your site/project to work well with Webkit.
So perhaps you should keep doing what you are doing and not get derailed by someone whose goal is not to find a good software, but is to gripe about the marginalization of Linux even when it is completely irrelevant to context.
No, I would say showing screenshots from all "supported" platforms is a good idea. The cost is very low, and preventing people from feeling marginalized is a win for you and your software.
Anecdotally, I can say that I am going to have a look at the software, and this just because the author was willing to consider us Linux users.
Your suggestion "write three pieces and polish them to a mirror shine" has a long and substantiated precedence: scientific publishing. The fact is, you're judged by the quality of your work. Better to produce something of lasting significance that just throw some 'musings' up on the 'net.
Huh, the largest complaint about scientific publishing is quality over quantity, incremental papers,publish or perish,milking each idea for as many articles as possible.
I'm thinking that adding an "Updated May 2014" intro text to older blog posts that are still relevant can do a lot to show the date, but also show the readers that you still approve of an older post and it's relevant a few years later, and that someone is home, reviewing their old work.
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.