The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Michael Kjörling" <>
Subject: [TUHS] Re: Early Unix and Keyboard Skills
Date: Wed, 2 Nov 2022 06:53:25 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2 Nov 2022 13:36 +1100, from (steve jenkin):
> There’s at least one Internet meme that highly productive coders
> necessarily have good keyboard skills, which leads to also producing
> documentation or, at least, not avoiding it entirely, as often
> happens commercially.

I wouldn't be so sure that this necessarily follows. Good keyboard
skills definitely help with the mechanics of typing code as well as
text, I'll certainly grant that; but someone can be a good typist yet
write complete gibberish, or be a poor/slow typist and _by necessity_
need to consider each word that they use because typing an extra
sentence takes them so long. If it takes you ten seconds to type out a
normal sentence, revising becomes less of an issue than if typing out
the same sentence takes a minute or a minute and a half.

Also, certainly in my case and I doubt that I'm alone, a lot of my
time "coding" isn't spent doing the mechanics of "writing code", but
rather considering possible solutions to a problem, and what the
consequences would be of different choices. That part of the software
development process is essentially unaffected by how good one is as a
typist, and I expect that the effect would be even more pronounced for
someone using something like an ASR-33 and edlin, than a modern
computer and visual editor. Again, the longer it takes to revise
something, the more it makes sense to get it right on the first
attempt, even if that means some preparatory work up-front.

Writing documentation is probably more an issue of mindset and being
allowed the time, than it is a question of how good one is as a

🪶 Michael Kjörling                  🏡
“Remember when, on the Internet, nobody cared that you were a dog?”

  reply	other threads:[~2022-11-02  6:53 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02  2:36 [TUHS] " steve jenkin
2022-11-02  6:53 ` Michael Kjörling [this message]
2022-11-02  7:11   ` [TUHS] " Rob Pike
2022-11-02 13:28     ` Clem Cole
2022-11-03 21:51     ` Stuff Received
2023-08-05 23:53     ` scj
2023-08-06  0:22       ` KenUnix
2023-08-06  0:43         ` Larry McVoy
2023-08-06 14:51           ` Leah Neukirchen
2023-08-06 15:01             ` Larry McVoy
2023-08-06 16:31             ` Clem Cole
2023-08-06 18:20               ` Jon Forrest
2023-08-07  4:56                 ` Adam Thornton
2023-08-06  8:37       ` Ronald Natalie
2022-11-02 12:13 ` Steffen Nurpmeso
2022-11-02 12:24   ` Steffen Nurpmeso
2022-11-02 20:35     ` Ron Natalie
2022-11-02 12:26   ` John P. Linderman
2022-11-02 13:07     ` Larry Stewart
2022-11-02 13:16       ` Larry McVoy
2022-11-02 13:27     ` Steffen Nurpmeso
2022-11-02 19:01 ` jason-tuhs
2022-11-02 19:20   ` John P. Linderman
2022-11-03  1:47     ` Ronald Natalie
2022-11-03  1:59       ` Dave Horsfall
2022-11-03  3:01       ` Clem Cole
2022-11-03 15:17       ` Paul Winalski
2022-11-03 16:18         ` Clem Cole
2022-11-03 17:02         ` John Cowan
2022-11-03 19:36           ` Rich Morin
2022-11-03 20:01             ` Charles H Sauer (he/him)
2022-11-02 12:16 Douglas McIlroy

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:

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

  git send-email \ \ \ \

* 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).