Looking for something?
By Ben Davidson, Chapter Member
For those of us in the field of technical writing who didn't come at this from a computer science background - raise your hand if you’re an English major! - we’re often introduced to unfamiliar technologies and terminology at the start of a project.
It’s understandable then that some of us might want to keep quiet and stay on the sidelines until we feel that we better understand what the developers are discussing. I’d like to suggest that doing so will lengthen the ramp-up time, and that engaging with the team and the product(s) as fully as is reasonably possible, might shorten this ramp-up time.
How then to do this, without being the one asking newbie questions all the time?
Even before you attend your first scrum (assuming you are in an Agile environment), be a detective and hunt down and view all available info about your product: wikis, training videos, customer training or collateral, etc. If your company records training sessions or presentations, find those as well. Sometimes at large companies, this information is scattered across several directories.
If you aren't given hands-on access to your product (be it hardware or a software environment), politely ask for it. Don't be afraid to follow up on this request. Hands-on access is vital, even if it’s for a prior release that doesn’t include the features you will be documenting. Of course, if you are writing about a 1.0 product, the software might not yet exist. Sometimes, however, the company has a similar product, say for a different operating system. Using the tool while referring to preceding user documentation (if it exists) is extremely helpful.
Now that you’ve done your homework, you’ve probably got a better idea of the kinds of worthwhile questions you can ask, and have at least been introduced to relevant terms and concepts.
Thus armed, you are at least attending those first scrums and developer meetings with a basic level of knowledge. Even so, you still might find yourself feeling a bit lost. That’s probably to be expected. Keep attending. You’ll learn the concepts and language more quickly if you immerse yourself in your new environment, and you will also get a better sense of those things you most need to know. You will also show up on the radar of the rest of your team and begin getting to know them. Write down unfamiliar terms, record the scrums (a topic I've written about before), and don't be afraid to ask about possible doc or user impact for anything you hear, within reason of course. Another note about recording scrums: I've found it helpful to listen to the recording soon after the scrum, and to summarize discussion on issues that have publication impact. I have a Word document I've called "Scrum Items," and the information I add to it allows me to follow-up with the devs on relevant issues. I'd never be able to rely solely on my memory to capture such details!
There are likely more things a tech writer can do to speed up the learning process. If you know of any, please share them in the comments section below. Thanks.
Ben Davidson can be reached at benddavidson99 at gmail dot com. Read more articles by Ben Davidson.
Ben Davidson
It’s understandable then that some of us might want to keep quiet and stay on the sidelines until we feel that we better understand what the developers are discussing. I’d like to suggest that doing so will lengthen the ramp-up time, and that engaging with the team and the product(s) as fully as is reasonably possible, might shorten this ramp-up time.
How then to do this, without being the one asking newbie questions all the time?
Even before you attend your first scrum (assuming you are in an Agile environment), be a detective and hunt down and view all available info about your product: wikis, training videos, customer training or collateral, etc. If your company records training sessions or presentations, find those as well. Sometimes at large companies, this information is scattered across several directories.
If you aren't given hands-on access to your product (be it hardware or a software environment), politely ask for it. Don't be afraid to follow up on this request. Hands-on access is vital, even if it’s for a prior release that doesn’t include the features you will be documenting. Of course, if you are writing about a 1.0 product, the software might not yet exist. Sometimes, however, the company has a similar product, say for a different operating system. Using the tool while referring to preceding user documentation (if it exists) is extremely helpful.
Now that you’ve done your homework, you’ve probably got a better idea of the kinds of worthwhile questions you can ask, and have at least been introduced to relevant terms and concepts.
Thus armed, you are at least attending those first scrums and developer meetings with a basic level of knowledge. Even so, you still might find yourself feeling a bit lost. That’s probably to be expected. Keep attending. You’ll learn the concepts and language more quickly if you immerse yourself in your new environment, and you will also get a better sense of those things you most need to know. You will also show up on the radar of the rest of your team and begin getting to know them. Write down unfamiliar terms, record the scrums (a topic I've written about before), and don't be afraid to ask about possible doc or user impact for anything you hear, within reason of course. Another note about recording scrums: I've found it helpful to listen to the recording soon after the scrum, and to summarize discussion on issues that have publication impact. I have a Word document I've called "Scrum Items," and the information I add to it allows me to follow-up with the devs on relevant issues. I'd never be able to rely solely on my memory to capture such details!
There are likely more things a tech writer can do to speed up the learning process. If you know of any, please share them in the comments section below. Thanks.
Ben Davidson can be reached at benddavidson99 at gmail dot com. Read more articles by Ben Davidson.
Top of page
Staff and authors:
