New to tech-writing, or considering starting? The secret to success is acknowledging that tech-writers are an essential evil.
Tech-writers are essential because somebody needs to write the user doco. The developers and managers sure as hell don’t want to. This is in fact part of the factor that you’re wicked, too. In my experience, the majority of programmers and managers believe that they could write the manuals if they wished to … they simply don’t wish to. They may not compose all “flowery” like the tech-writers, but what they write is proper.
Unfortunately, that’s quite often all that’s essential to developers and managers.
There is a sensation within the software application environment that precision = quality. Audience analysis, doco readability, consistency, usability, active and passive voice, commas in a list of 3 or more items … All of these things are reasonably unimportant to everybody however the tech-writer. Oh … and the user.
In a world where precision is all important, a lot reviews the head of the dummy. I do not know if it’s intellectual snobbery, however programmers and managers seem to think that if they comprehend it, so needs to the user. It does not matter whether they do … they SHOULD! Dumb users! Maybe it’s the geek’s ultimate revenge …
Your document can be 100% precise, but if the audience can’t read it, you’ve squandered your time.
So why does not anybody acknowledge this? They do! That’s the strange part. In theory, everybody concurs with you, it’s just in practice that you discover yourself out in the cold. I don’t know why this happens. Possibly it’s due to the fact that most of these guys have never done tech-writing.
So tech-writers invest too long fretting about unimportant things. And they bother developers and supervisors with unimportant things. However they’re necessary things. Otherwise why would you be employed. Possibly the absence of easy logic short circuits their brains. Who understands?
What we can leave this is that there’s a sensation that tech-writers waste time, and as a result, they’re basically at the bottom of the heap in the software application world. I believe an excellent analogy is the method some abundant see the bad. Unclean little animals … if only we might do without them …
But there is an up-side. I do not want you believing it’s all bad.
Being at the bottom of the heap has its benefits. You can go undetected for years if you desire. If you have not seen the motion picture, Office Space, you should hire it. There’s a little ferrety bloke because who was “release” years ago. Problem is, nobody ever informed him, and since of a problem in payroll he still made money. No one ever observed.
Being a tech-writer’s a bit like that.
When I was managing doco groups, my preferred stating was “All we have to do is handle their expectations and our dedications”. Due to the fact that developers and supervisors resign themselves to the fact that they do not know what’s going on in the doco team, there’s in some cases a temptation to ease off. Don’t succumb to this temptation!!! If you ever get caught, doing it, it’ll be like the young boy who cried wolf– they’ll never think your estimates again!
The other risk is that you’ll lose your sense of seriousness. Which’s a big part of what makes a great worker. You need to be very rigorous about managing your dedications. This needs discipline, since often it seems you’re the only one that cares, however you need to do it.
Something you should understand however, is that your typical tech-writer in software spends only about 50% of his or her time composing. The rest of your time is invested preparation, problem fixing, repairing your computer system, researching, interviewing the developers, writing work pracs …
I always discovered it was a great balance, though.
It was when I started handling teams that the bottom truly fell out. Then the percentage dropped to about 10-20%. There were times when I ‘d go months without composing any help at all. That can be very frustrating, specifically if you don’t especially like managing.
Now managing tech-writers in software is a fascinating thing. As with most technology management positions, you kinda fall into it, because you’re the most senior/experienced individual in the business. Unfortunately, that does not certify you to be a manager. Software application business are renowned for dumping people into management roles with no real training or assistance.
I don’t really have any suggestions for you here. If it’s gon na take place, it’ll occur. Simply understand it, and know that if you fall under a management role, it’s gon na be tough. (That’s not to say that it can’t be gratifying though …).
The paradoxical thing is that the most tough aspect of it is that your personnel are shouting at you to change the system. “The programmers don’t answer our concerns!” “None of my work has been reviewed for the last 2 months!” “The job manager just informed me to forget quality!”.
Unfortunately, the inexperienced tech-writer is typically naïve adequate to believe they can change the system. When you end up being a supervisor, you know you can’t. Hold on a minute … Maybe apathy is what certifies you to be a manager … Hmmmm.
In any case, my suggestions is not to press too tough. You’ll make life tough for your supervisor, and give yourself a bad track record. Recognise you’re a needed evil, and work within those constraints.
Tech-writing can be a lot of enjoyable. And do not let anybody inform you it’s not innovative. Trying to think of a way to describe what goes in the Name field without just stating “Enter the name” is a genuine mind-boggler!