Programming with Punched Cards (2005) [pdf]

The luxuries of a pro ... (although further down the page he is using the spare card punch machine himself.)

I met punched cards for an IBM 360 as a student - besides punching our own cards, in a public room with a dozen machines clattering away, we needed a "credit card" at the head of the deck. This was a pink-colored card (instead of the run-of-the-mill cream) pre-punched with the number of CPU seconds allowed for the job.

http://www.columbia.edu/cu/computinghistory/sorters.html

"You may have heard the story of the operator who dropped a whole box of cards. Wanting to put things right as quickly as possible, he sorted the cards, without consulting the user. As it turned out, that was the worst possible response. Up until that point, the box had contained a sample of random numbers."

(My father used to get his entropy from dead tree random number pools, similar to: https://www.rand.org/pubs/monograph_reports/MR1418.html )

You don't discover that you have to compile your program after you have written it. You are taught that in advance.

The keypunch operator knew this was source code, and would never give you an uninterpreted deck. That was only for data.

I maintained a 4,000+ card program. I used two special metal trays, with a tab that pressed and locked in the cards securely. There was no "2,000-card" limitation. The operators were trained to feed thousands of cards in the card reader. Our master file was 40,000 cards, read through twice a day.

We used a binary image technique, allowing us to store 240 4-bit digits (3 x 80) per card.