I'm a Front-End Software engineer who will be responsible for the complete lifecycle of scalable, secure, and well-designed software products from research and design to implementation.
🇩🇴 I'm a Technical Program Manager and Content Strategist with an MSc in UXD. I help developers become better content creators and DevRel teams build robust content programs.
I've been in the technical writing field for over 30 years, mostly working on API documentation. My criteria for good API documentation are simple:
Is it accurate?
Is it complete?
Is it necessary?
Accuracy is paramount. If you incorrectly describe an argument as a 64-bit integer, but it's actually a 32-bit integer, you lose your audience.
Completeness is crucial. I hate it when I read an API doc and they fail to give me details of possible error/exception conditions. So this takes a string? How many chars? Min? Max? Does case count? Unicode?
Don't litter a technical doc with sales/marketing blather. I don't care if it's the greatest thing since bottled beer, let me decide. Keep the conceptual stuff in a separate section, as if I care. Don't make me wade through a bunch of new terms you heard on a TED talk. Use industry-standard terminology.
Max is a startup software engineer. He seeks to use what he has learnt as a startup founder and tech community leader to solves hard problems with innovate products or services.
🇩🇴 I'm a Technical Program Manager and Content Strategist with an MSc in UXD. I help developers become better content creators and DevRel teams build robust content programs.
I didn't argue to the contrary! ;) Like any other skill, technical writing requires a lot of consistency and repetition to get good at it (as you point out). But as you imagine, there's more to writing than "sounding good" on a page, and that's an important thing to highlight—technical writers care about the user experience and their skillset reflects that! :)
If you want to be a good writer, find a job where your work is reviewed by an editor. I still get dinged every once in a while for some sloppy passages.
🇩🇴 I'm a Technical Program Manager and Content Strategist with an MSc in UXD. I help developers become better content creators and DevRel teams build robust content programs.
Senior DevOps, located in Mexico City. Originally from Australia but have been living in Mexico City for over 8 years. In my down time, you can find me taking pictures and documenting life in Mexico
🇩🇴 I'm a Technical Program Manager and Content Strategist with an MSc in UXD. I help developers become better content creators and DevRel teams build robust content programs.
🇩🇴 I'm a Technical Program Manager and Content Strategist with an MSc in UXD. I help developers become better content creators and DevRel teams build robust content programs.
🇩🇴 I'm a Technical Program Manager and Content Strategist with an MSc in UXD. I help developers become better content creators and DevRel teams build robust content programs.
🇩🇴 I'm a Technical Program Manager and Content Strategist with an MSc in UXD. I help developers become better content creators and DevRel teams build robust content programs.
Professional technical writer with a software development background. Interests in cloud computing, IoT, V2X communication, and other cutting-edge technologies.
Great post! Thanks for the recommendations!
I'd like to add two resources that, while not specific to technical writing, have helped me a lot:
I've posted a bit on why I chose technical writing as a full-time job and why I like it:
What got me writing
Tomas Fernandez ・ Aug 10 ・ 4 min read
I got the course on Lynda! Thanks
Great, thank you for sharing!
I've been in the technical writing field for over 30 years, mostly working on API documentation. My criteria for good API documentation are simple:
Accuracy is paramount. If you incorrectly describe an argument as a 64-bit integer, but it's actually a 32-bit integer, you lose your audience.
Completeness is crucial. I hate it when I read an API doc and they fail to give me details of possible error/exception conditions. So this takes a string? How many chars? Min? Max? Does case count? Unicode?
Don't litter a technical doc with sales/marketing blather. I don't care if it's the greatest thing since bottled beer, let me decide. Keep the conceptual stuff in a separate section, as if I care. Don't make me wade through a bunch of new terms you heard on a TED talk. Use industry-standard terminology.
To be fair I think spending time to write constantly helps alot. While devouring the book like "On Writing Well" is really a good reference point.
I didn't argue to the contrary! ;) Like any other skill, technical writing requires a lot of consistency and repetition to get good at it (as you point out). But as you imagine, there's more to writing than "sounding good" on a page, and that's an important thing to highlight—technical writers care about the user experience and their skillset reflects that! :)
If you want to be a good writer, find a job where your work is reviewed by an editor. I still get dinged every once in a while for some sloppy passages.
100% this. Working with editors is the topic of my next newsletter.
Thank you for the sharing this. I am going to reference this going forward.
Thanks Benjamin!
Great guide lots of reference material thanks for sharing.
Thanks for reading, Andrew
Hey Stephanie,
Great guide for anyone who wants to break into technical writing!
Thanks for writing this.
Thank you, Saeed!
Comparing to recipes and the idea of concise and precise is very helpful. Thanks for the article.
Thank you!
Perfect overview of this amazing career field. Thanks for sharing!
awesome