My contribution to this debate is that it isn't a developer problem it's a "beginner's mind" problem, which I personally characterize as "empathy"
Can one recall what it was like 15 minutes ago when you didn't know the answer, and how would you have changed the situation to foster the pathway that would have squared up the product's model with your mental model. No matter the product: library, webpage, physical tool, bureaucratic process, etc. If a human(s) made it, then managing the assumptions is a grade-A problem that requires managing throughout its lifecycle
Developers love to complain about bad requirements, but documentation is where one gets to provide the requirements to the reader, thus, is an empathy management exercise
jamesgill · 1h ago
As someone who spent a long time in technical writing, and wrote a decent-selling book about getting started as a tech writer, here’s my thought:
The problems with software documentation/tutorials/etc. rarely have anything to do with writing skill—because the biggest challenge is not writing, it’s how to analyze and understand the audience and design what ‘documentation’ they need to get the job done. Separate skill(s), unrelated to writing. “Writing”, in fact, is the easy part.
Think of it this way: you can write the most beautiful, elegant, correct JavaScript that’s ever been written: and it can be utterly useless. Beautiful code is good, but that’s not the goal or the focus.
No comments yet
theletterf · 2h ago
The posts has a promising start, then abruptly ends.
They also need to hire technical writers. Did the author know they exist?
tolerance · 1h ago
You know, I really want to thank you for referring a book and including a review of it, especially your own.
More on topic, I'm under the impression that this is a budding idea of the author's, at least as budding as a thought willing to be made public can be without being totally picked a part by the crowd here.
So yeah, he needs to read that book and post a review of it next. Keep the butter churning.
crosser · 42m ago
I once worked for an organization known for providing good documentation.
This is how it worked:
They had a documentation-writing branch. And you (developer) knew that if you don't write documentation, they will. And then if will cost you _more_ time and frustration to review and correct what they wrote than to write it yourself and give to them.
So you did write it (and they proofread it, corrected grammar etc.).
tolerance · 1h ago
I have a hunch that technical documentation may be one form of writing that LLMs won't be able to really help with beyond the mundane grammatical/structural advantages that it affords to any other form of writing.
AI is utterly swaggerless and I have a notion that a lot of what people enjoy from technical writing is the vibe they get from the writing; as much as the instruction.
x2tyfi · 2h ago
Undoubtedly a big opportunity area for LLMs. I’ve recently observed engineers deliver LLM-generated (or iterated) docs that blow away any technical writing they had done in the past.
Network Engineering design docs can be somewhat formulaic structurally, making the LLMs job simpler. I imagine in the near future we’ll just ask them to follow doc templates or reference other designs within a RAG system to ensure there aren’t gaps in the doc, etc.
nrclark · 2h ago
I'm not sure about that. For whatever reason, I've noticed that my brain has a hard time holding onto ideas from LLM-written documentation. Maybe because LLMs generate the mathematically lowest-energy thing that they can.
I'd take poor grammar and interesting ideas over clear grammar devoid of real content any day of the week.
CharlesW · 1h ago
Assuming that your ability to remember the content isn't a result of differences in the substance of the content, in my experience the stylistic issue can be addressed with thoughtful training/prompting and lots of Do/Don't examples.
It helps if your technical writers already adhere to a voice/tone guide, which can be pretty easily adapted/extended for automated documentation generation. If one doesn't exist, you'll definitely want to create that first. Some good examples:
That’s understandable - the rule of “garbage in, garbage out” certainly still applies. I find that many engineers are capable of gathering the right requirements and content, but struggle with the polish/finish that makes docs more consumable - where LLMs can shine.
Can one recall what it was like 15 minutes ago when you didn't know the answer, and how would you have changed the situation to foster the pathway that would have squared up the product's model with your mental model. No matter the product: library, webpage, physical tool, bureaucratic process, etc. If a human(s) made it, then managing the assumptions is a grade-A problem that requires managing throughout its lifecycle
Developers love to complain about bad requirements, but documentation is where one gets to provide the requirements to the reader, thus, is an empathy management exercise
No comments yet
Yes, developers need to improve writing skills. A good book on the matter is Chris Ward's Technical Writing for Software Developers, which I reviewed here: https://passo.uno/review-technical-writing-software-develope...
They also need to hire technical writers. Did the author know they exist?
More on topic, I'm under the impression that this is a budding idea of the author's, at least as budding as a thought willing to be made public can be without being totally picked a part by the crowd here.
So yeah, he needs to read that book and post a review of it next. Keep the butter churning.
This is how it worked:
They had a documentation-writing branch. And you (developer) knew that if you don't write documentation, they will. And then if will cost you _more_ time and frustration to review and correct what they wrote than to write it yourself and give to them.
So you did write it (and they proofread it, corrected grammar etc.).
AI is utterly swaggerless and I have a notion that a lot of what people enjoy from technical writing is the vibe they get from the writing; as much as the instruction.
Network Engineering design docs can be somewhat formulaic structurally, making the LLMs job simpler. I imagine in the near future we’ll just ask them to follow doc templates or reference other designs within a RAG system to ensure there aren’t gaps in the doc, etc.
I'd take poor grammar and interesting ideas over clear grammar devoid of real content any day of the week.
It helps if your technical writers already adhere to a voice/tone guide, which can be pretty easily adapted/extended for automated documentation generation. If one doesn't exist, you'll definitely want to create that first. Some good examples:
Google: https://developers.google.com/style
IBM: https://ptgmedia.pearsoncmg.com/images/9780132101301/samplep...
Microsoft: https://learn.microsoft.com/en-us/style-guide/welcome/
Red Hat: https://stylepedia.net/style/