For example: On an IBM PC, running DOS. You could know all there was to know about the BIOS, hardware ISRs, DOS ISRs, DMA, how a file system works, and maybe a bit about the graphics system, and you could make the machine do anything you wanted.
Today, if my kid wanted to learn all those things, I wouldn't even know where to tell him to start. You simply can't get that low (easily) anymore, or know that much about numerous subsystems. And the higher level stuff, like you say, is buried in layers of abstraction.
Of course, now we have an unprecedented access to cheap, powerful microcontrollers and SBCs, which make up for it to some degree - but it's still harder to translate that knowledge into something of perceived usefulness on a 'proper' computer.
You know, it’s pretty interesting that IBM was painted as the devil, but that they made this standard, interoperable computer system that you could touch at such a low level. Now it’s all Windows 10 and MacBooks and Linux userland, and even if it were possible, good luck finding documentation for any of that.
I hear you. There was a time when I could pretty much describe everything that happened from the time you pressed a key to the time a file was displayed on your screen: exception/interrupt handlers, keyboard driver, network stack, storage stack, context switches, page faults, etc. And that was a pretty good chunk of what I needed to know in order to do many useful things. Now some of those pieces aren't even relevant any more, the others have all become far more complex, and new ones keep being added at an ever increasing pace. Nobody but nobody can know such a high percentage of what's going on as many of us once did. I'm not saying it was better, but I do miss it.
So much this. It ties in with my other comment, to some degree.
Someone here mentioned StackOverflow, but really, a handful of manuals, maybe a good book or two, and some persistence, /usually/ gave you all you needed to figure out a problem, and do something magical.
Now, those resources (if they're available) will likely only help you understand a very small subsystem.
I appreciated that the behavior of that system was fixed for a certain period of time. That word processor would work the same for all eternity (warts and all) if you didn’t intentionally get a version upgrade.
Turbo Pascal came with reference manuals, but also with instructional books that taught you OO programming and Windows UI programming from scratch.
They must have been well-written; I didn't really have Internet access, so there was nowhere else to go if I got stuck. Though I was probably a much more determined learner back then.
IBM mainframe documentation was amazing. I encountered cases of strange edge conditions that would be carefully detailed in some manual even though any given installation would be unlikely to encounter it. (The trick would be finding that given manual, so having your library properly organized helped.)
Agree. I’m around students often. The way they treat me is pretty alienating. I liked the Sir Davos quote from GoT “the young treat us old people with respect because we’re an uncomfortable reminder of the inevitable.”
Just the sense that we were on the cusp of some magical, new, civilization changing thing.
I don't get the same sense that stringing lines of code together can change the world, largely because, where it could, it mostly already has (I am not a believer in the latest wave of AI hype).
What we did used to be magic and was met with gasps and now, it's mostly just expected and complained about if it breaks :/
Actually had an office with a door you could close and a window you could open to actually think in.
Microsoft ran a radio recruitment ad campaign in SV in the late 80s with that exact theme! The narrator exclaimed how hirees would get "... an OFFICE! With a DOOR! That you can CLOSE! So you can THINK!"
There was a lot less stuff, in general. Now you have libraries, protocols, umpteen different languages, paradigms, design patterns, IDEs, runtimes, platform after platform, etc.
I remember all I used to need was a C compiler and a task and basically alone I would be able to complete it with the standard stuff that came with the compiler.
Worked in SW since early 90s. Back then you didn't have to think much about security and you could push things to the limit.
Also things were not as "professional". When I started out my boss told me to figure something out and I would report back weeks or months later. I had the time to make mistakes and learn from them. Today the young devs are often very micromanaged and have no freedom.
On the other hand we can do a lot of cool stuff today and it's amazing how much info is out there. But I think the 90s were more creative. Stuff like StackOverflow is great. Documentation was MUCH better in the 90s.
Elegant, tight, and efficient code mattered back in the days when a machine with a 20 MHz processor and 8 MB of RAM was considered a high-end workstation. You really had to understand what your hardware, your OS, and your compiler was doing in order to produce decent software.
Nowadays, such esoterica is relegated to the tiny niches of systems and embedded development.
My side project right now is flight control/readout software written in assembler for the C64 which will control a virtual spacecraft inside of my lua programmable 3d/physics libretro emulator front end.
I am really enjoying working inside of Turbo Macro Pro. It is an interesting challenge to make the assembly code efficient and easy to understand.
On reflection, the thing I miss about web dev in the '90s is the low user expectations.
Because I was going to say I missed the simplicity of it all -- your front end was just HTML, no CSS (which didn't exist yet) and only sometimes a smidgen of Javascript for like light form validation; your back end was just a Perl script with CGI.pm running behind Apache that rendered that HTML.
No React, no flexbox, no REST API, no microservices, no Docker, no Kubernetes... but the reason it didn't need any of those things is because it had a terrible UI, didn't do all that much, and only needed to support trivial numbers of users whose modems were probably the main bottleneck anyway.
Trying to make modern users happy with '90s era tech would be impossible and deeply painful.
But it was nice, just for a while, to have a world where people were thrilled that even a super-basic web application was a thing that existed.
I still make websites this way because no-one told me to stop. They can be made responsive to things like smartphone browsers which incredibly minimal changes. No complaints so far.
What kind of sites do you make? I’d imagine that avoiding things like react is fine for a lot of sites that just need a bit of form input here and there and some nice styling, but that anything relatively big with interactive pieces would fairly quickly devolve into a difficult to maintain mess without components. I’ve sort of been trained to think that, though, as I was just starting development right before libraries like React started to get big. I remember reading cs books and learning about how important encapsulation and modularity was and then feeling like I wasn’t really able to apply those concepts adequately in my really early web projects. React came along and seemed like the best answer. Do you do something different to organize code related to more complex frontend user interaction than forms/animations, or do you find that you just don’t really need complex frontend user interaction for the websites you make?
Most of the things I've made are not public-facing. I just try to keep things simple. My sites generally require page loads more than the average single page application, but they have the advantage of loading faster and working in nearly any browser, even super old ones.
Yes, it was a simpler time :) There was a job position known as "webmaster" who was basically a god. User expectations were low because users didn't know what to expect. Everything was so new. Putting formerly locked-away resources like job databases and digital libraries online blew people's minds. And we imagined that we were building a utopia where everyone could publish, and information was free..
With respect, I strongly disagree with your assertion that it’s the users demanding anything. Users are rarely asking for our bloated single-page apps; we just foist them on the public because we think JavaScript development is fun and cool. That’s not how we rationalize it to ourselves, of course, but it’s the truth. The majority of web sites (all newspapers, all magazines, many less trafficked social media sites, I could go on) would be served just fine with HTML, CSS, and minimal to no JavaScript.
> Trying to make modern users happy with '90s era tech would be impossible and deeply painful.
Given my experience users can be delighted in 2019 by well-designed and lightweight UI built with just CSS and vanilla JS, instead of an overweight buggy SPA (usually built by engineers more interested by the code itself than solving the business problem in the leanest way). Source: I made that my business and I couldn’t be happier.
You're exceeding their expectations by providing less than they expected. That's easy to do when the user expects to be accosted by a slow loading page that comes onto his screen janky because of deferred stylesheets and 4 different Google fonts and 1.6mb worth of ads.
SPAs are often buggy, but you can’t honestly blame React/Angular for that. I’ve built and actively maintain a number of SPAs in React. With some care JS size and speed is very manageable even in mobile devices.
The thing that consistently kills site performance is ads and trackers. Of the sites I work on, GTM, Optimizely, FullStory, and other similar crap routinely are responsible for >75% of the JS weight and >90% of the HTTP requests. It doesn’t matter how much I prune our npm dependencies and tweak React to make sure it’s rendering fast—marketing is going to make the page suck and I can’t do anything about it besides generate page speed reports that the client will ignore.
Interesting. There were two primary triggers for me creating https://alchemist.camp. One was that the Elixir screencasting I'd used site had very out-dated tutorials that often didn't compile or run on the post 1.0 versions of the language. The second was that I loathed the huge card-based design and the SPA the author moved to.
I just wanted information density and scannability, not hamburger buttons and pages and pages of responsive cards.
Similarly, I'm no fan of Reddit's redesign or the huge lag when loading IH and yet more and more content sites are going the same direction.
True, but when I remember how we used 1x1px Java applet to allow reloading data without refreshing the page I would not call that simpler... And don't even get me started on Flash.
> no REST API
True, but when I remember fumbling about with SOAP I would hardly call that simpler...
> no microservices
True, but what we had instead -- monolithic PHP "applications" with insane hacks to integrate with other monolithic services, Microsoft' and Adobe's attempts to abstract the backend/frontend separation away and so on -- I would not call that simpler...
> no Docker, no Kubernetes
True, but when I remember the deployment mechanisms (upload via FTP), problems with scaling once our server became not enough (usual approach: set-up everything on a separate machine and then have a downtime until it was back up) and so on, I would certainly not call that simpler...
There are always trade-offs, and you continuously have to learn new technologies and unlearn others...
I was tempted to write "computers were so slow and lacking in resources that you were forced to write efficient code". Because efficient code is good, right?
But I lived through that era and being forced to write efficient code is a god-damn nightmare. There were so many ideas flying around that you simply couldn't do because the computing power just didn't exist.
Today people revere things like "vi" but when you were forced to use such basic utilities because your human/machine interface was a 300 baud modem, or even a paper teletype, life wasn't so good.
Late 90's here.
There are two things I miss:
1. Going to the book store and looking through the (mostly) O'Reilly books to see what there is to learn or what new technologies are coming out.
2. Having a huge pile of 3.5" floppies (or even CDs) you are using to load the latest version of Visual studio or whatever and just imagining how much knowledge is contained in those. I think my copy of VC++ was something like 21 floppies.
Speaking as someone who cut my teeth in the 80s and early 90s: I miss the elitism and exclusivity of it. Nowadays the internet has made it so any question can be answered within seconds, but back then you had to scrupulously acquire your information from magazines, Usenet discussions, and just plain experimenting with the code. As things currently stand, programming has become a commodity skill that anyone with a room temperature IQ can learn within a reasonably small time frame. Then, you get on StackExchange and start cobbling together your app from copypasta provided by other programmers.
Yeah. In the 90s I met almost no computer scientists. We all came from different backgrounds and got into programming because we were interested and liked it. Now we have a lot of people who chose it as a well-paying career. Nothing wrong with that but it's less fun.
I'm an applied mathematician that worked in those days with chemists, microbiologists, hydrologists, civil engineers, electronic engineers, physicists and almost every darn flavour of critter _except_ computer scientists.
Learnt a lot of interesting stuff.
Most of their code was utter shit to read and maintain... but then so is that from most recent comp sc graduates...
Not having so many plug-n-play abstractions that you’re so strongly encouraged to use to “not re-invent the wheel”. The problem in my mind is that the abstractions leak all over the place, but we stop caring.
Pushing off compute to the browser because it’s cheaper, nevermind the cost to non-powerhouse phones.
Avoid putting any thought into optimization because compute and memory is cheap. Nevermind that you’ll have to do a complete re-write when a few dozen 600+ ms microservice responses results in 20 second page loads.
Store all the things! You might need them someday, after all. GDPR what?
I work with developers who think that DB migrations are “of the devil”. As a result, they have pivoted to use the RDBMS as a rudimentary k/v store and create the relational data structures in memory. All they need to do is pull a few dozen GB of rows from the DB with every container restart.
So, yeah. I miss having fewer abstractions; having more constraints. The software seems somehow nicer through the CRT-colored lenses.
> Not having so many plug-n-play abstractions that you’re so strongly encouraged to use to “not re-invent the wheel”.
Inventing the wheel, rather than re-inventing it. There was a lot more "doing something for the first time" and less "doing something for the Nth time, slightly differently".
(Or so it felt to me. But there was still a bunch of "doing what the mainframe people did a decade ago, but doing it badly". Still, it felt different.)
Main thing I miss is the lesser degree of abstraction in doing anything. If you wanted to build a simple app which just took one input and did a calculation and returned a result, there were multiple languages, but you didn't need a huge number of libraries, infrastructure, etc. to deploy it -- you just built the code, compiled it, and distributed a binary (and source, with a makefile). There was complexity crossplatform (even across unixes), but there was a period of time in the mid-90s/early 00s where "some form of linux or a BSD" was all I had to care about, and it was pretty easy.
Also, being able to trivially modify almost anything I used (because it was largely open source, and simple).
Lots of things were worse, but less abstraction was pretty nice.
Developers being far less critical of other developers.
We were much more positive in the olden days. Back in the 90s you could post an idea in a developer-oriented usenet group or discussion forum and get pretty decent feedback. If you do that today there's good chance you're going to either get nothing back or you're going to be flamed for using an "anti-pattern". People are far too quick to dismiss things now.
It's probably a function of how everything gets marked with a score now and every post is social proof, but it's quite annoying regardless.
There was a genteel, supportive quality of having a participation base comprised mostly of sincere, interested readers and posters. There were trolls even then, for sure, but they were few and were generally embarrassed into an inert mumbling.
I still remember fondly the debates in comp.lang.c about the first ANSI C standard proposals. Even Henry Spencer's rants against NOALIAS were entertaining.
And where user participation got unproductively unruly, moderated groups served well, like rec.humor.funny.
There was also an open, transparent process for forking groups, generally along natural fracture lines, and for creating new subgroups.
What ultimately ruined Usenet (IMHO) was a falling signal-to-noise ratio, and not just because of spam. The opening of the AOL gateway and the resulting Eternal September proved to be mortal wounds.
I miss building everything from scratch, in assembly, because I could do it better than the libraries that shipped with the system.
I can still do it better today, but the stack is so deep now, I just don’t have the time.
Would I go back if I could? Nah.
Hacking is a blast, but never forget it is to achieve a greater purpose. A greater purpose for our software’s users, for ourselves, and for for our subroutines.
Old hackers never die— we merely gosub without return.
There were very few ready-made frameworks and libraries to get things done, so it was fun writing those meta libraries that runs your business. Of course, purely from a business point of view, this is not ideal and is extremely wasteful. At the same time, it really helped me understand the systems that we use. Maybe that's why people survived without Stackoverflow :)
In comparison, modern software development is almost all about composing or stitching together a bunch of different services. There are other complexities around orchestration and breadth of the systems involved, but very rarely one goes deep into a particular technical problem.
After a really long time, I'm getting a kick out of working on a highly technical problem: an open source search engine from scratch (https://github.com/typesense/typesense). It has been deeply rewarding and definitely something that's missing in a typical web oriented software development career today.
It wasn't always so great across the board. Back in the late 80s or 90s I could write and distribute my own code for free. OTOH, for my day job developing network code on larger machines, we had to pay hefty licensing fees to get a decent compiler. Or debugger. Or libraries to do the most basic kinds of things. Corporate control hadn't come down to the smaller machines, but open source hadn't grown up to the larger ones either.
The dump reading was done with a cardboard pamphlet that listed the machine instructions, arguments, address offsets.
You'd find the hex abend on the greenbar, mark it up with a pencil, and use the machine instructions to figure out what went wrong (and the record that caused it).
In my business (banking) this was done sometime around 2 a.m. after you got called back to work by the night operators.
My systems were core to business operations (manufacturing shop-order control) and always ran between 2-4 AM.
I quickly hardened the shit out of our interfaces so that we (a) wouldn't break and (b) had automatic workarounds for when feeding systems blew up. Oh, how my project leader loved me.
There was little or no evangelism for a particular language/framework/database/stack. People just trusted you to pick the right tools to get the project done, without feeling the need to insist you look at the latest flavour of the month thing out there.
But mostly, I miss the fact that 20+ years ago, programming was still considered a professional, white collar role that engendered respect from the entire organisation. Nowadays, I feel that most coders are lumped together with "support people" and are considered nothing more than replaceable factory line blue collar workers.
That’s a very different experience than I remember. Macho culture dominated: assembler was the king, then C, then C++. LISP or Smalltalk or COBOL people hung out on their own and didn’t talk to each other. Java was a joke usurper at first. Perl, python, ruby were toys. Etc.
IOW language advocacy and flavor of the month were rampant in the late 80s onwards from my POV.
These days at least there is enough community for all of the major languages and even the minor ones.
Also I find programmers get a lot more respect now than they did in the 80s and 90s. Programmers can make $300k+ USD at a top Bay Area company today, and starting salaries are well over $100k. Often they talk directly to users - no handlers or analysts in between to shield people from the “strange programmers”. Attitudes have shifted. Though given your experience, I guess not uniformly.
70's and 80's here. Big fast printers. I know, who does massive code listings or memory dumps anymore? I feel that if I had one, I'd be using it all of the time, though.
When I started in mainframe programming, our organization had a license for a core dump formatting package that would do a lot of cross referencing for you and even break down COBOL into assembler on a line by line basis for you. Well thought out little things like that made a big difference.
154 comments
[ 3.8 ms ] story [ 224 ms ] threadFor example: On an IBM PC, running DOS. You could know all there was to know about the BIOS, hardware ISRs, DOS ISRs, DMA, how a file system works, and maybe a bit about the graphics system, and you could make the machine do anything you wanted.
Today, if my kid wanted to learn all those things, I wouldn't even know where to tell him to start. You simply can't get that low (easily) anymore, or know that much about numerous subsystems. And the higher level stuff, like you say, is buried in layers of abstraction.
Of course, now we have an unprecedented access to cheap, powerful microcontrollers and SBCs, which make up for it to some degree - but it's still harder to translate that knowledge into something of perceived usefulness on a 'proper' computer.
You know, it’s pretty interesting that IBM was painted as the devil, but that they made this standard, interoperable computer system that you could touch at such a low level. Now it’s all Windows 10 and MacBooks and Linux userland, and even if it were possible, good luck finding documentation for any of that.
—Sent from my iPad.
"We build our computers the way we build our cities -- over time, without a plan, on top of ruins." Ellen Ullman
Someone here mentioned StackOverflow, but really, a handful of manuals, maybe a good book or two, and some persistence, /usually/ gave you all you needed to figure out a problem, and do something magical.
Now, those resources (if they're available) will likely only help you understand a very small subsystem.
They must have been well-written; I didn't really have Internet access, so there was nowhere else to go if I got stuck. Though I was probably a much more determined learner back then.
I don't get the same sense that stringing lines of code together can change the world, largely because, where it could, it mostly already has (I am not a believer in the latest wave of AI hype).
What we did used to be magic and was met with gasps and now, it's mostly just expected and complained about if it breaks :/
And then walk down the corridor to the terminal room to turn thoughts into programs and/or ask the other guys or gals.
Strangely enough there were more ladies around in those days.
Miss that.
I remember all I used to need was a C compiler and a task and basically alone I would be able to complete it with the standard stuff that came with the compiler.
Also things were not as "professional". When I started out my boss told me to figure something out and I would report back weeks or months later. I had the time to make mistakes and learn from them. Today the young devs are often very micromanaged and have no freedom.
On the other hand we can do a lot of cool stuff today and it's amazing how much info is out there. But I think the 90s were more creative. Stuff like StackOverflow is great. Documentation was MUCH better in the 90s.
Nowadays, such esoterica is relegated to the tiny niches of systems and embedded development.
I am really enjoying working inside of Turbo Macro Pro. It is an interesting challenge to make the assembly code efficient and easy to understand.
Because I was going to say I missed the simplicity of it all -- your front end was just HTML, no CSS (which didn't exist yet) and only sometimes a smidgen of Javascript for like light form validation; your back end was just a Perl script with CGI.pm running behind Apache that rendered that HTML.
No React, no flexbox, no REST API, no microservices, no Docker, no Kubernetes... but the reason it didn't need any of those things is because it had a terrible UI, didn't do all that much, and only needed to support trivial numbers of users whose modems were probably the main bottleneck anyway.
Trying to make modern users happy with '90s era tech would be impossible and deeply painful.
But it was nice, just for a while, to have a world where people were thrilled that even a super-basic web application was a thing that existed.
:P
Brutalism for President 2020.
Given my experience users can be delighted in 2019 by well-designed and lightweight UI built with just CSS and vanilla JS, instead of an overweight buggy SPA (usually built by engineers more interested by the code itself than solving the business problem in the leanest way). Source: I made that my business and I couldn’t be happier.
You're exceeding their expectations by providing less than they expected. That's easy to do when the user expects to be accosted by a slow loading page that comes onto his screen janky because of deferred stylesheets and 4 different Google fonts and 1.6mb worth of ads.
The thing that consistently kills site performance is ads and trackers. Of the sites I work on, GTM, Optimizely, FullStory, and other similar crap routinely are responsible for >75% of the JS weight and >90% of the HTTP requests. It doesn’t matter how much I prune our npm dependencies and tweak React to make sure it’s rendering fast—marketing is going to make the page suck and I can’t do anything about it besides generate page speed reports that the client will ignore.
I just wanted information density and scannability, not hamburger buttons and pages and pages of responsive cards.
Similarly, I'm no fan of Reddit's redesign or the huge lag when loading IH and yet more and more content sites are going the same direction.
> No React
True, but when I remember how we used 1x1px Java applet to allow reloading data without refreshing the page I would not call that simpler... And don't even get me started on Flash.
> no REST API
True, but when I remember fumbling about with SOAP I would hardly call that simpler...
> no microservices
True, but what we had instead -- monolithic PHP "applications" with insane hacks to integrate with other monolithic services, Microsoft' and Adobe's attempts to abstract the backend/frontend separation away and so on -- I would not call that simpler...
> no Docker, no Kubernetes
True, but when I remember the deployment mechanisms (upload via FTP), problems with scaling once our server became not enough (usual approach: set-up everything on a separate machine and then have a downtime until it was back up) and so on, I would certainly not call that simpler...
There are always trade-offs, and you continuously have to learn new technologies and unlearn others...
But I lived through that era and being forced to write efficient code is a god-damn nightmare. There were so many ideas flying around that you simply couldn't do because the computing power just didn't exist.
Today people revere things like "vi" but when you were forced to use such basic utilities because your human/machine interface was a 300 baud modem, or even a paper teletype, life wasn't so good.
Nostalgia isn't what it used to be.
Things have been dumbed down considerably.
Learnt a lot of interesting stuff.
Most of their code was utter shit to read and maintain... but then so is that from most recent comp sc graduates...
In the Usenet days, you'd find a FAQ with answers curated by the combined reviews of dozens of participants over time.
Pushing off compute to the browser because it’s cheaper, nevermind the cost to non-powerhouse phones.
Avoid putting any thought into optimization because compute and memory is cheap. Nevermind that you’ll have to do a complete re-write when a few dozen 600+ ms microservice responses results in 20 second page loads.
Store all the things! You might need them someday, after all. GDPR what?
I work with developers who think that DB migrations are “of the devil”. As a result, they have pivoted to use the RDBMS as a rudimentary k/v store and create the relational data structures in memory. All they need to do is pull a few dozen GB of rows from the DB with every container restart.
So, yeah. I miss having fewer abstractions; having more constraints. The software seems somehow nicer through the CRT-colored lenses.
Inventing the wheel, rather than re-inventing it. There was a lot more "doing something for the first time" and less "doing something for the Nth time, slightly differently".
(Or so it felt to me. But there was still a bunch of "doing what the mainframe people did a decade ago, but doing it badly". Still, it felt different.)
Also, being able to trivially modify almost anything I used (because it was largely open source, and simple).
Lots of things were worse, but less abstraction was pretty nice.
We were much more positive in the olden days. Back in the 90s you could post an idea in a developer-oriented usenet group or discussion forum and get pretty decent feedback. If you do that today there's good chance you're going to either get nothing back or you're going to be flamed for using an "anti-pattern". People are far too quick to dismiss things now.
It's probably a function of how everything gets marked with a score now and every post is social proof, but it's quite annoying regardless.
There was a genteel, supportive quality of having a participation base comprised mostly of sincere, interested readers and posters. There were trolls even then, for sure, but they were few and were generally embarrassed into an inert mumbling.
I still remember fondly the debates in comp.lang.c about the first ANSI C standard proposals. Even Henry Spencer's rants against NOALIAS were entertaining.
And where user participation got unproductively unruly, moderated groups served well, like rec.humor.funny.
There was also an open, transparent process for forking groups, generally along natural fracture lines, and for creating new subgroups.
What ultimately ruined Usenet (IMHO) was a falling signal-to-noise ratio, and not just because of spam. The opening of the AOL gateway and the resulting Eternal September proved to be mortal wounds.
I can still do it better today, but the stack is so deep now, I just don’t have the time.
Would I go back if I could? Nah.
Hacking is a blast, but never forget it is to achieve a greater purpose. A greater purpose for our software’s users, for ourselves, and for for our subroutines.
Old hackers never die— we merely gosub without return.
In comparison, modern software development is almost all about composing or stitching together a bunch of different services. There are other complexities around orchestration and breadth of the systems involved, but very rarely one goes deep into a particular technical problem.
After a really long time, I'm getting a kick out of working on a highly technical problem: an open source search engine from scratch (https://github.com/typesense/typesense). It has been deeply rewarding and definitely something that's missing in a typical web oriented software development career today.
I was pro-closed source in Turbo Pascal days.... once the licences turned to complete shit I went pure opensource.
The dump reading was done with a cardboard pamphlet that listed the machine instructions, arguments, address offsets.
You'd find the hex abend on the greenbar, mark it up with a pencil, and use the machine instructions to figure out what went wrong (and the record that caused it).
In my business (banking) this was done sometime around 2 a.m. after you got called back to work by the night operators.
Ah, the good old days.
I quickly hardened the shit out of our interfaces so that we (a) wouldn't break and (b) had automatic workarounds for when feeding systems blew up. Oh, how my project leader loved me.
But mostly, I miss the fact that 20+ years ago, programming was still considered a professional, white collar role that engendered respect from the entire organisation. Nowadays, I feel that most coders are lumped together with "support people" and are considered nothing more than replaceable factory line blue collar workers.
IOW language advocacy and flavor of the month were rampant in the late 80s onwards from my POV.
These days at least there is enough community for all of the major languages and even the minor ones.
Also I find programmers get a lot more respect now than they did in the 80s and 90s. Programmers can make $300k+ USD at a top Bay Area company today, and starting salaries are well over $100k. Often they talk directly to users - no handlers or analysts in between to shield people from the “strange programmers”. Attitudes have shifted. Though given your experience, I guess not uniformly.
It took a fair number of pages to get up to speed and a largish chunk of a box of paper just to stop.
Postcript? Ha.
You're joking.