I think the Author meant 1973 not 1983. In 1983 I was about to graduate from USC, we had FINE (Fine Is Not Emacs), vi, TOPS20, TENEX, TOPS10, Beehive terminals, VT52 & VT100 terminals, the infamous 'urinal' terminals (the Lear Sieglar ADM3) and really cool Heathkit H29 and later Z29 terminals. You tended to work in an 80 x 24 + 1 line status window but that was not nearly as bad as writing things out on sheets. Which I did do in 1973 because the only way to program Fortran at the High School was to send it into the district office to run as a batch job.
Nit picking aside though, the key issue was turnaround time. The time between when you thought you were done and the time you knew your code worked. Few people these days experience hitting enter at the shell prompt and waiting 30 - 45 seconds before the command started running. This was one aspect of workstations that made them so popular, no time sharing mean you could compile quickly and test and simple things like 'ls' on a directory were fast.
It got "too good" though, with people having the computer check things rather than think about what they had written. That leads to a situation where if the result is close enough to what you think it should be, you can convince yourself that it is correct before it actually is, and that can lead you to look elsewhere when things go wrong and makes debugging harder than it should be.
I was so excited when I got my own vt220 on my desk and didn't have to go into the raised floor computer room. We used a VAX 1170 then a Micro vax to compile C for Motorola 68000 and 68020 processors. Then you'd download the code to an EPROM burner.
Well, the author notes that the workplace upgraded to terminals after just a year or two. I know that the high school where my mom taught programming in Chicago still had punch card technology (no terminals) as of the early 1980s, although the upgrade happened around then. Also some of the other mentions (eg IBM clicky keyboards) are consistent with a 1983 date.
Nit picking aside though, the key issue was turnaround time. The time between when you thought you were done and the time you knew your code worked. Few people these days experience hitting enter at the shell prompt and waiting 30 - 45 seconds before the command started running. This was one aspect of workstations that made them so popular, no time sharing mean you could compile quickly and test and simple things like 'ls' on a directory were fast.
It got "too good" though, with people having the computer check things rather than think about what they had written. That leads to a situation where if the result is close enough to what you think it should be, you can convince yourself that it is correct before it actually is, and that can lead you to look elsewhere when things go wrong and makes debugging harder than it should be.