It's 2026 and I started professional software development in 1986 when I took a Summer internship at Tandy Computers in Fort Worth, TX after my junior year at Rice. I worked for them again for a few weeks over Christmas break and started full time there the next year.
Now, as we all go through a series of huge changes in our jobs, I thought it would be fun if you would tell me what software development was like 40 years ago. Don't research it, don't go look at my AMA from years ago, just go with your gut.
What tools did we use? What did we develop on, machine wise? What was storage like? How did we learn everything we needed to know about languages, libraries, etc.? Communication? Languages used? And, I still had another year at school, how did we build software at school and turn in assignments?
I got this idea when I watched a story the other day about a teacher who was getting married and she asked her students to give her advice for her wedding and her married life going forward. The advice ranged from thought provoking and sweet to hilarious.
The difference here is that I can wait a few days for the submissions to all come in and I can actually tell you what it was like then.
Top comments (42)
COBOL pops to mind. And...the hole punch thing would have been way before this right? 😬
Perforated media existed well before computing (barrel organs, early programmable looms), but dedicated mechanical punching devices likely appeared in the early 19th century with the industrial production of Jacquard cards. The same paradigm was later repurposed for computing, most notably by Herman Hollerith in his tabulating machines.
What Pascal said is 100% correct, punch cards had existed for quite a long time but I just missed them (and COBOL/Fortran too). When I went to college in 1983 the computing center had a wall of cubbies on it (backless) where people would turn in a bunch of cards in a stack in one of the cubbies, someone would retrieve and run them, and then they would come back with a printout that showed the results of the run. I never saw anyone do that and I actually saw them roll out the very last card punch they had on campus (at least according to one of the folks working there).
When I went to Tandy we had a couple of guys working there who really only knew COBOL and when we tried to move them to C, they were resistant and eventually ended up being let go. I never heard how they did after that, but I assume they made bank when Y2K rolled around about a decade or so later.
GUI is a new thing, but not super mainstream, email is poking its head out, and devs are excited by the personal computer revolution, but circumspect about it.
That’s me riffing on my ideas of what 1986 might have been like.
GUIs really started to show up after just a few years. Tandy took a run at it with their first version of DeskMate which was character based (VGA and higher resolution graphics cards weren't quite yet a thing in 1986) but they used character based UIs to provide simple editors and stuff in software they could bundle with the machine. We actually did not have a network in the group I was in upon first joining but it was coming reasonably soon (token ring, Novell NetWare). We were moving everything around on floppy disks.
As a matter of fact, in the group I first worked in, we were building Varsity Scripsit (a new PC version of an older editor Tandy used to sell on their Unix machines). Of the eight machines used in our group, I believe only three had hard drives in them. Most of them were floppy only. You have not lived until you've done software development using Microsoft C on a floppy only machine. You edit your code on a disk with part of the compiler. Run it, it does one of the compilation steps, copies the build product onto the next disk (which might require multiple swaps to happen), runs the next build step, etc. Probably crossing multiple floppy disks in the process. If it failed at one of the steps, like the linker, then you could go back to the beginning and try and correct it. No millisecond builds in that environment :)
I will say this though, we saw what we had and its incredible limitations, but we also saw how fast it was changing. We needed literally every hardware change to happen overnight because we needed ten years of progress to move from the hardware being the bottleneck to the software being the bottleneck.
I can only imagine typing C code on a green screen terminal in '86 with just a blinking cursor. Version control was piles of floppy disks everywhere, each named project_final_v3_USE_THIS_ONE 😂 It's a miracle anything worked. Respect!
LOL. I was fortunate that the green screen terminal thing was largely restricted to when I was at school. For most classes we time shared VAX machines (like the VAX 11/780). If you put a whole class of people all doing development on one of those machines to work at the same time, you could bring it to its knees if everybody ran the compiler at the same time. So the rather crude system of a couple of tokens came to be (often an empty soft drink can sitting on top of a terminal that showed you had the right to compile right now). Only those with the token could compile, everybody else had to stick to editing their code. Those would then be moved around as people got their compile done and then shifted back to editing again.
When I went to work, Tandy was shifting from Unix machines and home computers they had built internally (like the TRS-80) to IBM PC and PC Jr. clones. Most every machine I worked on had a display card in them capable of displaying text and various graphics characters in color! Woo. This spot in the video will give you a better idea of what the heck I'm talking about: https://youtu.be/X_mFNBRXObg?si=amtuwVul7ERBOk_T&t=923
1986 was about the time of my first dev job. I was creating and maintaining code for three different platforms, 8088 MSDOS in C, Z80 assembler for CP/M based Kaypros, and an 8035 based embedded tool also in assembler.
The PC had a CGA screen. 4 colours, low resolution and a flicker that hurt the eyes to look at for very long. We had full screen text editors - Brief was a godsend - but nothing at all resembling version control.
Build tools, beyond a few self-created batch files were also non-existent, but then things were simpler. Apart from the standard C library and O/S supplied APIs, code had no external dependencies that needed managing.
The Kaypro had a 10MByte hard disk.
Learning was done from books, manuals and experimentation. Personally, I didn't have any more experienced colleagues to lean on, although that was undoubtedly an unusual situation.
Transferring files between computers was possible - over RS232 serial ports at very low bit rates - but when you're entire storage capacity was only 10MBytes, files tend to be very small anyway. Sneaker-net - copying files to a floppy, carrying it to the other machine and copying it again - was generally faster and more reliable.
Development methodology was agile, although we wouldn't have called it that, and didn't follow any formal process. Someone would ask for a feature, I'd listen, code it and say "there you go". No sprints - it took as long as it took. If it wasn't what was wanted, we'd iterate.
@alohci interesting, a hard drive, that was advanced those times ... I started with an ITT 3030, with two floppy disks 5 1/4" and green monitor. Boot time of CP/M was around a second ...
I started with 8080 assembly, and I accidentally wrote a cross assembler for Z80 commands, since I only had the asm.com assembler. Didn't know anything about crafting a compiler and so forth ...
I so want to chime in here, because I too started out at this time... so have firsthand knowledge, but that would be too much of a spoiler....
The one thing that I will mention, rather than software or equipment was process.... compute was expensive, so planning was meticulous, flowcharts, memory registers, plans reviewed before coding began.... it's actually a methodology that we're returning to now considering that in the age of the LLM context is king.
I will be watching these comments with great interest!
C... lots of C and tweed suits
100% correct on C. C was king at this time but a lot of people don't remember that C compilers like Microsoft C at the time had the ability to create C functions that were Intel assembly inside the function when you had to drop down to a lower level for higher performance. It was a way to embed some assembly into your overall higher level language application. Today it would be like having a 95% JavaScript app but part of the code was written in raw WASM.
Maybe you wore a suit if you worked for some places but fortunately I never worked any of them. The worst I ever dealt with was beige slacks and shirts with collars and even that was rare.
In 1986 I was writing Pascal on a VAX PDP 11 at Hampshire College in Amherst, MA. It was definitely well-past punch card days by then but the PDP was in a glassed-in room and was only accessible via terminals arranged around the main room. You had to type in your entire Pascal program and then run it. If it crashed, you printed it out on linked, dot matrix paper (so one long scroll for the entire length of the program). Then you got to read through that whole thing to figure out why it went wrong. (I think there must have been an error type and line number involved but I can't remember for sure.) We also had a computer lab with a few Apple Macintosh computers... the original (it came out just a couple years earlier). I took a winter term course on C and still have my copy of The C Programming Language on my bookshelf). There was no internet or email. I didn't even hear of the concept of email until the mid-nineties. Computers were strictly something used in a computer lab; no one that I remember actually owned one.
Well you might say that it was well-past punched card days, but not for everyone. Early adoption was not a thing in government, local councils and other large-scale institutions. In 1987 I was working for a local council and everything was punched card, except for a couple of paper tape machines. We were using multi-platter Winchester Hard Drives weighing around 5lbs each, and stacks and stacks of magnetic tape, but punched card was still the primary way to get your code into the machine.
Ouch. I had no idea then or now that anyone was still using punch cards. Interesting!
In 1986, we were still targeting Minuteman II's with punched mylar tape.
My dad had a giant 8086, complete with the 5” floppy disks and a monochrome screen. When my friends all started getting the new Commodore 64, I asked my dad if we could get one too. His non-verbal reply was to build a colour graphics card and 2 joysticks, and then told me if I wanted any games I’d need to write them.
So I learned how to spec out a program using a paper flowchart, how to make sprites in Basic, map joystick outputs to inputs in the program, and do it all in 700 bytes.
Things have come a long way since then!
BASIC was my first language (though on the TI 99/4) and in those days every version of the language was different (including some versions that had no line numbers at all). If you had a game you wanted from a magazine like Compute or a book like BASIC Games or More BASIC Games, you had to figure out how to translate it to your version of the language.
'86 I think it was still just the black square floppy disks? Small programs could have been written and shared on that, maybe school assignments as well, else the source code might have been printed out on paper and submitted? (totally guessing).
I think IBM was the main player, would have been PC-DOS. Apple had created a home computer by '82-83 I think so the school and job might have had those, with BASIC. Dev work I guess would have been in the terminal with Cobol or C, or a few others. Look forward to reading the other responses!
1986 meant every dependency decision was intentional because you felt the cost of each one. now agents install whatever fits the prompt and nobody reads the dep tree. some of the discipline from constrained environments was load-bearing.
This is actually a good observation and something that came up repeatedly in the first decade or so I was working. People would decry the fact that the computers were faster, with more memory, and more storage; yet the apps did not seem to get faster. And it's true. If you're not worrying about every byte and cycle, it's easier to write stuff in a lazy way and not have to spend so much time on everything. So writing the code sped up, but it certainly wasn't as efficient as it could be and we still see that today.
But on the flipside, it can be a lot more fun to put something together quickly and easily than to fret over every line.