Programming with punch cards must have driven people insane after a decade.
Just look at me--I'm sort of sane, sometimes.
What many people don't understand is how slow the old machines were--how would you like a "successful" day where you could get perhaps 2 or 3 compilations performed--and that includes tossing out your job because of a syntax error during compilation? Here's the typical workflow looked like after you'd gotten your first cuppa after the 9 AM status meeting:
1. Using your coding forms, write (block print) your next bit of program code, being careful that "oh", "zero", "i" and "1" are distinct and in the proper columns. You usually did this from a handwritten version on plain paper that you'd worked out, probably from your scribbles on a chalkboard.
2. Read what you've written a few times to pick up any obvious errors, then submit the stack of paper (remember to number the pages) to the keypunch pool.
3. The keypunch ladies (almost always female) read and punch your cards (it's useful if you tell them that a FORTRAN keypunch drum card can be used). Then they take your card deck and repeat the process on a verifier, where what they key in is compared with what's actually been punched. Errors are corrected.
4. Your punched deck, along with the coding forms, are delivered to your desk a few hours later. If you're smart, you take the deck to the room with the unit record equipment (sorters, reproducing punches, interpreters--and most importantly, the accounting machine) and get an "80-80" listing to take back to your desk which you carefully read one more time. If you need to make a correction, a few keypunches are scattered around--with 10 minute timers.
5. You take the punched cards, combine them with any other parts of the program you've previously done (sometimes you could archive your older work on mag tape, so maybe your deck was composed of modifications or additions to the stuff on tape. At any rate, you take the cards, any tapes and a job card that identifies you and your job for accounting purposes to the I/O window and turn it all over to the clerk for running. If you were smart, you punched and interpreted a duplicate deck while you were getting your 80-80 listing, in case some operator dropped your deck or the card reader ate it. By the way, "deck" could be several trays 4-5000 cards) on an I/O cart. Raised floors were wonderful in that one of the filler strips between tiles could come undone and trip up you and your cart....
6. Go back to your desk; contemplate your next step and wait for your job output.
7. Someone comes by about once an hour with a cart piled with not only your input, but your job output. Notice that your compilation/assembly failed because of an undefined symbol. Start all over again.
You develop certain thought and coding habits because of this process. Not all bad, IMOHO.
FWIW, if you were in maintenance, you could spend a few days staring a memory dumps, noting various things on them with a No. 2 pencil before you wrote even one line of code. Program listings could be checked out of a "library" of listings. No CRTs here, sorry.