I almost didn't major in Computer Science because in the late 90s, there were so many negative articles in the New York Times, vis-a-vis software. People don't remember it now, but the media and the culture were utterly hostile towards us, and loved to say our jobs were going to India, that everything there was to know about Computer Science could be studied in railyard switching, in existing abstract math textbooks, etc.

By a combination of luck, and my dad's insistence, I ended up at Carnegie Mellon, and while I was there, I saw what folks at Google were doing, and I thought to myself, no, this stuff is hard, and this is just going to be the beginning.

> "It was way too tedious to do. You'd spend hours getting the cards just right. We used to put them in a shoebox and mark them with a pen in case we dropped them on the way to the lab. Then you'd wait until the next day to get your results. If you had a mistake you'd repeat the whole process"

Even what came after that, e.g. in C / C++ was considerably tedious compared to what we do today. Folks sometimes had to do objdumps of compiled binaries to debug what was going on. We had to get coredumps, load them up, and try to determine what memory error had caused things to crash (this is an entire class of problems that doesn't exist today). You used to legit need that CS degree in order to code in your day-to-day because you had to understand the function stack, the network stack, basic syscalls like wait and poll, etc.

It was a lot of work, for relatively little product, and I think part of the reason why software is paid more today is in part because of 1. faster processing speeds and 2. better tooling and automation, and higher-level programming languages – all of which were enabled in part by cheaper / faster CPU speeds (e.g. people don't have to care about how slow Python is – you can optimize it after you find product-market-fit), and 3. a better understanding of how software should be developed, at all levels of management.

I'm glad I'm not the only one who remembers this - whenever I try to explain it to someone they look at me like I'm crazy. In the late 90s and even early 2000s the common wisdom with guidance counselors and even local recruiters was that programming and software design were dead end in the U.S. I remember one article literally said "the bud is off the blossom". I wound up majoring in electrical engineering instead of computer science as a result.

It all worked out in the end, but not following my instincts at the time is one of my few regrets.

It rook my alma mater MIT until 2018 to recognize software worthy of a department in itself (after a huge financial donation). Before then it was a step child of Electrical Engineering. This is kind of ironic because me and most of my classmates ended up writing software for money, though almost none of us majored in that field.

That's because in those days, the term "programming" didn't mean "software development", it referred to data entry. It actually was clerical work, comparable to typing a dictation on a typewriter. Only later, when user interface devices (keyboards, displays) considerably improved and it became more efficient to unify those tasks in one person, did "programming" and "software development" start to become synonymous.

It has nothing to do with "dignity of a male profession", or oppression of women, just a misunderstanding of a shift in the meaning of words.

In the 80s we were mocked and called nerds for being interested in computers, and before and after dot com people thought this was dead end career.

My career advice as a teenager was that there wasn't any point doing software, as Microsoft had made it all already with Microsoft Office.

Just yesterday I was talking to a grad about DevOps. He said the field sounded boring from what he was taught at uni. Then when we discussed it more it turned out his “DevOps” course was actually just teaching them how to be a scrum master and didn’t include a single thing about automation, infrastructure as code, etc.

I also remember just how garbage general publications were with regards to IT. And to be fair they still are now. But there was always a wealth of better information in specialist publications as well as online (particularly by the late 90s).

It's a simple chip, with a simple instruction set, that can actually be taught to you in the time allotted over a three-credit class.

And having computers doesn’t mean any of the lecturers understand the modern (for that era) trends in computing. More often than not, it’s computer clubs rather than cause material that hold the really interesting content.

I don’t doubt there will be exceptions to this rule. But for most people I’ve spoken to or read interviews from, this seems to have been the trend.

Why spend the time futzing with a tool like docker? It's not foundational to machine learning, so learning that tool takes away from time that could be spent learning something more relevant. And the student may or may not use it when they get a job.

And if you want to try two different deep learning frameworks, dependent on different versions of cuda, and want them to not break each other, God help you if you try that without containers.

It's not that they don't have a "course in docker". I understand that. It's that they haven't even heard of it, so they don't even know where to start to look for solutions to problems like that. I have been through that pain myself.

Containers is just one of so many easy things, that make your job so much easier, I've learned the painful way in 20 years as a developer in (mostly) non-elite companies, where no one else knew it either because they hadn't been taught at the local universities, because no one there knew it either.

One evening, I raised my hand and asked when we were going to study TCP/IP.

He simply quipped, "TCP/IP is not a real networking protocol."

So I wouldn't say that universities are always behind the curve :)

1. "DevOps" is an absolutely critical part of automation. It's the reason why we can start tech companies with such small engineering staff compared to 20 years ago. It's as important as all the high-level languages we use. This stuff is the logistics of how software gets deployed. It's the same in business as it is in war. Coding chops is like tactical strategy, and being able to ambush a tank column. It matters, and you won't have an engineering org without it, but the whole chain of how stuff gets deployed and iterated is what keeps the ammo flowing and the fuel pumping.

2. Universities want to teach stuff that'll still be relevant in 50 years. Given their proclivities, that means stuff like algorithms.

On one hand, I think that universities and academics can be somewhat forgiven for their ignorance on this matter. In fact I think we ourselves don't know what's going to be needed in our field in ten, twenty, thirty years. If the folks in industry didn't predict infrastructure-as-code 20 years ago, then the universities couldn't have taught it.

But what I know now is that:

- After all these years, no one is getting rid of shell scripting.

- Old school (i.e. 2nd generation) config management still has its place in many companies. Ansible is great for provisioning an AMI, if you need one, but if you need static infrastructure, puppet and chef are actually better because they track state, which allows you to better manage config drift.

- k8s may be hot and all, but a lot of the underlying "ops" stuff still translates. You average resource usage over pods instead of hosts, for example.

- Put together, there is an "instinct" for ops that is not unlike the "instinct" people learn for math, algorithms, and code. They are completely separate and an engineering org needs both. I think that universities don't "get" ops because computer science is more like math, whereas ops is more like history.

- On one hand, being stuck in an older ops paradigm is pretty awful – if you missed the transition to infrastructure-as-code, then it may be really, really hard to get out of that rut. But the field itself can be pretty bad with being stuck – it took us forever to give up our own datacenter racks.

- But otherwise, the old knowledge about old tools didn't necessarily just go away, in fact it's oftentimes still quite relevant. Linux internals (e.g. iptables) are still useful.

- When I was at CMU, a lot of folks learned some of that ops instinct in the dorm room, and in the computer clusters. But the universities pretty much made it optional. Looking back, I think this was a mistake. Ops is pretty much entirely transmitted through osmosis, whereas we at least try to teach people to code in official uni classes.

I wound up going to school for economics and then later found my way into the IT world by circumstance.

In retrospective, the New York Times is always wrong about everything. Maybe it should be adopted as a useful heuristic

At least with punched cards if you kept them sorted (line numbers in front a'la BASIC really helped with that) you could easily edit in place - just replace that one card that was incorrect, because each card = one line.

TECO (which begat EMACS) started out because paper tape which was preferred storage on DEC machines was harder to edit in place than card stacks and instead of retyping whole program you'd summarise your changes (that you dutifully copied on fanfold greenbar printout - or suffered) into few complex commands then used the resulting 4 tapes (TECO load tape, TECO commands tape, incorrect program, fresh unpunched tape) to get one corrected.

For maximum efficiency, the OS/360 team had to work 24h - the programmers would write their changes on first shift, then teams had to prepare cards, submit them for compilation, night shift reprinted modified documentation, and when you'd arrive at work you'd have fresh documentation and results of your compile (unless you had the luck to work on-line that day with more immediate feedback)

They weren't wrong, though; they just omitted delimiting that assertion.

Back in those dark ages, mainframe jobs were still considered by career "experts" the "adult in the room" jobs of programming. It is hard to convey to people who never studied that era or grew up in that era just how much microprocessor-based computers were considered "not real computing" in vast swathes of the industry. The proprietary Unixes thrived under that lay perception, as a "serious business" microprocessor-based computers market segment.

And the mainframe jobs did by and large up and wholesale decamped to India from large chunks of the mainframe account base. Those career experts were right in a way.

Just not quite the way they thought. The scope they thought in was too absolute because they lacked the technical (and business, and financial...) perspective and context to understand why the same wouldn't happen to quite the same extent to sectors outside mainframes, nor of the explosion of re-invention of the wheel of many mainframe tech stacks that would drive the industry forward even to this day and beyond, along with the rapid recombination of new ideas.

You missed, by a few years at least, the opportunity to study and earn a degree that is no longer available from CMU, the B.S. in Cognitive Linguistics. I got an early acceptance from CMU in late 1988, my first choice of education because I wanted that degree in particular, but I could not afford CMU tuition let alone housing, and I was ineligible for financial aid. I studied CS at Virginia Tech at about a tenth the cost and never regretted it. Though I never met him, Allen Briggs[1] was an underclassman there while I was an upperclassman. He ported NetBSD to 68k Macs while still an undergraduate at Virginia Tech, which always impressed me. A/UX licenses were not cheap, and MacBSD was free.

[1] https://www.netbsd.org/ports/mac68k/history.html

Our computer science department chair (Ed Lazowska) at the time brought this up as a reason to be wary about department expansion in the mid 90s.

You’ll see a huge drop off in computer science graduates after a local peak in 1985 (they wouldn’t get back to that level until 2000, note this article also quotes data from Ed Lazowska).

To me it felt like a golden age. The .com bust hadn't happened yet. If you could turn a computer on there were jobs everywhere. The world was starting to get online. Linux was really gaining traction and Slashdot was all time.

They used to do objdumps. They still do, but they used to too.

The dotcom crash happens later in 2001, but if we are talking about the late 90s, then I’d say it was a period of huge energy in the CS field and tech companies were hiring as fast as they could and jobs were plentiful all around.

And when people today look back with disdain at ugly VB applications and wonder what simpleton, non-programmer, drag-and-dropper built this piece of excrement (that has somehow been running for 17 years without an update and the replacement project that we hired those consultants for ended up 3x over costs and nobody uses it) as opposed to a Real Software Program, there's the reason.

But I imagine we're probably using the same word to describe very different things.

In my team we have reduced the process to having a simple backlog which we work through. But I have seen other teams where you spend enormous amounts of time on planning but it’s frowned upon if you think any further than the next sprint. Just check off tasks without any thoughts about long term architecture or strategy. Basically just a sweatshop with replaceable “resources” (the company doesn’t hire “people” anymore but “resources”)

Granted, that is most of what I see: poorly implemented agile everywhere, usually half embracing SCRUM. I think that has more to do with the typical command and control nature of upper management though.

I'm not trying to denigrate you in any way, I myself switched from working at $BIG_BANK to a more lithe type of company and 90% of that bullshit went away.

Agile + Scrum stuff are minimal and now consume ~4.5% of my week instead of ~12.5%, I'm not spending half my "dev" time babysitting and maintaining giant applications no one really understands in full, and instead work on a bunch of little serverless applications, maybe half of which I do actually understand and can explain end to end.

CTSS -> Multics -> UNIX. All had interactive development and scripting to varying degrees.

I was in school and working in the computer lab when we switched from batch processing (cards) to a time shared system with terminal labs. I was part of the team that wired up the campus and connected the campus to the ARPANET (precursor to the internet).

As we rolled out the terminal labs, each CS class was either assigned to batch processing or time sharing. Since I was part of the lab, I could schedule my classes to be time share only. I was only stuck with 4 classes not in the time share lab. 2 were batch processing. For some reason my LISP and AI classes used a teletype interface. It was not as bad as the cards, but still weird. Some classes allowed me to use my personal computer (TRS80) and work at home.

At the time my uncle was a programmer. He said that there was no future in CS and I should switch majors. I could already see the wave coming and ignored the advice.

As someone who programs for the "enjoyment", as a hobby, and who entered university when FORTRAN was still taught, I still consider programming to be tedious grunt work even with all the advances.

Even today, I would be willing to wager that the "average person" if they were "forced" to program computers would likely characterise the experience as "tedious" and/or "grunt work".

I also do not see programming computers as any more or less important today than in the past. Yes, the use of computers has exploded, an internet was created and it has grown exponentially, but if anything this has resulted in computers being used for less important tasks, with much "programming" being done to support frivolous computer use and transform personal computers into radio or TV-like vectors for advertising. For example, programming computers at NASA was important as early as the 1960s, long before the "internet" or the ability to share even the most uninformed opinions with large audiences instantaneously, at a cost affordable to many hundreds of milions of people.