The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
To: Rob Pike <>
Cc: "Michael Kjörling" <>,
Subject: [TUHS] Re: Early Unix and Keyboard Skills
Date: Sat, 05 Aug 2023 16:53:44 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

I took typing in Summer School.  My parents bought me a typewriter with
mathematical symbols on it, which was almost worthless, and I had to
improvise to get some of the standard characters (for example, the
semicolon was comma/backspace/colon).  By the time I was talking to
computers ( Model 33 tty) I was happy that I couldn't type faster
because it was impossible on that thing. 



On 2022-11-02 00:11, Rob Pike wrote:

> Neither ken nor dmr were impressive typists. In fact few programmers were then, at least of my acquaintance. 
> In the 1970s Bell Labs created the Getset - think of it as an early wired smartphone, or a Minitel, with a little screen and keyboard. It cost quite a bit but was a cool gadget so the executives all got one. But, in fascinating contrast to the Blackberry a generation later, no one would touch it - literally - because it had a keyboard, and keyboards were for (female) secretaries, not (male) executives. The product, although well ahead of its time, was a complete failure due to the cultural bias then. 
> There may be a good sociology paper in there somewhere. 
> I'm not saying K&D shared this blinkered view, not at all, just that typing skills were not de facto back then. Some of the folks were even two-finger jabbers. I was a little younger and a faster typist than most of the others, and I am not a good typist by any modern standard. 
> bwk was one who could smash out the text faster than many. His having learned on a teletype, the keyboard would resound with the impact of his forceful keystrokes. 
> -rob 
> On Wed, Nov 2, 2022 at 5:53 PM Michael Kjörling <> wrote: 
>> 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
>> typist.
>> -- 
>> 🪶 Michael Kjörling                  🏡
>> "Remember when, on the Internet, nobody cared that you were a dog?"

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

  parent reply	other threads:[~2023-08-05 23: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 ` [TUHS] " Michael Kjörling
2022-11-02  7:11   ` Rob Pike
2022-11-02 13:28     ` Clem Cole
2022-11-03 21:51     ` Stuff Received
2023-08-05 23:53     ` scj [this message]
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).