From: KenUnix <firstname.lastname@example.org>
Cc: "Michael Kjörling" <email@example.com>, firstname.lastname@example.org
Subject: [TUHS] Re: Early Unix and Keyboard Skills
Date: Sat, 5 Aug 2023 20:22:17 -0400 [thread overview]
Message-ID: <CAJXSPs-2Qj+ZbPtK5E41bHOqC1YD8rjFNUPdP+OoGik=0GpF7g@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3933 bytes --]
The thing I like is VI because it is almost universal. Windows, Linux, BSD
In a pinch I use "ed".
Sad to hear today that its creator has passed away.
On Sat, Aug 5, 2023 at 7:53 PM <email@example.com> wrote:
> 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.
> On Wed, Nov 2, 2022 at 5:53 PM Michael Kjörling <firstname.lastname@example.org>
> On 2 Nov 2022 13:36 +1100, from email@example.com (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 🏡 https://michael.kjorling.se
> "Remember when, on the Internet, nobody cared that you were a dog?"
End of line
[-- Attachment #2: Type: text/html, Size: 6049 bytes --]
next prev parent reply other threads:[~2023-08-06 0:22 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
2023-08-06 0:22 ` KenUnix [this message]
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
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).