I began using paper tape regularly to carry programs to and from minicomputers that I was programming. The Purdue CDC 6500 was one of a few installations that had a tape reader/punch in its configuration. The software for it hadn't kept up with changes in our site. I fixed it.
The 6000 series architecture had one or more 60-bit CPUs sharing main memory with 10 multiplexed 18-bit peripheral processors (PPUs). The PPUs shared 10 data channels that could talk to I/O devices like tapes, disks and the reader/punch.
The CDC high speed reader/punch would pull tape from a spool past an optical read head. Punching was more mechanical and much slower.
It took special permission to read or punch paper tape because the device needed the continuous attention of a PPU and continuous use of a data channel while the paper was moving through the machine. As paper moved, the super computer's resources diminished by 10%. Yikes.
Bugs in the stock PPU code caused mis-read and mis-punched paper tape jobs. This sucked because they had to be rerun presenting their unusual load on the whole machine once again.
I learned the PPU instruction set, the protocol for acquiring and releasing data channels, and the specific function codes for the reader/punch. I read the source code and tapped our systems staff once or twice for details.
There was one daylight hour a day allocated for testing systems code. I was in the habit of running production jobs during systems time to get the great response. It was quite a different experience to run my own systems code during systems time. If I make a mistake, reboot the system.
I had friends who were systems time regulars. Their productivity was limited by that availability. I was happy to drift away from that but missed the aura that came with working then.