Getting Started, circa 1983

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.

Actually, the 3270 terminal was pretty smart for its time. It was capable of x/y cursor addressing (supporting full-screen editors as opposed to line editors like the original Unix "ed"), had protected/unprotected fields (for form entry, you could only enter data in the unprotected fields and tab from one field to the next, like a form in HTML), and one version, the 3279, even had a color display. You can see a photo of a 3279 here:

https://en.wikipedia.org/wiki/IBM_3279

My first experience with computers in the 1970s was with punched cards, but unlike the author, the output (printed on fan-fold line printer paper) usually came back in a matter of minutes. When your program crashed, you'd get a hexadecimal dump of registers and memory - printed on paper.

My dad worked with punch cards to crunch numbers in Fortran as a young statistician. Initially the university had only one big machine. Every day at 5PM there were long lines of people delivering their decks of cards with source code to the computing center. At night clerks fed all the jobs to the machine, and at 9AM there was another line of people getting their job output back.

The output cards were stacked in boxes on the wall by user name. You could tell the height of the output decks from some distance, and if a box only contained one card, you knew instantly it was a syntax error and someone was going to have a bad day. So apparently at their start of computing, they immediately had a nice analog build status visualization.

My first job was a bit more modern, instead of men writing code with pencil and women typing it in, we had women who coded, did the admin job, and typed themself. The men moved up to become system architects or database designers. We had ASCII typewriters with paper tape to type our own code. The papertape then went to the print and copy room, where it was printed and copied on magnetic tape. Compile time was rare, especially at the dayshift. So once the printout was on the table, a group of coders, all but me women, took a red pencil to fix bugs, before a job was submitted.

Most all of the old-timers used pencil on coding sheets like displayed in this article and were aghast at us young whipper-snappers that entered code directly into the terminal.

I sometimes wonder if this type of programming is a side-effect of the short attention spans teens and twenty-somethings have now... but that's a subject for another time.

In retrospect, this approach made us to think about edge cases which now I'll think about much later in the coding process. The overall grade was based on the correctness and also on the number of alterations in logic made in the final running code.

edit: by school, I refer to senior high school as in US [0]

[0] https://en.wikipedia.org/wiki/Senior_high_school#United_Stat...

To this day, I still prefer to do a lot of writing before I start typing, though I don't often write the entire program ahead of time. Instead, I'll write the "interesting" bits -- the stuff that's algorithmically complex or otherwise kind of tricky. I find that with nothing but a pencil and a sheet of paper, there are fewer distractions and fewer limitations (comments can readily contain drawings, for example).

Compared with today's streamlined tools - everything cloud synced instantaneously from portable devices, and maybe a small paper notebook to sketch ideas - it seems incredibly quaint. Lots of artifacts that just aren't necessary now.

I used to type in BASIC programs from magazines such as Byte. A typical bug that bit me several times was typing an l instead of a 1.

Especially you have to remember a lot of Java standard library APIs and the same for C#, ASM, C, C++.

For one exam I had to remember Lisp, Haskell, Ada, Pascal, Scheme, J# and Smalltalk language syntax and their common APIs to write code snips on paper to pass it.

What was your experience with university coding exams?

I would guess those programmers made sure they had perfect penmanship, I wouldn't have wanted a typist to mistake my colons for simicolons.

I wounder if the act of physically writing out the program on pen and paper actually made it stick for viscerally in the programmers head?

I eat up computer history, but it's especially nice to hear firsthand accounts about seemingly mundane stuff like workflow.