My mother was always the one who told me (and her students) that everyone has a story. She said that writing could be therapeutic in ways you probably won't consider until you've written something that someone else enjoys. Just as software developers exist to write software for their users, writers exist to write stories for their readers. There's nothing that says technical people can't become excellent writers who inspire others to learn and share their knowledge with others.

The goal of this post is to encourage technical people to enjoy writing, write efficiently and feel comfortable doing it. I'll roll through some of the most common responses I've received about why technical people don't blog about what they know.

I don't think I'm really an expert on anything. I'm not an authority on any topic I can think of.

I'm leading off with this response because it's the most critical to refute. If you don't take away anything else from this post, let it be this: you don't need to be an expert on a topic to write about it.

You can find examples of this by rolling through some of the posts on my blog. I'd consider myself to be an expert on one, maybe two topics, but I've written over 450 posts in the span of just over five years. I certainly didn't write all of those about the one or two topics I know best.

Write about what you know and don't be afraid to do a little research to become an authority on something. A great example of this was my post, entitled "Kerberos for haters." I had almost no expertise in Kerberos. In fact, I couldn't even configure it properly for my RHCA exam! However, I did a ton of research and began to understand how most of the pieces fit together. Many other people were just as confused and I decided to pack all of the knowledge I had about Kerberos into a blog post. Positive and negative feedback rolled in and it was obvious that my post taught some readers, inspired some others and angered a few.

What a great way to lead into the next response:

What if I say something that isn't correct? I'll look like an idiot in front of the whole internet!

Been there, done that. Every writer makes errors and comes up with bad assumptions at least once. Readers will call you out on your mistakes (some do it delicately while others don't) and it's your duty to correct your post or correct the reader. I've written posts with errors, and I've gotten a little lazy on my fact-checking from time to time. As my middle school journalism teacher always reminded me, the most important part of a mistake is what you do to clean it up and learn from it.

In short: you'll make mistakes. As long as you've done your due diligence to minimize them and respond to them promptly, your readers should forgive you.

Speaking of errors:

I'm great at a command prompt but my spelling and grammar are awful. I write terribly.

This is easily fixed. If you're one of those folks who live the do-it-yourself type of lifestyle, pick up a copy of The Elements of Style by Strunk & White. There are free PDF versions online or you can borrow one from your nearest journalist. No matter the situation you're in, this book has details about where punctuation should and shouldn't be, how to structure sentences and paragraphs, and how to properly cite your sources (really vital for research posts).

Hauling around a copy of an ultra-dry reference book may not be your thing. If that's the case, find someone you know who has a knack for writing. You can usually find helpful folks in marketing or corporate communications in most big companies who will take your post and return it covered in red ink ready for corrections (thanks, Garrett!). I've even spotted some folks on Fiverr who will do this for as low as $5.

I'll wrap up with the second most common response:

I don't know who I'm writing for? What if I write about something simple and the really technical folks think I'm a noob? What if I write something crazy complex and it goes over most people's heads?

I've done both of these. Most Linux system administrators worth their salt know how to add and remove iptables rules, and they'd consider it to be pretty trivial work. Would it surprise you to know that out of over 450 posts, my post about deleting a single iptables rule is in the top five most accessed posts per month? I receive just over 11 percent of my monthly hits to this post. People are either learning from it or they can't remember how to delete the rule and they want to use the post as a quick reference. Either way, the post is valuable to many people even if I think it's the simplest topic possible.

On the flip side, I went nuts and wrote up a complete how-to for a redundant cloud hosting configuration complete with LVS, glusterfs, MySQL on DRBD, memcached, haproxy and ldirectord. I thought it would be valuable knowledge to a few folks but that it might sail over the heads of most of my readers. Again, I was wrong. The post is constantly in the top 10 most visited posts on the blog and I've probably received more feedback via comments, email and IRC about that post than any other. Once again, a post I thought would be mostly useless turned into a real conversation starter.

Let's conclude and wrap up. Keep these things in mind if you feel discouraged about writing:

• Write about what interests you whether you're an expert on it or not
• Don't be afraid to fail
• Be responsive to your readers
• Even if you think nobody will read your post, write it
• Always ensure your voice shines through in your writing — this is what makes it special and appealing

Why technical people should blog (but don't) is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Photo credit: Will Clayton

As I mentioned already, the blog started out just as a place to stuff my notes from the things I learned at work. I figured that it would be nice to store it in a searchable format but it would also be great if I could link other people to certain posts if they needed more information to fix a problem. It was a way to retain knowledge but yet give it back to the people around me who needed it.

The blog has hit 456 posts (this one is #457) and it's gone from a few page views per day to just over 20,000 per day. Here are the top five most accessed posts (since I've been keeping stats):

1. Syncing an iPhone with a new Mac without hassles
2. ip_conntrack: table full, dropping packet
3. Delete a single iptables rule
4. Increase MySQL connection limit
5. MySQL Error 1040: too many connections

I'd like to send out a big thanks to the people who read this blog, add comments (or complaints!), and suggest new topics. You are the reason why I take the time to keep this blog going.

Five years of rackerhacker.com is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

My main purpose for the blog at the beginning was to create a place where I could write quick articles about problems I found and how to fix them. Most of the people around me were using their own handy systems to store notes (Stickies on the Mac, Tomboy notes on Linux, or just simple text files), but they weren't able to share them easily. I wanted a way to write up a solution and instantly share it with someone. I also wanted that person to be able to pass along the fix to someone else if they wanted.

Needless to say, it took off from there.

It's important to note that I couldn't have done this by myself. I've learned some efficient strategies for managing large systems and troubleshooting complex issues from my peers, my managers, and colleagues outside of Rackspace. There have been many triumphs and there have been quite a few failures.

The failures have taught me the most. I've made some pretty large mistakes and here are a few:

• inserted data into a MySQL slave in an active replication pair
• run a fsck on an online ext3 partition
• marked a failed drive online in a hardware RAID array
• mangled Plesk installations in ways that you can't comprehend
• typed 'reboot' into a terminal and pressed enter, only to realize I was in the wrong terminal
• ran UPDATE statements without a WHERE clause in MySQL (well, I only did this one twice)

Even after all that, people occasionally tell me that I'm very good at what I do. I don't know if that's true or not, but I'm glad some people think so! Many of those folks end up asking me this question:

How do I learn how to be a successful Linux systems administrator?

My answer is this: Be humble. Always be thirsty for knowledge. Don't be afraid to make mistakes. Love what you do and the people you serve.

400th post: Looking back at where this blog started is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Movember 2010

The Movember Foundation currently passes along the proceeds to the Prostate Cancer Foundation and LIVESTRONG.

If you'd like to make a donation, you can do that on my member page.

Raising money for prostate cancer research and survivor support is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

After the post went up, I received as much feedback from people outside of Rackspace as I received from Rackers.  The negative feedback I received was centered around the assertion that the post's content was "fluffed" to make the Rackspace experience seem better than it actually is.  That couldn't be further from the truth.

If you want to make comments on the post, or if you want to know more about working at Rackspace, let me know.  Although I'm not in sales and I'm not in recruiting, I always enjoy talking to people about using Rackspace's services or working for Rackspace.

Here's a link to the post: Rackspace Talent - Why I'm a Racker

Why I'm a Racker is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Call to undefined method wpdb::has_cap() in schema.php on line 22

Even though I followed the instructions on the WordPress site, and I disabled all of my plugins, the error kept appearing. The only parts of the site that remained unchanged after the upgrade were the wp-config.php page and the wp-content directory. I merged the changes in wp-config.php, but the error was still present.

In frustration, I renamed the wp-content directory to a temporary name and uploaded the wp-content provided from the WordPress tarball. The upgrade completed without a problem! I deleted the new wp-content directory, put the old wp-content directory back in place, and WordPress sprang to life!

It's certainly possible that a WordPress plugin blocked the upgrade process even though it was disabled in the database.

Upgraded to WordPress 2.7 is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Leave a comment and let me know what you think of the changes. Have a great weekend!

New look is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Here's the exact numbers as of tonight:

2008 Year to Date:

• Sessions: 501,166
• Pageviews: 2,506,011
• Hits: 7,414,333
• Bytes Transferred: 65.19GB

2007 Totals:

• Sessions: 65,849
• Pageviews: 427,923
• Hits: 1,199,403
• Bytes Transferred: 36.22GB

Thanks to everyone for making this blog so popular! It started as a simple place to stash knowledge that I've gained during my work as a Linux systems administrator, but it's turned into something that helps people around the world with their daily work.

Thank you!

Thanks for making RackerHacker so popular! is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.