Circa 1974, you'd sit at a convenient desk and write your program out long hand on paper. You'd test it by walking through it in your head using test data. When you were satisfied that your program was correct, you'd go to the punch card room and transcribe your program onto punch cards, one 80 character line per card. You'd also punch cards for any data your program might need. Then you'd also punch a few incredibly cryptic cards in Job Control Language (JCL) that would tell the computer how to compile and run your program, and what input/output devices it would use. Then you'd take your cards to the 'IO Window', where you'd hand them to a clerk.
When your turn came, the clerk would load your cards into a hopper, and push a button to tell the computer to start reading them. The output of your program would generally go to a line printer or a drum plotter. When your program was done, the clerk would collect your cards, and your hard copy output, and put them in a pigeon hole where you could pick them up. You'd pick up the output, review the resuilts, and repeat the process. It would take anywhere from 20 minutes to 24 hours for a complete cycle. You can probably imagine that you were not happy when you found that the only output was a printed message from the compiler telling you that your program had a syntax error.
You might also have access to a computer through a teletype, so you could actually have an interactive session with a remote computer. However, typing on a teletype was physically painful (very stiff keys, and loud), so you still generally wrote and tested your program on paper first.
By 1976 UNIX systems and mini-computers like the PDP 11-70 were becoming more common. You usually worked in a room full of video terminals with 25x80 character displays. These were connected to the computer via serial lines. Crude, but not too dissimilar from working at a command prompt today. Most editors back then were pretty crappy though. Vi was an amazing improvement.
Linked list have nothing to do with OOP, in fact they predate OOP by quite a bit. Linked list are implemented simply by having a recursive structure, this is in my opinion conceptually easiest to understand in assembly -- you allocate some memory, and the first bytes of that memory serve as a pointer to the next/previous. In assembly you don't have to worry about the "type" and just think of it as another pointer, so the fact that it is recursive is not something you need to think about -- you don't have to think about how something can refer to itself in its definition.
Best Answer
In a word, poorly.
At least on any machine I ever used or heard of, you did not feed cards one at a time though. There were automated card readers that would feed and read hundreds of cards a minute (probably around 1000/minute, but I'm not sure of the exact specs).
In a typical case you wrote the code by hand, then punched it onto cards. Each card holds one line of code (up to 80 columns). You took the card deck to be executed. Depending on backlog, anywhere from an hour or so to a day or so later, you got your deck back along with a printout of the results.
I should probably add: since your card deck ran as a job, you didn't just submit the code for the program itself -- you had to write something vaguely similar to a batch file/shell script with the directions to compile and execute your code. IBM JCL (for one example) remains heavily influenced by its Hollerith-card origins.
Another minor point: on most systems I remember, you normally included a line number on each punch card. You obviously avoided dropping a deck if you could, but when (not if) one got dropped, it wasn't really nearly the tragedy many imagine. Interesting side point: at least the card sorters I saw used a radix sort -- they'd separate the cards into 10 bins, based on one digit of the line number, then "merge" those together (drop all the cards into a single bin in order) then repeat as many times as you had digits in the line numbers.
Hollerith cards were extremely influential -- 80 columns as a limit still survives to an almost disturbing degree. At least on the Control Data mainframes, things like the file system were influenced quite heavily as well. Well after Hollerith cards were mostly gone, remnants of them were visible in the OS -- for example, text files were often stored as a series of 80-character records, regardless of how few/many characters a line actually contained. I can still remember my surprise at the "backwardness" of a system like Unix where you had to read all the preceding lines to find line N of a text file, instead of just being able to seek to it directly.