Good technical writing starts with curiosity. I’ve found that the best documentation comes from asking simple questions early: • Why does this command exist? • What problem does it solve? • What breaks if it fails? Those questions force you to think beyond syntax and focus on user impact. That’s where clear, useful documentation comes from. #documentation #technicalwriting #docs
Ashu Saini
2w
I agree, writing detailed documents is key to good writing and for it, one has to start asking questions. It is very ironical though that in some teams, questions are not taken during the early phases of the doc cycle. I faced this issue in my last assignment.
100% with you on the "super power" of curiosity! I would only add that the list of questions can and does contain many more entries, that ebb and flow per project.
Sadly, that curiosity often exposes holes in what you're writing about. Then, when you say anything about the less than ideal UI, you're told "it's too late to change it now, just document it how it is". So we, the team producing the end product, miss out on the chance to provide the best user experience.
Insatiable curiosity for how things work coupled with the ability to communicate the ideas clearly to others. That’s us. We’re rare birds.
Vivek N
2w
Well said. Good documentation starts the moment someone asks “Why?” instead of simply “How?” That shift in thinking helps create content that is practical, user-focused, and actually useful in real-world situations.
Great points! There's nothing that terrifies me more in our line of work than someone who just blindly processes information without trying to understand it.
Once I had to document troubleshooting tips. It was a software product, therefore alarms should be triggered by tolerances built into the software. Blood pressure dips below 80, an alarm sounds. I asked for the tolerances and how the alarms or pop-ups were triggered by the software. I found it odd no one knew. Turns out the company used a type of open source code and the software engineer who added alarms did not document what he added and why. A year and a half after he left the system starts displaying these alarms and warnings. Hard to document when everyone is in the dark. But it did trigger internal processes for revision control and documentation.