How and why  I write articles

I’ve written a lot of articles over my more than fifty years in IT—most of them since I started using Linux in 1996. Without doing an exact count, I can safely say that the total is over 150 articles.

Over the years, people have asked me how I decide what I’m going to write about and about the process I use. This is my process:

Choosing a subject

Although an image of a writer wracking their brain to come up with an appropriate subject for an article comes to mind, that’s not how it works—for me at least. I have little trouble finding things to write about. Sometimes the problem is sorting through the possibilities to choose the ones that belong high on my list. I very seldom discard a potential article but they can get bumped down in priority.

For example, this article was conceived during an email exchange with Jim Hall. Jim had already interviewed me about the process I use for writing my books. In order to maintain the focus of that article on my books, we didn’t even touch on my articles. So when he shared a prompt for articles for Technically We Write, I suggested that I write an article about writing articles.

Editors send out requests for articles to their writers about specific subjects. This is a common practice and the requests can range from looking for a single article on a single subject to something more general like, "Pi day is coming up. Please write an article about how you use your Raspberry Pi." Or something similar. Other requests I’ve received included articles to celebrate the birthday of the Linux kernel, the top X software packages for any of a number of types of software like accounting or office suites, and much more.

I have sometimes written articles as a result of those requests. However I have a foolproof method for picking subjects. It usually starts with my mistakes—or at least with the problems I encounter while doing my systems administration job.

Yes, mistakes and problems. I have made many mistakes and encountered lots of problems. All of which I have had to resolve myself.

Those problems, including and especially the ones I created for myself, and their resolutions are the best source of my articles. I find that if I have encountered a problem, others will too—and they’ll look for a solution.

Getting started

But I didn’t start out by writing articles.

At first, I started keeping notes recording the problems, how they came about—especially the self-inflicted ones—and how I fixed them. These were simple notes with a description of the problem and usually a bit about how I performed problem determination. I also described the details of how I fixed it including any failures.

I started this in a paper notebook I kept many years ago. As more notekeeping options became available for my computer, I moved first to a note-taking application and then to a simple database. At that time, I was working in the IBM PC Company support center, so I started sharing my database with others over the simple network we had.

After leaving IBM, I continued to keep notes on my PC using various tools. This eventually led to a large Lotus Notes database, primarily about IBM hardware and OS/2, which I shared with my consulting customers.

Eventually, I realized that OS/2 was stagnating. I decided to switch to Linux because that seemed to me, in 1996, to be the best and most exciting software around. There’s a long story about how that all happened, but I won’t bore you with it here. The point is that I started doing with Linux what I had done previously with IBM’s OS/2 operating system.

Getting them published

When I realized that other people might encounter the same problems with Linux I had, I began publishing those notes on my own websites. In 2013, I went to my first All Things Open conference and got in contact with the editors at Opensource.com. That was a great place to publish my articles, and I started writing for them.

Because my notes were just that—collections of notes—I needed to add some context to make them more understandable to readers. So I added stories about how I encountered the problems and how I performed problem determination to locate the root cause. I also added more readable descriptions of creating and implementing the solution. This tied it all neatly together in a readable narrative.

Those articles ranged from fun to deeply technical. But most tended to be based on my own experiences.

I became friends with many of the authors and staff at Opensource.com. We shared a lot of things, including our love for Linux and open source software as well as our deep commitment to sharing our knowledge.

When Red Hat stopped adding new content to Opensource.com, I started publishing my own articles—as well as those of other former Opensource.com contributors—on my own website, Both.org.

Final thoughts

I have many things to write about. That’s in part at least, due to the fact that I am a hands-on person. This is kind of the nature of Linux system administrators: we like to play with the toys. It also provides us with a steady stream of fun things to write about.

No matter how trivial something seems to you, there are always plenty of people who want to read about it. So if you find yourself thinking you should take notes about something you just did, or that others might benefit from your newly gained experience, go ahead and write the article. Then submit it to an appropriate place—or just start your own website if you can’t find a suitable venue.