The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Winalski <paul.winalski@gmail.com>
To: Adam Thornton <athornton@gmail.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Documentation (was On Bloat and the Idea of Small Specialized Tools)
Date: Mon, 20 May 2024 11:43:49 -0400	[thread overview]
Message-ID: <CABH=_VQU1hQ0FhxWg8ZC=U0VTG0gZQuQKzyn13DCdJwEKvRz2Q@mail.gmail.com> (raw)
In-Reply-To: <CAP2nic07dtEUjgC4Ex8g0iOaDuGsXyhTxY23v0x8wG_cb3D_+A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

On Mon, May 20, 2024 at 2:08 AM Adam Thornton <athornton@gmail.com> wrote:

> I can't tell you--although some of you will know--what a delight it is to
> be working on a project with an actual documentation engineer.
>
> That person (Jonathan Sick, if any of you want to hire him) has engineered
> things such that it is easy to write good documentation for the projects we
> write, and not very onerous.
>
> Design for documentability, testability, and ease of maintenance are what
distinguishes good software engineering from hackery.

Back when I worked in DEC's software development tools group, we had
professional technical writers who write the manuals and online help text.
There was an unexpected (at least by me) benefit during a project's design
phase, too.  Documentation was written in parallel with the code, so once
the user interface specification was arrived at, first order of business
was to sit down with the tech writer and explain it to them.  Sometimes in
the process of doing that youd stop and think, "wait a minute--we don't
really want it doing that".  Or you'd find that you bhad difficulty
articulating exactly how a particular feature behaves.  That's a red flag
that you've designed the feature to be too obscure and complex, or that
there's something flat-out wrong with it.

-Paul W.

[-- Attachment #2: Type: text/html, Size: 1732 bytes --]

  reply	other threads:[~2024-05-20 15:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-18 18:07 [TUHS] Re: On Bloat and the Idea of Small Specialized Tools Douglas McIlroy
2024-05-18 18:13 ` Brantley Coile
2024-05-18 18:18 ` Larry McVoy
2024-05-18 18:52   ` Clem Cole
2024-05-18 19:19     ` Luther Johnson
2024-05-18 20:12       ` segaloco via TUHS
2024-05-18 19:32     ` Stuff Received
2024-05-18 18:22 ` Ralph Corderoy
2024-05-19  8:58   ` [TUHS] The 'usage: ...' message. (Was: On Bloat...) Ralph Corderoy
2024-05-18 18:31 ` [TUHS] Re: On Bloat and the Idea of Small Specialized Tools Peter Weinberger (温博格) via TUHS
2024-05-18 20:33 ` Steffen Nurpmeso
2024-05-19  8:39   ` Marc Rochkind
2024-05-20  6:07     ` Adam Thornton
2024-05-20 15:43       ` Paul Winalski [this message]
2024-05-20 16:37         ` [TUHS] Re: Documentation (was On Bloat and the Idea of Small Specialized Tools) Andrew Hume
2024-05-20 18:38         ` Yeechang Lee
2024-05-20 19:27           ` Phil Budne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABH=_VQU1hQ0FhxWg8ZC=U0VTG0gZQuQKzyn13DCdJwEKvRz2Q@mail.gmail.com' \
    --to=paul.winalski@gmail.com \
    --cc=athornton@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).