Technical writing is so much easier when you are told what to write about, as opposed to having to come up with an idea yourself. However, oftentimes this responsibility falls square on the shoulders of the author (as it should, usually). Such is always the case for editors of technical Web sites who place themselves in the precarious position that I have: namely, I have a weekly newsletter that has paid subscribers, and the newsletter contains fresh content. Translated this means that I need to come up with a new idea for an article and create an article based on that idea at least once a week. And by a week I really mean within two to three days, since I usually don't sit down to start the newsletter, which goes out on Wednesday morning, until Sunday or Monday. (Of course creating a newsletter once a week isn't nearly as hard as what I did my first six months running 4Guys - then I had a newsletter called WebDaily, which, as the name implies was sent out every freakin' day.)
One option is to merely offload the work to someone else. As any sane Web editor will tell you, it's a smart move to solicit other authors to write for your site. Of course, depending on the author, the job of editing the author's work can be exponentially more time-consuming than creating an article from scratch! In any event, over the years I've served as the 4Guys editor, I have received a number of potential author candidates who were excited about giving back to the community by writing for 4Guys, but were plumb out of ideas and wondered if I had any. As you can see, coming up with ideas can be tricky!
In my experience, I've found a number of tactics helpful for coming up with ideas. The fist tactic, which is the simplest and best, is to use real-world ideas. That is, you're working on a project, you hit a snag, bang your head against the wall for hours on end, and then finally come up with a neat work-around or solution. These types of things are great material for technical articles. However, events like this do not happen on a regular basis for me, especially since writing, consulting, and teaching are my full time job - that is, I'm not at a company developing all day.
Failing any real-world experiences, the next place to turn is online messageboards, email listservs, and newsgroups. I'll spend maybe half an hour digging through recent posts, trying to find some good questions that make me think, "Yes, answering this problem would make a great article." Those are nice too, because you can forward the article to the person who asked the original question, so it's like you're directly helping someone out. Positive karma and all. And, if you already spend significant time browsing through these resources, then oftentimes you know what the common questions and problems developers are asking and facing, and can bypass the actual searching through the resources.
If no online questions do the trick for me, I'll turn to existing articles on other resource Web sites. No, I'm not looking for ideas to copy, rather I'm looking for neat solutions that have potential to be enhanced, or explained in a different way. For example, I might find an article that's short on explanation and long in code on how to perform a cool task. This makes a great basis for an article. I can start off the article like, "I recently read so and so's article at such and such URL, where she described how to do this and that." And then I can delve into a more rigorous English explanation, show a different way to solve the problem, and do so using a different language (if the article was in C#, I'll show it in VB.NET, or vice-a-versa).
Finally, if all of these techniques fail, as a last resort I'll recycle material from a past book of mine or from the course material of a past class I taught. Mind you I don't just copy text from an old book, but I'll take an idea I discussed in a chapter in a previous book, and write a new article on that material. This is usually the quickest writing job on my side, but it sort of feels like cheating. Plus, it's more fun to come up with a new idea or concept or slant on an existing article/question, than to merely rehash old material.
All of these past approaches essentially take something that I've or someone else have worked on before, be it a real-world application, someone else's question in a newsgroup, or someone else's article, and adds explanation to provide a useful article. However, the ideal situation is to come up with fresh, new content. For example, when writing magazine articles or books, oftentimes I need to come up with "new" ideas, or new ways to explain the standard material. For example, I recently finished an article for Microsoft's online MSDN Web site. I was asked to write about ASP.NET and XML. Now, even though I had a braod topic, I still had to spend some time thinking on how to formulate the article - what examples would I use? What direction would I take the reader? How would each section segue into the next? I find that thinking about this stuff while driving, showering, lying in bed before falling asleep, or during any other low-key "downtime" is ideal.
Coming up with new ideas is not only difficult, I've found, but also time consuming, because they can involve significant development time. For example, for the MSDN article I decided to step the reader through creating an news aggregator Web application, seeing as how this touched upon many pertinent XML and ASP.NET topics, like accessing remote XML documents, displaying XML data on an ASP.NET Web page, and translating XML data with XSLT stylesheets. Once I decided to go with this approach, and mulled over the organization of the article, I still had one big task in front of me: writing the application itself! Granted, an online news aggregator isn't rocket science, but it took up a full day to create the application.
Coming up with new ideas is definitely the hardest approach, and rarely makes its way into the weekly articles I write for the Web site (seeing as I usually only have two to three days to create the Web site content due to the looming Wednesday deadline!). I try to save the new ideas for books and magazine articles, unless the new idea can be quickly converted into an article, but usually it takes some time to mull the idea over in my head for a while before I begin writing. Furthermore, working with new ideas usually requires more editing time during and after the writing process, and when you have two to three days to wrap everything up, oftentimes this is not sufficient for more involved new ideas, some of which may require significant development time before I can start writing.
To summarize, there are a number of venues I examine when trying to come up with ideas, from using inspiration from real-world problems I've encountered, to directly trying to help a person who has posed a question to the online community, to enhancing an existing article or tutorial, and, finally, to rehashing old content. Ideally, each week I'd have the time, energy, and interest to come up with new ideas and concepts to write about, but typically there isn't enough time in the day for this sort of thing.