Writing for #vDM30in30

As November rushes to its conclusion, it’s time to start some introspection about #vDM30in30. Here are some observations I’ve made, in no particular order:

  • I was asked how I write so many articles in such a short time. My most successful pattern is to identify 2-3 related concepts I want to write about and write 5 or 6 sentences describing them in Evernote. When it’s time to write an article, go to Evernote, pick a concept, and give myself 1 hour to write an article. At the end of the hour, start revising it, but there’s no time limit on this. I’ve been able to do most articles in 60-90 minutes this way. The concepts stay focused, the editing is good, and I’m prevented from obsessing about perfection to the point that I never end up publishing anyway. This results in shorter articles, so won’t hold true for longer technical articles, but I like this pattern.
  • As a consequence of this pattern, my editing process is getting tighter and tighter. Write and finish, then edit, edit, edit. I’ve noticed fewer errors in my writing overall – hopefully that’s the reality of it.
  • Writing and editing is easy. Ideas are difficult. Having a stock to rely on isn’t a bad thing. I hope to end this effort with a dozen or so ideas banked for the future.
  • Thirty articles in thirty days is rough. Even with a decent process in place and much shorter articles, I don’t think I want to do this again anytime soon. I’ll stick to my once or twice a week schedule, thanks!
  • Fear is a killer. By publishing rapidly, I’ve overcome most of my fear. Previously, I would sit on a completed article for days, sometimes weeks, for fear of how it would be received. Now, I am more focused on writing for my own goals – I appreciate it when an article is well received, but it’s not the primary focus during writing and editing.
  • Even though I’m less concerned about the reception, of course I’ve looked at page view statistics. Whether I’ve published 0, 1, or 4 articles a day, page views – aggregate and per new article – seem to remain fairly consistent. There doesn’t appear to be a downside to publishing multiple articles a day. I also didn’t see any significant correlation between the day of the week or the time of publication and the number of views. This isn’t something I’ll worry about in the future.
  • I wrote about the writing process itself a few times. I found this useful to myself and I hope others find it helpful as well. The 30in30 exercise, after all, was about improving my writing.

While I said I don’t want to do this again, it has been a worthwhile exercise and I think I benefited a lot. I hope the readers enjoyed it, as well! Even though this 30in30 challenge is ending, it’s not too late to start your own 30in30 challenge.

Happy Thanksgiving!

When Good Hypotheses Go Bad

I’ve written recently about the necessity of hypotheses, whether you’re writing or troubleshooting. When you craft a hypothesis, it’s based on some preconceived notion you have that you plan to test. When your hypotheses are tested, sometimes they are found wanting. It’s tempting to discard your failed hypotheses and simply move on to the next, but even a failed hypothesis can have a purpose.

Imagine for a moment that you’re sitting in front of a user’s computer, helping them out with some pesky problem. Suddenly it’s the end of the day, you’ve tried everything in your repertoire and you’re calling it quits when the user looks at you and says, “I thought it was kinda weird you tried all that. Bob did everything you did last week and he couldn’t figure it out either.” Gee, thanks, Bob! There’s not even a ticket from last week, nor did he mention talking with this user. How many hours did you just waste that you could have saved if you knew none of it would work?

Bob spent hours crafting and testing his hypotheses, but he discarded all of them, straight to the circular file. You then proceeded to craft and test many of the same hypotheses which, of course, failed again. If only there was some way we could learn from our failures… Wait, there is!

Let’s take a quick look at another example, a scientific hypothesis. A researcher crafts a hypothesis and spends $100,000 to gather preliminary data that can be submitted for a grant worth $2,000,000. If the preliminary data looks good, great – well on the way to two million in funding. If it doesn’t pan out and the hypothesis is shot, $100,000 just went down the drain. That’s the nature of science. But…

A few years go by. Another researcher comes up with the same brilliant idea and sets out to collect some preliminary data for around $100,000. Whoops, the hypothesis isn’t that brilliant, doesn’t work out, and the scientist wasted time and money. Now science is out $200,000 on this failed hypothesis. If only she had known that someone else had tried this before, but there was nothing in the literature to indicate that someone had. She publishes her data in a journal and the next scientist who thinks they have it made can see what the results will look like before investing time and money in the idea. Good money isn’t thrown after bad money anymore.

You can help those after you (including future-you) if you take some time to record your hypotheses and how they failed. You don’t necessarily have to go into great detail, though scientific papers obviously require more rigor, often just a sentence or two will work. “Traceroutes were failing at the firewall, but a packet capture on the data port showed the traffic leaving the firewall,” or, “The AC fan wouldn’t start and the capacitor looked like it might be bad, but I swapped it out for my spare cap and it still won’t start.” If it’s a really spectacular failure – something that was ohhhhh-so-close to working, or a real subtle failure – maybe it’s worthy of a full blog article.

Make sure to store this information somewhere it will be found by someone who is likely to need it. In Bob’s case, this is what the ticketing system was there for, so that others can see his previous work on an asset or for a user. At home, you might keep a journal or put a note in the margins of the AC manual. For public consumption, you might write a blog article or submit your research results to a journal. Anywhere that will help prevent someone in the future from having to waste resources to rediscover the failed hypothesis.

Try and make this part of your habit when researching and troubleshooting. State your hypothesis, test the hypothesis, and record any failures before proceeding with successes. Don’t be a Bob!