But looking back on it, I would say out of my current perspective this Mel guy was not a genius, but one of the worst programmers you could probably hire:
He written unmaintainable and even unchangeable "write-once" code that was so complex that nobody else could handle it either. He refused to do what he was payed for and just went away as he lost interest.
One of this kind of dudes on your engineering team and your company is in real deep trouble…
It's a given that you will need to throw away everything they did and start form scratch should any changes be necessary later on. However there's one fundamental constant in software engineering: Your software is going to need to change over time! No mater whatever somebody told you upfront. So in case you've got software built by some "Mel" you're completely screwed at that point, especially as changes to SW are usually needed the most at some critical period in time for your company.
Obviously not. We're talking about mundane business software.
Also the "optimizing compiler" that couldn't reach such levels of "perfection" wouldn't be a thing if this would really matter.
> Mel's tricks were just how things were done back then.
Obviously not. Otherwise there wouldn't be any point in this story.
It points out, with a lot emphasis, how exceptional Mel's code was!
> There was no repo, code didn't need to be maintained or added onto.
VCS dates back quite some time…
Also maintaining code was of course not any less important for a company as it is today. Simply as companies back than also relayed on their software to operate.
> The lifecycle of software was much much shorter.
No, of course not, as nobody would throw away some very expensive asset for no reason.
If anything, lifecycles of software were much longer than today (when you can deploy changes every few minutes if you please). Stuff written in the 70's is still running on some mainframes today!
As changing software was much more dangerous with much higher risk of breakage, less experts around, and everything much more difficult in general, it was more usual to try to not touch an already running system. (Maybe you even heard some quite similar proverb coined back than ;-)).
But "not touching" it does not work, as there is only one truly constant thing: Change.
But it's quite strong. B-)
Let's see. From the story:
>I first met Mel when I went to work for Royal McBee Computer Corp... [The firm] had just started to manufacture the RPC-4000
https://en.wikipedia.org/wiki/LGP-30#RPC_4000
> the General Precision RPC 4000, announced in 1960
https://en.wikipedia.org/wiki/Version_control#History
>IBM's OS/360 IEBUPDTE software update tool dates back to 1962, arguably a precursor to version control system tools. A full system designed for source code control was started in 1972, Source Code Control System for the same system (OS/360).
The events of the story predate the precursors of VCSs by two years, and the earliest true VCS by a decade.
I can't find any definitive info when this computer got actually manufactured ("announced in 1960" doesn't mean strictly the same). But this was the time Mel was met first time by the author.
The story plays likely some time thereafter.
I guess some significant time, because it takes time even for a genius to become familiar enough with a machine to do all this kind of trickery described in the story.
I think it may make sense to assume even some years passed between when the author met Mel the first time and Mel's departure form said company.
So I wouldn't be even so much off with the VCS statement—which actually doesn't state any relation between the usage of VCS and the story. I've only said that "VCS dates back quite some time". Which is obviously true. ;-)
But, all this actually doesn't matter.
The more important statement was the following. Which is a direct reply to "code didn't need to be maintained", which is in my opinion just not true.
I did not say VCS was used back than for that purpose.
I guess they preferred more a sort of solid hard copy. :-)
Certainly if you were a business, you had an extreme business interest in keeping your "known good" stack of cards in a place, and every revision in code required a new stack of cards.
"Hey, the machine just ate 10 cards from the payroll software, can we get duplicates made?"
"No, those were the originals, guess we're SOL no one gets paid" never happened.
Most likely "Ok, version 1.34 of the payroll software that was updated last week? Cards 1032 to 1042? Duplicate cards will be up to you within the hour"
or "We have to revert to the old payroll processing software, can you create a new fresh copy of 1.33, 1.34 has some bugs and we need to get tonights run in?"
There are lots of problems that are specific and simple enough to solve, that it's easier to write a C program from scratch, than it is to find, install and then learn how to do it with some existing package... The same concept goes for programs.. At a certain scale, it's not worth the extra infrastructure/overhead/rigidity/complexity that it takes to write software that's optimized for change.
That said, today, in 2022, it's more or less the opposite, codebases are huge enough that most of software "engineering" is about plumbing together existing libraries, and at that scale, it's an entirely different thing.
We're not talking about embedded software with special constrains here!
This story is about mundane enterprise software.
Nothing in the story justified this insane level of over-engineering and premature optimization.
Just using the "optimizing compiler" was deemed "good enough" for all other needs of the company, likely…
Also nobody asked for that over-"optimized" thow-it-away-and-start-over-if-you-need-to-amend-anything-crap.
I have still this warmth nostalgia feeling when looking at this story, but when thinking about it with quite some experience in real world software engineering I'm very sure that this kind of programmer would be one of the worst hires you could probably run into.
Finding any valid excuses for "write-only" code is hard, very hard. This was also true back in the days this story plays.
Sorry for destroying your nostalgia feeling, but please try to look at it from a professional perspective.
Otherwise it makes no sens. Computers back than where very expensive. You wouldn't use them for anything that wouldn't yield income in some way.
It quite clearly wasn't a "computer game" in today's meaning.
I would call "marketing support software" indeed "mundane enterprise software".
Not so for anything shipped on ROM.
Maybe that's even the point that makes me like the story as such very much.
Still true today.
By the day we didn't even invent some best practices or std. tools everybody in the field would agree on.
CS is still like electrical engineering around 1850. ;-)
Decades later I, still a teenager, asked him something like this: "Dad, you were a FORTRAN programmer and physicist in the 70's, you could be a very well paid developer anywhere in the developed world... why didn't you?"; he answered me: "I didn't thought this thing about computers would go too far."
When I asked him a similar question his reply was (quotes are paraphrased): "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".
Basically it was considered tedious, grunt work in his opinion (at the time...he later of course has come to understand the importance).
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.
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.
To be honest, this prejudice still exists. I heard a C-suite exec mocking "those guys with the ticky-tacky machines".
Not sure of exact time, but I think it was late-60s-to-early-70s; Gramps was a business professor at a major university in the Midwest. A team of math nerds started working on this new thing called a "computer". He said it was almost the size of a basketball gymnasium, it took weeks to get the thing set up, and was always breaking. In the end, it could only do simple calculations. He said the university viewed the project as pretty much a failure. So, Gramps, the futurist, told all his business students not to get involved with computers, there was no future in them. Good job, Gramps.
He later told me his big hope was that none of his students listened to a word he said. LOL
I'd suggest there is likely another reason, and if your father didn't actively think about it he probably understood it subliminally. Back then, programming was part of mathematics at many universities and, like it or not, everyone doing science and engineering had to study the subject—and for many universities that was Fortran. Fortran was essential part of the background culture: if one was doing mathematics or any of the physical sciences, Fortran was just there—thus, one didn't see it as special or exceptional.
I had no option but to study it but I didn't see that as an imposition—diehards like me were regularly chucked out of the punch card room by the university security guards last thing at night when the joint closed.
Moreover, at my university the Fortran lecturer also wrote the Fortran textbook (well, the ones we used at least), so there was no leniency or excuse: Introduction to FORTRAN IV programming using the watfor compiler - 1968 & 1971 and Basic FORTRAN IV programming (version IBM 360), 1969—by John M Blatt: https://en.wikipedia.org/wiki/John_M._Blatt.
As I found out later there were better textbooks on the subject and Blatt was a didactic forceful character without much charisma, so his lectures were somewhat painful. However, comic relief was not that infrequent. We had Fortran lectures in a large hall which had an upper circle like a picture theater, a certain fraternity would frequent the circle and aim paper airplanes at him when he was facing the blackboard much to his chagrin. No, I wasn't one of the guilty but I fully enjoyed the spectacle.
Our community college highlighted their Vax minicomputer by having a special window that showed all the flashing LED's to passers by. But when PC's became the "in thing", they felt embarrassed and covered the window with PC posters. Poor Vax, lots of memories together. It was an early lesson in IT = star-today-washup-tomorrow.
Computers based on integrated circuits were more recent. But the foundations were much older.
For example take the punchcard. Punchcards as a way to work with automatic computing devices go back to Hollerith machines and the 1890 census. That was how IBM got started. The phrase "Super Computing machine" dates back to 1931, and referred to a tabulating machine built for Columbia University. Raytheon was producing and selling analog computers starting in the late 1920s. Much of the calculations for the Manhattan project were done by machines - Feynman talks about this in Surely You Must Be Joking, Mr. Feynman.
And to give a sense of how much history there is, one of my favorite essays in the 1945 essay, As We May Think, which you can find at https://www.theatlantic.com/magazine/archive/1945/07/as-we-m.... It provided the inspiration for both hypertext and the science citation index. The recombining of those ideas in the PageRank patent was the foundation of Google. But how could someone in 1945 understand computing that well? It is simple! Its author was the man who designed those computers Raytheon sold in the 1920s, and among other things was in charge of the development of mechanical computers for the Manhattan Project. (OK, he did a lot more than that...)
I doubt it. If by computer you want to mean any machine capable of mechanically doing some kind of calculation, then of course there are examples going back hundreds of years, or even millenia - the Antikythera device was without doubt a mechanical, astronomical computer, for example. But I wrote "the first commercial computer," and the first stored program, Turing complete computing machine that you could actually write a purchase order and be invoiced for, the UNIVAC I, was only produced in 1951. So, I cheated a bit with "less than 20 years old in 1973." It was 22 years old. The point being in terms of my post, that when I started, computers, and programmers, were still very unusual in the employment landscape, and for people like Ray, of the original post, the concept of being a programmer appeared AFTER their formal education in electronics was finished.
But Turing complete computers predated that. In fact Turing's own design for a Turing machine was NOT a stored program computer. And you're right that the modern idea of programming postdated stored program computers.
But computers are older. As you pointed out, arguably thousands of years older.
However I maintain that automatic tabulating machines were on the path to modern computers. Early accounting applications were based on them, as were key parts of the technology used. Like punch cards.
Does that matter? Depends on your point of view. What I meant by "how new it all seemed" then tells the tale here. Baruch could maybe see the future in 1945 because of his experience and vision. But by 1970 or thereabouts, almost anyone who touched it could see it, and millions were increasingly able to touch it, precisely because it was was commercially produced and generally available. Still not ubiquitous, as they are today, computers were nevertheless showing up in every corner of life.
So it's not that I think computers or information as a processing as a concept, or even as an occasional reality, were new around 1970. But computers as a phenomenon that would define the way interact with each other and the world, and computer programming as a skill that anyone could acquire, really were.
It's hard to explain just how new it all felt, then. But in 1973, even though we were sitting on the cusp of the single chip microprocessor and personal computer revolution, the commercial computer was less than 20 years old, and college recruiting materials might well brag that at their institution, there were not one, but two computers on campus. I remember the day the total RAM at our institution passed the megabyte mark - closer to the end, than the beginning, of the 1970s. The ability to "program" was a rare skill - even the people who taught it were still just learning it.