Generating Topics for Technical Articles

A couple of weeks ago, I was minding my own business on a Sunday morning when I received a cold email from an editor to write for their online publication. After doing some research, I figured out that the offer was legitimate and wrote back. After a brief exchange, I was pumped about the prospect of writing for them! However, the latest email had the dreaded phrase "pitch me on a couple of topics." I opened up my trusty ideas.txt only to find it devoid of topic suggestions. I only write original content on topics where I have interest and experience, so it took some frantic brainstorming to find something worthwhile. When I pitch a topic, I do enough research to make sure that I can write a complete piece that doesn't exist elsewhere, so it's a non-trivial task to concoct multiple pitches. Even with recurring clients, I have trouble coming up with strong topics that meet their needs off the top of my head.

I write technical articles on software development for a variety of clients. When I started, I had a few article ideas in mind, and every once in a while when inspiration struck I would add to the list. As my client book expanded and I worked on larger projects and series, I found myself coming up blank when asked to pitch new article ideas. Recently, I developed an exercise for developing quality ideas that helped me generate 20 solid pitches to use over the coming months in a single planning session, and I hope it will be useful for you as well.

Seven Questions

Sit down with your favorite ideation medium (pencil and paper, your TODO manager, your favorite text editor) and about 15 minutes. To generate ideas, ask yourself the following seven questions:

  1. What programming languages do I know well enough to write about?
  2. What frameworks within those languages do I enjoy using?
  3. What company-specific technologies do I know well?
  4. Who are my clients and what topic domains are they interested in?
  5. Who would I like to land as clients and what topic domains are they interested in?
  6. Which topic domains am I interested in?
  7. What relevant prior projects have I done?

The first three questions guide your exploration into your areas of expertise. I always learn while writing articles, but I try to base each pitch in one of my areas of experience. Most clients will be interested in only some languages and frameworks, and with the exception of broad platforms like AWS you probably won't have much luck writing about company-specific technologies for third parties.

If you don't already have clients, skip question 4, if you aren't looking for new clients, skip question 5. For questions 4-6, a "topic domain" is an area like "data science" or "front-end web development," that is, it's not technology-specific. While what clients say they want is an important filter for pitches, these questions are here to expand your list of ideas, not constrain it.

The last question is the most important. Most of my articles and article ideas come from prior projects. Sometimes, I take the skills I learned and apply them to new sample code, but sometimes I'm able to repurpose old work as sample code. A project in any domain gives you the experience that you need to write about that area with confidence. Projects don't have to be intense: weekend scripts, hackathon projects, and schoolwork fill my list alongside the fewer large projects that I've worked on.

Using the Answers

With your answers in hand, it's time to write titles. Try for as many titles as you can, even if some overlap or seem insubstantial. Here's an example of how I generated a title from my answers:

For questions 1 and 2, I had Python and Django at the top of the respective lists. My topic domain list for question 6 included MVC web dev. In question 7, I listed an early long-term project of mine that contained several disastrous mistakes with Django migrations. Also, thanks to a recent class project where I was working with a team unfamiliar with database migrations in RoR, there were issues stemming from direct editing of migration files. Combining these led me to the title "Ensuring Correctness in Django Migrations."

My rule of thumb is that a technical article, tutorial, or guide is 2,000 words. After coming up with titles, see if you have any duplicates or topics that can be combined, or if any of your topics are too broad to cover in that length. Doing the work of estimating length up front can save you from pitching an overly complex topic or running out of things to say 500 words in.

To make sure that I remember my developed idea, I included a 2-sentence outline of the article under the title in my notes. For the Django migrations idea, the general structure is to discuss best practices, then provide examples of how to recover from errors of various severities. If you're newer to technical writing, you might want to develop a more substantial outline to determine if the topic is of an appropriate length and complexity.

Finally, you'll want to validate your topic with some searching. The market research phase is incredibly important because it's better to kill an idea that you've spent five minutes on than a draft that you've spent five days on. If your idea turns out to be wholly original, then that's great, but you'll need to do extra research to make sure there's an interested readership for it. Finding other articles on your topic isn't a bad thing, on the contrary, it means that you've identified something interesting enough for other people to write about. That said, if there are hundreds of articles, books, videos, and other resources on the topic (for example, say you want to write a general introduction to programming in Python), you'll have to carefully consider your angle to stand out from the crowd.

With your list of articles in hand, it's time to start pitching your clients and writing outlines. While passive ideation and occasional inspiration are great sources of insightful content ideas, after running this exercise I have confidence that I'll be able to keep my content pipeline full for months and, when it's running low, I can work through these questions again.