I give a talk that advocates writing. I do this because I owe my career to people who wrote down what they knew and made it available in one form or another; either free on a web site, or in a book that I bought.
When I started editing, one of my jobs was to encourage people to write for whatever publication I was working for at the time. I’m now Editor in Chief for Python Magazine, and I’m back in the role of encouraging people to make their knowledge available for others (including me!)
Python Magazine is going well in terms of authorship, but with all of the Python coders out there, I should be overwhelmed with article proposals! When I talk to people who clearly know what they’re doing, or are doing something cool, and ask them to write, the responses are, by now, pretty predictable – and mostly based on misunderstandings, myths, and other untruths. I thought I’d take a few minutes to address the most common ones here:
“I can’t write”
The king of reasons for not writing is this one. The problem isn’t really that the person literally cannot write. The problem is twofold: first, the person has absolutely zero confidence in their ability to write. Second, the person doesn’t understand what an editor is supposed to be doing to earn his keep.
I’ll tackle the second part of the problem first: an “editor” is not some gray haired guy with a cigar screaming about deadlines and rejecting 99% of everything that hits his desk. An editor is someone who works *with* writers. It’s not *supposed* to be an adversarial relationship – and it *is* supposed to be a relationship. It’s supposed to be a working relationship where the writer tries to relay concepts in a way that the *editor* can understand. In return, the editor asks questions, pokes, prods, and makes suggestions that help morph the article into something the *readers* will understand.
Further, the relationship may begin before a draft is ever submitted. I’ve helped lots of writers develop their *abstracts*, so that by the time they sit down to write the article, they have some clear idea where they’re headed. And the word is *helped*, not *dictated*. It’s not me passing back a marked-up copy and saying “fix this and do that”. It’s me writing back saying “I’m a little confused in this part, how does this work?” or “can you provide a use case in which someone would find this useful?”
Finally, this excuse may have foundations in a perceived language barrier. If English is not your first language, you may feel like you’ll never get published in an English publication. Not true. If you have the knowledge, and can write enough English to relay the concepts, a good editor will work with you to develop it into something suitable for publication. It may take a bit more time, but that’s usually not a problem. In technical publishing, knowledge trumps prose every day of the week.
“I don’t know what to write about”
One day while you’re coding, just stop. Stop and take stock of what you’re working on. In all likelihood, there’s an article in there. If you’re thinking “there are a thousand articles about this already, in addition to the online docs”, you need to know three words: “Fresh, relevant content”.
A thousand articles have been written about just about everything! Why do you think that is? In the tech world, it’s because technical people tend to pay close attention to the date of publication to figure out if the content is fresh and relevant to the current version of whatever they’re using. Because technology evolves, there is often a need to get updated information to the readers.
The other part of this objection is the idea that the reader can get the same information from online documentation, or that what you might write about is just too easy for anyone to find useful. This is usually based on an assumption that because the writer learned it in an hour reading online docs, that everyone can/will/wants to learn that way. I hate online documentation, especially for programming languages. So do lots of other people. That’s why people buy enough technical magazines for my publisher to let me head up another one!
Also, people read about things in magazines that they may otherwise never read about if it were online, and they get inspiration from these things on occasion. Why? Because it’s there. When I go to get my oil changed, I bring a magazine with me to read while I’m waiting, and I read stuff I wouldn’t normally seek out online because I have time to kill. When you see people at the DMV (or MVS, or wherever people go to get their licenses renewed or cars inspected), a lot of them have magazines with them. They have time to kill. Inspiration can come from the strangest places. So whatever it is you’re doing, write about it, and inspire someone to take whatever it is you’re doing and do something else cool with it. Even if it’s, say, the Python tempfile module or something mundane like that
There are three things I tell people about where to find article ideas:
- Write about stuff you know/do – this is a gimme.
- Write about stuff you *want* to know/do – You don’t have to be an expert on Twisted to write an article about it. If you’ve done some network programming with Python at all, and are wanting to get into Twisted, research doing what you want to do with Twisted, figure out if it’s a good choice, do a proof of concept, take some notes, and write an article based on what you’ve done!
- Write about stuff that is not done, or often done wrong – Best practices documentation is severely lacking. There are a trillion articles that talk about different ways to do similar things, but very, very few articles that say “Here are three common ways this is done, and here’s why this fourth way might be better” or “Here are the pros and cons of doing this using 2 different methods”. Because best practices documentation is lacking, things are quite often done in a suboptimal way. Articles like “How not to do web programming with Python” might cover why you don’t want to use the split() function to parse URLs, for example
More on the way
I’ll expand on these and address more common reasons for not writing in future posts. In the meantime, if you’d like to give writing a shot, and you write a decent bit of Python code, I invite you to come and write for Python Magazine. I look forward to working with you!