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.
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!
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.