I transitioned from software development to technical writing because, after an hour of coding, I was super fatigued. So I was looking for an easier way to make a living — and, like all programmers, I thought that writing was “easy”.
I’m happy for the change, because it gave my career a whole new lease on life. But as for “easy”, you should know that I was 100% dead wrong. And only later did I find out that my fatigue resulted from the fact that I needed glasses!
Contents
Coding vs. Writing
When you’re coding, you spend a few weeks or months in an intensive design sprint. That’s hard. It’s mentally draining, but very rewarding as nebulous ideas begin to come together. Then comes the easy part — coding a new feature, testing, fixing bugs, and then coding another feature.
As I coder, I could (and generally did) spend 12 hours a day coding. It was fun — like solving crossword puzzles, with lots of little breaks as you watched the compiler spit stuff out and as you ran tests. But design work — that was hard.
Writing, it turns out, is like the hardest design work you have ever done — day after day after day, without letup.
Expectations
The good news is that no one in the technical fields expects you to know a lot. For one thing, that gives your career a lot of longevity, because you don’t have to be the technical hotshot you maybe used to be in your younger years. And when it turns out that you do know stuff, you become something of a minor deity — because writers with a strong technical background aren’t all that common.
The Process
Now then, if turns out that you have one of those good project leads who really knows how to explain stuff, writing is a cinch. You still have to figure what to say and how to say it, but the sequencing of concepts and a basic introduction to them are nicely laid out by the project lead.
When you don’t have a good project lead, things become about 3 times harder. First, you have dig into the technology enough to discover the fundamental concepts. Sometimes that means a lot of homework. Sometimes, a lot of experimentation. All of the time, it’s some combination of the two — and a lot of it. Next, you have to figure out the best sequence in which to introduce those concepts to your audience. Then, you need a concrete example you can festoon the explanations around, like baubles on a Christmas tree. Again, a good project lead will already have examples you can use. Lacking those, you need to come up with one of your own.
Finally, after acquiring the basic understanding, outlining a presentation sequence, and devising an instructive example, you can begin doing the writing. So in general it’s a four-step process, where each of the initial steps can take a minimum of 2 to 3 weeks, or as little as a few days (with a good project lead who doubles as a speaker and a writer).
At that point, you can begin doing something that most people regard as “writing” — figuring out which words to use (and what illustrations are needed to help them make sense). But again, as simple as that seems on the surface, you’re effectively doing “design work”, trying to pull concepts out of the air and get them down into some kind of semi-concrete form.
Remember that guy who used to code 12 hours a day? Well, as a writer, a six-hour day is a really good day. Four hours of productive work is more the norm. Everything else is talking to people or processing email. Because it’s just really hard to do that kind of mentally intensive work every day!
It Takes a While
I was able to become a writer because my managers at Oracle had come to the realization that it was easier to train a technical person to write, than it was to train a writer in technology. So they gave me an opportunity to start writing.
Now, I had always written. A lot. Ever since High School. But while I put many, many words on paper, I can’t honestly say that I was a good writer. In fact, my early drafts had so much red ink poured on them that you could barely see the black text underneath! For every page I wrote, I had 120 corrections to make. Grammar errors. Punctuation errors. Spelling errors. Missing words. Bad arrangement of words. Better ways to present information. Elimination of repetition. And on. And on.
After correcting the same dumb mistake 100 times in a single manuscript, I eventually stopped making that mistake. Multiple by 100 common mistakes, and after a year or two most of the really dumb ones were ironed out. But the important point is that it took that kind of detailed oversight to produce a usable work product, and to begin learning the craft.
With most of the brain-dead errors ironed out, that left more “thoughtful” errors, where I could explain things more simply, or more clearly. Another couple of years, and those became fewer, as well.
By now, proofreaders were helping me find typos, and there weren’t many really major errors left. But I can’t say that I was really a “writer”, just yet. I was writing help systems, mostly. And they were good, but they weren’t the great American novel.
Then I had a chance to write the JBuilder Java Bible. To do that, I worked with a professional editor by the name of Matt Lusher. That was a long project — much longer than I had anticipated — but in the process, I really found my writing voice. Thanks to Matt’s edits, I began to really visualize the person I was talking to on the other side of the computer screen, just as I am talking to you now.
It’s hard to explain what the difference was, but I can tell you that no English teacher and none of the professionals I had worked with up until that time ever gave me edits like he did. If I could encapsulate his process in a phrase, I would say that he was developmental editor, who was coming at the book from the perspective of a reader — and that he knew what kind of changes to make, to make the explanations as clear (and at the same time as comprehensive) as possible.
In all, the process took a good 8 to 10 years. At the end of it, I could honestly say that I was, indeed, a writer. And it has been rewarding. But there was a heck of a lot more to it than I expected.
