Did professionals have those timeshare terminal things in the home back in the day (late '60s, early '70s?) like they had in some schools? I imagine that far back the terminals would have been at the office and the processing power rented from some other company offering the timeshare service.
And furthermore that code would have been printed on physical paper, from a typewriter or something, not edited digitally.
~Max
There was a brief time in my career where I had to hump home a terminal and modem to provide night support for my week in barrel. I had a 2nd phone line for this reason. They did pay for the 2nd line at least.
That must have been a PITA!
~Max
The first commercial modem was the Bell 101, from 1959, while FORTRAN dates from 1954. But I suspect a more serious problem is that any kind of interactive terminal was tremendously expensive. Much of that early programming went directly on punch cards. Programmers would then take a stack of them to the computer operator and they’d be queued up to run.
I guess programmers could just mail the cards in, but that makes the horrific latency even worse.
It was and I always tried to write scripts for the operators in extreme detail so they could follow instructions easily, but not all my fellow programmers did and I got more calls than I appreciated for confused operators not being able to follow the unclear instructions.
I would literally cut and tape and then copy so the Ops would have visual clues also.
But sometimes programs just failed for an unanticipated condition. Always seemed to happen between 2am and 3am.
Sounds about right. I know several people at Google, and while the men do tend to be happier there than the women, a lot of people would have told me if they’d run into that level of “super vilian” sexism, and no one has.
What? He was trolling? How did no one see that coming?
The first real practical 300 baud full duplex modem was the Hayes Smartmodem released in 1981 which also developed the ‘handshake’ protocol that became the default for automated dial-up versus having to key in individual commands to initiate a terminal session. Of course, at 300 baud the rate of file transfer is painfully slow, even with the relatively small codebase that projects had in the pre-OOPS era of programming. This also assumes that the phone lines in the pre-optical fiber age were good enough to maintain a connection; I recall time and again getting booted off of a dial-up BBS because the connection was too poor, and this was from a friend’s house in a well-developed suburb, which crushed my dreams of being able to dial into anything from the rural bumfuck where I lived.
And it should be pointed out, again, that “programming” on a large project or enterprise scale is far more than writing code. In fact, if a programmer to day is spending more than 20% of their time writing code they are probably spinning their wheels because a lot of making a modern software development effort work is creating and revising requirements and interfaces, testing code, communicating across teams, planning out work, et cetera; even if you are doing Agile or SCRUM or whatever the current paradigm is you end up coding in brief periods and then unit testing, revising, regression testing, documenting, et cetera. These are things that we can easily do remotely now with the collaboration tools that are available but in the era before distributed revision control, collaborative documentation and tracking systems like Jira and Confluence, remote videoconferencing, et cetera this would have been onerous and counterproductive if workable at all. (Having worked on design projects in the pre-collaboration suite era having to communicate only by email and phone I can attest to how slow this process is and how many errors are made in miscommunication or failure to get the most up-to-date information.)
Of course, in the pre-PC era this would have required a interactive remote terminal, and in the punchcard era it would have been absurd to even attempt work from home. The idea that it would be possible for a programmer to work from home “ in the early days of programming”, e.g. prior to the 1980s is absurd on the face, and even until quite recently it was really necessary for programmers collaborating on a large project to interact in person on a routine basis. The point at which we started to see globally distributed programming projects starts in the mid-‘Nineties with expansion of open source projects like GNU and Netscape, and even then these often required a core group of architects that were colocated and delving out individual subcomponents to small coding teams or individual coders.
Imagine punching out your cards, carefully arranging them in a box, mailing them off, and then getting a call a week later saying that the sysop dropped the cards while loading them into the hopper and they are now out of order. That makes waiting a few seconds for the GCC compiler to compile your code seem like a the kiss of an angel by comparison.
Stranger
My high school had terminals to some kind of computer (a small Vax, I think) which wasn’t located on-site. We used paper-tape, which had the virtue that if you dropped it, you could wind it up again, you hadn’t lost your whole program. That was in the late seventies.
Was there not any solid space on punchcards with room enough to number them?
With what, your own hand? I doubt the hole punching machine could print numbers. I read that sometimes the last eight or so columns were reserved for a sequence number in case the cards get dropped.
~Max
Sure, and experienced programmers (i.e. those for whom this had happened to before) would do exactly that. However, realize that each card is one 80 column line (in FORTRAN at least…hence why Fortran and Fortran-based tools still have an 80 column limit). It is really easy to write a program implementing, say, a Runge-Kutta iterative solver that will take fifty lines without even getting into anything you might be actually using the numerical solver to do, such as some kind of radiative heating function, so even a simple program could be a couple hundred cards, so it easy to get lazy or just get out of order and misnumber the cards. Anyway, programming via punchcard entry ‘remotely’ would be an incredibly tedious and time-wasting process that would not be even vaguely feasible, and this was the norm well into the ‘Seventies.
Stranger
That’s why you used a magic marker to draw a diagonal stripe down the edge of your program deck. Or, heck, one down each edge.
I used to telecommute way back in the 80s, and I lugged one of several shared Compac “portable” computers home. We called them the sewing machines. Working on a dial-up modem was a joy! 
I also volunteered for an Explorer Post that our IT dept sponsored. We’d lug those Compacs to Camporees to do the scoring. More joy!
Even just interactive terminal operations are painfully slow at 300 baud, let alone 110. Most people can read faster than 300 baud. And some people can type faster than 110.
Thankfully, by the time I was old enough for a modem (mid 80s), the phone lines were in pretty good shape. Started with a 2400 baud and ended with a dual, bonded 2x56k model.
I can just about imagine that someone, somewhere did some small amount of programming remotely by the mid-60s, even if only as an experiment. It would have been just way too expensive to do in general, though.
One wonders if most of the advancement in sorting algorithms can be traced to people dropping large stacks of punchcards.
If you were using punched cards you probably had a card sorter. Sorting only helps if you have sequence numbers on your cards but you could read them in and have a new set punched with sequence numbers. Dropping punched cards is one of those things you learn not to do. Keep large decks in card boxes with diagonal stripes on them. Use rubber bands on small decks. But not rubber bands that are too tight and will crimp the cards so they jam in the reader. The operators weren’t real concerned about the state of your deck if they had to get up and go clear the card reader.
Anyway, I was programming at home in the 70s because that’s where my computers were. They were small. It was mostly assembly, a little BASIC mainly for fun. Forth emerged as a kind of assembler overlay and with a good assembler I developed some high level macro functionality. Decent versions of BASIC emerged, I had a version of Tiny C that never took off, Fortran became available.
In the 80s I was using high speed 18K bit multi-channel modems but largely as transfer devices. Programming became more extensive when I got a VAX. MicroVAX anyway, not the fastest VAX ever made, probably the slowest, but a big jump over 386 and 486 machines. I don’t think many other people had a 9-track tape drive connected to a PC and another one on a VAX at home. Those really were the good old days.
I was mostly making a small joke there, but the diagonal stripe still requires sorting, just by hand. You drop your stack, play 52-card pickup, and now have to reorder the deck based on which segments have an out of order stripe. Someone that dropped their decks on a regular basis would get rather good at this reordering, I imagine–which is to say, they developed an effective manual sort algorithm. It wouldn’t shock me if some of the lessons there made their way into one sorting technique or other.
As one example of parallelism, one could hand half the shuffled deck to a friend, both of you sorting your individual pieces, and then interleaving the two sorted subdecks together. That’s just one iteration of mergesort.
Many of the VT* terminals were only running at 9600 baud even over a hard connection, so calling in from home at 1200 baud wouldn’t have been too terrible, and that could have started in the late 70s. By then a PC or other home computer running terminal emulation software would probably have been preferable to a real (or clone) VT220 or whatever.
Even in the very early 90s I knew people working from home with a black & white X-Terminal and 9600 (or maybe 14.4kb) connection. In 1990 or so I did school programing assignments on a Vax over a 2400 baud connection.
Obviously that’s way later than the 60s, but some of us have been working remotely on a regular basis for 30+ years. I don’t mean doing work at home, and then taking the resulting product into the office, but working on remote systems. People a bit older than me who started in academia have been doing it since at least the mid-80s.
If you were going to work remotely with slow connections you needed to be proficient in line editors. Full screen editors were too slow on dumb terminals. Some smart terminals could insert lines it was still awful to move somewhere else in the text and wait for a refresh. And remember that baud is the bit rate, it doesn’t guarantee the sending or receiving character rate which is asynchronous. With a line editor you worked on one or more consecutive lines of text at a time using a simple commands, most commands were just a single character. I don’t recall exact syntax off hand but I recall a command like “3LP” maybe meant move forward in the text 3 lines from the current line and print that line. Or “-3LP” to move back 3 lines and print that 1 line. Looking back on it now I can see that it required keeping a sort of mental image of large sections of code. Not in great detail of the content of each line, but where functional portions of the code were relative to each other.
Sorting a dropped deck isn’t actually that bad, so long as you still have some sort of information about the order (numbers on each of the cards, diagonal stripe, etc.). A dropped deck will mostly split into a small number of chunks, and within each of those chunks, the order will be preserved, so it’s just a matter of putting the chunks back together the right way.
