I assume they weren't able to sit in front of a computer for the whole day like we do today. So how did they write their program? On a piece of paper and type it later when the computer is available? How did they do their testing?

  • 9
    Well... for one thing they really did review their code, before submitting it to a compiler. No fun to lose precious time on missed semicolon.
    – Mchl
    Feb 24, 2011 at 7:59

6 Answers 6


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.

  • 7
    Also numbering punch cards was a very good idea for cases like dropping the cards pack.
    – sharptooth
    Feb 24, 2011 at 8:21
  • 2
    There was a famous story about some boss giving his assistant a tray of punch cards containing a set of random numbers. The assistant dropped the tray, and cards went all over the floor. Not knowing what else to do, the assistant picked up the cards and spent a couple hours sorting them into numerical order, which of course spoiled their randomness. Feb 24, 2011 at 8:27
  • 3
    @Louis Rhys: Will this link help? en.wikipedia.org/wiki/Punched_card
    – sharptooth
    Feb 24, 2011 at 10:27
  • 1
    The good old days. When the keypunch was a shared resource. And we had little red dot stickers we could put on our deck of cards to show that it was high priority and would get put into the card hopper first.
    – S.Lott
    Feb 24, 2011 at 11:01
  • 6
    Lets not even forget about the ways management enforced this. Your department was billed for time on the mainframe.
    – Incognito
    Feb 24, 2011 at 14:13

I learned programming in PL/1 in 1975 (on IBM 370/168), as a teenager (I was born in 1959). I had the privilege of having a father working at IBM France. His boss, M. Dornbush, wrote a book (in French) about programming in PL/1.

At that time, a program (as done by someone learning programming) was a packet of a few hundred punched cards. Charles E.Grant's answer describes the process: you wrote your program on paper first, and you checked it quite carefully. Then you punched the cards (on an IBM29 keypunch machine), and finally you put the card deck into the punched card reader. Notice that at that time source programs where quite small (a program of several thousand statements - that is, punched cards - was a very large program).

As a teenager, I was impressed by the ability of the PL/1 checkout compiler, in particular to suggest corrections on typos.

In the next years, I played with an old CAB/500 computer and an IBM/1620 computer at the Palais de la Découverte science museum in Paris (both computers were old enough to sit in a museum). CAB/500 was produced in the 1960s, and my father wrote its PAF compiler (a sort of BASIC language) when I was an infant or a toddler (1958-1962).

Today, I am still doing stuff (MELT) related to compilers, and one of the few who can claim that he saw his own father writing compilers!

The funny thing with PAF on CAB/500 was its interactive editor (with a physical tty & punched tapes) capable of completion (on keywords). It was a bit like the original IBM PC, somehow a "personal computer".

The funny thing with IBM/1620 was that you had to bootstrap it by entering a few digits on the keyboard to load the monitor and the Fortran compiler.

Notice that in the 1950s some computers did not even had punched card readers (AFAIK it was optional on IBM650 & IBM7094), but I never saw them.

Notice also that access to computers in the mid 1970s was a huge privilege (because they where costly equipments). Perhaps the equivalent today might be to get access to silicon making machines, or to datacenter-scale computing power.


It depends on how far back you want to go.

The earliest "Programming" used punchcards which looked like This (That's cobol) where they wrote out their code with very little interaction of anything particularly electrical and then fed them (when they actually got a chance) into the one computer into the building for the code to run for a while and spit out a print out of some form. Often there were lots of other people wanting to use the same computer, so you'd have to wait anywhere up to a couple of days (if it was really busy) for your results, which more often then not would be completely useless (you think getting a syntax error now can be frustrating. Imagine if you had to completely re-write a section of your code and then wait a day to compile it). They didn't have to check input nearly as much, or do usability testing or any of the other critical tests since, because computers where so scarce, they'd often be the only ones doing anything with the program.

When the PDP and equivalents became more common, a programmer (especially in college environments) would write their code out on paper, and then book time with the PDP to type their code in and run it a few times. They didn't get much time unless they were working in the small hours of the morning, so people staying up all night just to get their code to sort of run was not uncommon, and the limited availability of time on the "real" PDP's (or equivalent) lead to a number of groups building their own clone to get a bit more time.


I would say that back in those days, actually using a computer program might be slight easier than writing one today. Given that todays IDE's is much more user friendly than the user interfaces of computer programs back then, even when they had remote serial terminals. Most programs used cryptic undocumented key sequences or commands.

My only experience with ancient computer systems is the old Kodak 2610 Photo color printer. It booted from serial TTY using an optical stripe reader. During my employment I only had to reboot it once after a powe failure.

Command control was perfomred via a serial vt100 tty, but all configuration was saved and restored using a mechanical tty that could read and write paper stripes.


I remember my mother telling me that she was programming in college (Circa 1969-1970) She said that the first year they used punch cards, which was painful. The 2nd year they got a PDP-8, which was an amazing computer and I think they actually had a terminal, or at very least paper tape.

I think she was working in fortran and lisp.


Jerry Weinberg answered a similar question a while back on one of his blogs: http://secretsofconsulting.blogspot.com/2008/12/how-we-used-to-do-unit-testing.html

I think this might bring some light to your question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.