Jun 192009

Lately I’ve been thinking more about my place in the developer relations team at Mozilla. It’s sort of an odd place for me to be, sometimes. While my work managing the Mozilla Developer Center is obviously a component of developer relations, in past organizations I’ve worked in, technical writing was actually part of the engineering group.

Developer relations

Sometimes while I’m sitting in meetings, I find myself feeling vaguely adrift, since a lot of what goes on doesn’t all that directly relate to what I’m doing on a day-to-day basis. While my work involves interacting with developers, it’s generally on a different level than most of the rest of developer relations. I’m more interested in getting down information than in what exactly people choose to do with it.

To be honest, the sort of public relations work that a lot of developer relations involves — while incredibly important — isn’t really my forte.  I’m glad we have a bunch of folks that are both good at it and enjoy it, because that’s certainly not me!


On the other hand, attending engineering meetings can be an interesting experience for me. As a writer, I’m in the complicated position of needing to know what’s coming while avoiding knowing too much about things that are in a state of flux.

For example, let’s say a new technology is being introduced in the next version of Gecko. Great! I’ll need to write about that, of course.

The problem is this: when do I start studying up on it? If I start learning the technology too soon, I risk learning details that may change over time, requiring re-learning stuff later when the specifics change.

This happens fairly often. For that reason, I try to wait until a technology appears to be entering a relatively steady state before starting to learn details about it, let alone write about it. There’s probably nothing as frustrating as writing documentation about something only to have to redo it all because of drastic changes to an API.

However, I have to balance that with the need to have the documentation ready by the product’s ship date, and preferably by around the time it enters beta, so that developers have the material in hand when they need it.

It’s a tricky fine line to walk, but I like to think I’ve mostly done a good job of this. Our documentation for the releases of Firefox (and by extension, Gecko) that we’ve shipped since I joined Mozilla four years ago has generally been pretty good. Especially given the enormous amount of material there is to cover!

Between worlds

So basically, I sometimes feel sort of adrift between engineering and developer relations. Maybe that’s the right place to be. I don’t know. I suppose it helps to ensure I’m in touch with everyone I need to be dealing with.

But occasionally it can be slightly frustrating, too.

I’m not sure there’s anything that can be done about that. Writing developer documentation is a strange world to live in. It’s exciting and rewarding work, though, and I feel like I found my calling when I took my first technical writing job, which, ironically, I took because it was the only job I came close to qualifying for at a company I badly wanted to work for, and not because I was specifically looking to be a writer.

 Posted by at 2:00 PM

  2 Responses to “A technical writer’s place in the world”

  1. but I like to think I’ve mostly done a good job of this

    I’d argue that you’ve done an awesome job of it all.

  2. I really know this feeling! Playing a bridge/buffer role between two or more worlds is a hard job, since you don’t fully exist in either if you do it right. I feel this way all the time with the education stuff. I find it helps to spend make sure I work on technical things in parallel to the education piece, so I not only keep sharp, but also keep in touch and relevant with the people on that side of the divide. I have lots of empathy for you, and would echo Blair’s words: you’re doing some great work.


This site uses Akismet to reduce spam. Learn how your comment data is processed.