They are merely going to the developers asking them what the feature is supposed to do, and then they put the developers words into writing, perhaps adding a title and some bold text.
Ever thought like this?
The fact is that this is the same way people sometimes reason around testers.
Anyone can do testing, just put someone in front of the product and let them click around, or give them scripted test cases. Anyone can do testing.
Why do people end up with these narrow minded views on other peoples work?
Apart from the rock star "The Developer", there are other roles in the software industry that face the same type of prejudices.
For instance the configuration manager.
Anyone can do that right. It's just a human file handler in the end?
The reason we end up with these prejudices is because of the lack of insight into other peoples work and what separates a good tester/configuration manager/technical writer from the mediocre one, or even the lousy ones.
And also perhaps the lack of working with really excellent ones, and just having been exposed to lousy ones.
I have for example had the privilege of working together with what is probably one of Swedens best CM persons (however you define that), Christian Pendleton (@chop_se) at Softhouse.
Working close with him gave me some insight into how you do "good CM", what he as a CM is interested in, and how he stays up to date with his craft.
So far I haven't worked close with a technical writer and so I'm struggling to understand what separates a good one from a mediocre one.
But the fault is at my end and not the other way around, I have never done any technical writing, apart from when absolutely forced to do so for my own code.
These roles have been around for a very long time and probably so for a good reason.
Although I'm sure older readers can point out other roles in the software industry that existed a few decades ago but has since become extinct and obsolete, i.e the IT industries equivalents of Copy boys and Elevator operators.
Over the last years Scrum and Agile has been on the rise and the misconception of cross-functional teams have gotten more spread in the industry.
Now don't get me wrong, I love the idea of cross-functional teams, what the idea represents, and I have advocated it heavily throughout the years.
But the original idea behind cross-functional teams is that you have experts in the team that can raise the competence level of your fellow team members so that they can help out with simpler tasks within the experts domain.
But I've encountered too many managers too count that thinks cross-functional means that everyone should be able to do everything.
I've seen organisations where you remove titles/professions like developer, tester etc, and replace those with one title "designer", and having the expectation that a designer should be able to do test, cm, technical documentation and yes most importantly code, because that is what matters in the end right, pushing more code into the version control system.
This is both tragic and wrong since it takes away peoples pride in their craft and is sending the signal that anyone can do your work, and that you shouldn't bother getting better at it.
Such companies either have to employ super-generalists that can do a little of everything, with the result of poor performance, or through some miracle find teams, departments of super-generalists (super-heroes) that can do everything really well, meaning they have to pay through their nose to hire such people, if they even can find them. Most of the time its the first option they go with and suffer accordingly.
We need to realize that roles that has been around since forever is probably there for a good reason.
But also remember that they can evolve over time as well.
For example Elisabeth Hendrickson (@testobsessed) recently gave a beautiful quote in her keynote at CAST2012:
"Testing is only dead if you're trying to find something that looked like testing in 1998"
In the end it all comes down to this. The less we know of someone else's work, the more we tend to think of it being simple and replaceable.
So the next time your taking a coffee break with your technical writer or configuration manager, take an interest in their work and try to find out what separates excellent ones from the mediocre ones and how they stay up to date within their profession.
Because frankly we can all benefit from knowing a bit more about other crafts than just our own.