Electronics Career Game Changers

I'll reply as someone whose careen was at least electronics-adjacent.

As a kid, I grew up with vacuum tubes, and learned everything I could about them. Analogue domain (radios, amplifiers) etc. Transisters existed (mostly germanium) but were expensive. ICs were passives only - mainly encapsulations (big) to reduce production costs and often had tube type connectors. I still remember learning concepts like thermionic emission, and the advantages of pentodes over triodes for noise/distortion.

By the time I was graduating high school, 7400 series was in full vogue and the 8080 had come out. I still remember Pop Tronics with their Altair on the cover, and I lusted after one, but didn't have any money. Computers I had been exposed to in high school were all programmed with punched cards. Though students mostly couldn't afford, e.g., calculators we did all learn to use "slip-sticks".

In college digital electronics was all 7400 series work, with learning concepts like Carnot diagrams and NAND gate reduction (you can build everything from NAND). We had to build a modem in lab as I recall. On my own I got a surplus hall-effect keyboard and built an ASCII interface to it as I could use the electronics shops after hours. On the computing side, cards had been replaced (mostly) by printing terminals and dumb video. Editors were for the most part still line-oriented (as if one was working with a deck of cards) though TECO had some more advanced search/replace facilities. EMACS was just getting started and I admit to have mostly stuck with TECO (emacs aka control-R mode was an option). Computing for students was mostly PDP-11 or PDP-10 based, thought there was a honeywell machine running MULTICS, I preferred the AI lab's ITS OS running on a PDP10. They also had a xerox laser printer which was very cool for turning in class assignments over the typewriter in my dorm room. On my own I had wire-wrapped a Z80 S-100 system as programmed it in machine language. College was also my first exposure to programmable calculators which were very useful in most of my classes.

My first couple jobs were steps backward in that I worked as programmer on business computers (e.g. database), using line-oriented editors. .The first in COBOL (an internship), the second in HP-1000 assembly language. However the second job then entailed working on 6800 embedded controllers for large fiche retrival machines (these were interfaces to the HP1000 so you'd use the database to index the fiche and the machine would retrieve it). Most of the fiche systems we sold were for engineering systems designs (e.g. to GE), personnel records (Marine Corps) or legal cases (court systems).

Next I moved on to a job mostly working with the VAX under UNIX, doing OS work to build high availability systems for the phone companies. Interestingly enough I was hired to work on 68000 embedded processors but that kind of disappeared a few weeks after I was hired. Instead they started to build 68000 based computer systems so they had me work on that instead. This did involve a lot of work on optimization and interface to disk drive firmware and I had to work with scopes and in-circuit tools to debug so still pretty hardware oriented. Our company then built the Tahoe (a Vax clone) so one task was to port Unix to run on it, another was to create a hierarchical transaction processing system on top of that so operators could have guarantees updates would not be inconsistent and  in case of any single point failure (including to their own session terminal) recovery would be automatic (e.g. they could log into a different terminal and recover their session, single disks could fail, single processors, etc.). This was actually optimized for availability rather than fault-tolerance, but a large amount of fault-tolerance came along for the ride. Equally important was that our groups work fed back to the hardware group to improve reliability on critical components - some things could fail and be easily worked around and some things could not be. It also was the entry into a longer term interest on what you might call "intelligent scheduling" - i.e. how to monitor performance and change the job mix to achieve system-level goals rather than just process-level.

After that I went back to grad school to learn something mostly different (e.g. AI), so I'll stop there (though it did eventually lead to some work in robotics). The summary of events, then:

Punched cards -> terminals. (and batch -> time-sharing).

Line editing -> character editing.

Tubes -> ICs.

Mix of hardware and software into firmware.

Standardized OSs.

Improved reliability of systems through better hardware and software.

I'll reply as someone whose careen was at least electronics-adjacent.

As a kid, I grew up with vacuum tubes, and learned everything I could about them. Analogue domain (radios, amplifiers) etc. Transisters existed (mostly germanium) but were expensive. ICs were passives only - mainly encapsulations (big) to reduce production costs and often had tube type connectors. I still remember learning concepts like thermionic emission, and the advantages of pentodes over triodes for noise/distortion.

By the time I was graduating high school, 7400 series was in full vogue and the 8080 had come out. I still remember Pop Tronics with their Altair on the cover, and I lusted after one, but didn't have any money. Computers I had been exposed to in high school were all programmed with punched cards. Though students mostly couldn't afford, e.g., calculators we did all learn to use "slip-sticks".

In college digital electronics was all 7400 series work, with learning concepts like Carnot diagrams and NAND gate reduction (you can build everything from NAND). We had to build a modem in lab as I recall. On my own I got a surplus hall-effect keyboard and built an ASCII interface to it as I could use the electronics shops after hours. On the computing side, cards had been replaced (mostly) by printing terminals and dumb video. Editors were for the most part still line-oriented (as if one was working with a deck of cards) though TECO had some more advanced search/replace facilities. EMACS was just getting started and I admit to have mostly stuck with TECO (emacs aka control-R mode was an option). Computing for students was mostly PDP-11 or PDP-10 based, thought there was a honeywell machine running MULTICS, I preferred the AI lab's ITS OS running on a PDP10. They also had a xerox laser printer which was very cool for turning in class assignments over the typewriter in my dorm room. On my own I had wire-wrapped a Z80 S-100 system as programmed it in machine language. College was also my first exposure to programmable calculators which were very useful in most of my classes.

My first couple jobs were steps backward in that I worked as programmer on business computers (e.g. database), using line-oriented editors. .The first in COBOL (an internship), the second in HP-1000 assembly language. However the second job then entailed working on 6800 embedded controllers for large fiche retrival machines (these were interfaces to the HP1000 so you'd use the database to index the fiche and the machine would retrieve it). Most of the fiche systems we sold were for engineering systems designs (e.g. to GE), personnel records (Marine Corps) or legal cases (court systems).

Next I moved on to a job mostly working with the VAX under UNIX, doing OS work to build high availability systems for the phone companies. Interestingly enough I was hired to work on 68000 embedded processors but that kind of disappeared a few weeks after I was hired. Instead they started to build 68000 based computer systems so they had me work on that instead. This did involve a lot of work on optimization and interface to disk drive firmware and I had to work with scopes and in-circuit tools to debug so still pretty hardware oriented. Our company then built the Tahoe (a Vax clone) so one task was to port Unix to run on it, another was to create a hierarchical transaction processing system on top of that so operators could have guarantees updates would not be inconsistent and  in case of any single point failure (including to their own session terminal) recovery would be automatic (e.g. they could log into a different terminal and recover their session, single disks could fail, single processors, etc.). This was actually optimized for availability rather than fault-tolerance, but a large amount of fault-tolerance came along for the ride. Equally important was that our groups work fed back to the hardware group to improve reliability on critical components - some things could fail and be easily worked around and some things could not be. It also was the entry into a longer term interest on what you might call "intelligent scheduling" - i.e. how to monitor performance and change the job mix to achieve system-level goals rather than just process-level.

After that I went back to grad school to learn something mostly different (e.g. AI), so I'll stop there (though it did eventually lead to some work in robotics). The summary of events, then:

Punched cards -> terminals. (and batch -> time-sharing).

Line editing -> character editing.

Tubes -> ICs.

Mix of hardware and software into firmware.

Standardized OSs.

Improved reliability of systems through better hardware and software.

Great post.  Looks like you had a front row seat to witness many of the advancements.