in some ways it was simpler, but in a lot of ways it wasn't. reference materials back in the day were on actual goddamn paper, or in man/info pages, which seem

in some ways it was simpler, but in a lot of ways it wasn't. reference materials back in the day were on actual goddamn paper, or in man/info pages, which seem weird and archaic nowadays. sure, maybe the tools were simpler, but they were sitting on top of a lot of complexity that you had to know about: fundamental hardware was more diverse in a way we largely don't have to worry about as often. docs seemingly haven't evolved as much though--i can't really point to an MDN of infrastructure knowledge, even if the old manpages are still around. i'd say that the problem now is less a lack of simplicity and more that there just isn't a whole lot of interest in teaching practical usage and operation of the computer systems that underlie a lot of modern tech: from where i sit, /industry/ (individuals are whole different story) is interested in paying well primarily for new development both applications and infrastructure, but has decided that the quality, improvement, and maintenance are more of an afterthought. it's a microcosm of a larger human tendency to prioritize novelty, perhaps. from where i sit, much of the opportunity for a good (well-paid) position is skewed towards greenfield development: if you can build new applications, or architect new infrastructure, great! industry loves you, and will pay you much dosh to do that. if you want to fix or improve existing things, or ensure that new stuff actually works, you're valued less. QA/SDET as an attractive profession appears to have largely ceased to exist, cause you can just assign that work to the greenfield devs, and they can do it sorta--they'll probably focus more on new development, and the QA will suffer for it, but they'll produce enough testing and validation product to tick a box. on the infrastructure end, architects are in great demand, but once that infrastructure is built, you don't "need" anyone to maintain or improve it, or diagnose issues as they arise. i've spent a lot of my career doing tech support work for infrastructure for odd career path reasons, and capable colleagues or counterparts are few and far between: the people i support, who maintain existing systems, seem to have not the slightest idea how they or their underlying protocols work, and other people in support roles seemingly sit on a binary divide of incredibly capable technical diagnosticians and troubleshooters and people who have been shunted into the role for lack of ability to perform in greenfield work, but can't perform in other roles either. management has often asked me why they can't find people who are good at maintaining infrastructure or who are able to diagnose and address emergent problems, but the root of this seems quite obvious. it's not that the systems have grown too complex: they've always been complex, and while the locus of that complexity has perhaps shifted somewhat, i don't think our forebears were operating in some simple, easily-understood world that has ceased to exist. the problem is that nobody wants to pay anywhere near for an advanced brownfield skillset compared to what they'll pay for adjacent skillsets in greenfield work. the smart and capable people recognize this and move towards greenfield work even if they don't like it as much, and brownfield work is left with a sea of people who couldn't transition and can't deal with the complexity because they never could. the complexity or difficulty ain't new, but all the people that could deal with it were driven out.