I also have a problem with calling developers engineers. Heck, I would be offended if someone called me a developer rather than a programmer.
But unfortunately even the degrees themselves become less significant. A PhD in mathematics used to mean more than it does now. But another point is that with global literacy going up, scarse skills are now not based on the amount of people with certain degrees, but rather with inherent abilities that are uncommon. (Take Fortran coders as an example.)
> I also have a problem with calling developers engineers.
I held this point of view for a long time but, after lurking at r/engineering, I've learned that their jobs are (depressingly) similar to ours. I.e. it's almost never deriving things from first principles, but rather trying to quickly bolt together a solution out of pieces looked up at different vendors' catalogs. Most engineers don't even remember the basic equations they have learned at university.
> Heck, I would be offended if someone called me a developer rather than a programmer.
It depends on the specific job, but currently, I can spend 30 minutes changing one line of code followed by one week of deploying, testing it, making sure the configs are all right etc. So that's 30 minutes of programming followed by one week of "installing dishwashers" (as the joke on the team goes). Lately, I see myself more of a software configurator than creator (my nominal job title is a backend web developer).
The new "software engineer" is just a software assembly line worker. I guess the same goes for other engineers. I would imagine the quality of software engineer will get worse over time as it becomes easier to assemble software from an assortment of black boxes.
An assembly line worker just puts parts together - they don't understand why those particular parts have to go together in that particular way to achieve the desired result. Engineer is the person who does.
And engineers have always been assembling boxes together. At first those were the most basic components, like levers. Then we figured out about standardized parts and interfaces, and components got a lot less basic. But, fundamentally, what's the difference between an engineer fitting two cogs together, and an engineer fitting two pieces of electronics?
It is easier. If you wanted to create a web application from the dotcom era, you could probably knock it out faster by one or two orders of magnitude. It will probably look neater too, and you won't spend days or months tuning it so it will look decent in IE. We even have amazing CSS capabilities now.
If you wanted to create something that's better than the pages we had in the Geocities era, you can do that in 5 minutes (download some static page generator, add a theme and voila).
When it was unveiled, the GMail frontend was a remarkable feat of engineering. Nowadays? Polishing to that extent (also scaling, etc) will take time, but creating a knockoff UI is no longer a revolutionary job. Most web developers would be able to single-handedly replicate the basic functionality ('ajax' and lots of client side javascript are no longer arcane).
As web development progressed, so did expectations.
well, so if requirements were easier back then you can't really say things got easier. The stack got harder. you used to be able to get by with asp.net / php and that's it. Yes, you would throw files into ftp and there weren't any stackoverflow or frameworks. But still, the amount of knowledge you needed to keep up was way less than what we have today.
My point: 20 years ago you could learn php and make good money. Nowadays you can't get by without a convoluted front end stack as well, which kinda doubles the amount of knowledge you need to carry.
You can still do simple stuff, it's not hard: just don't use the complex garbage :)
I wrote a web app the other day with vanilla Python, it doesn't do much (it's a tasks app for my wife and I), but it does it's job, and in one file even! It doesn't use fancy front end stuff, just HTML template strings and some links that send CRUD ops to the server, then that saves the data in a big text file. It uses CSS to make it look nice.
I bet I could get a hundred people using it without edits, and it took a few hours. With a proper database and server, it would support thousands easily.
We all do what our managers / tech leads / architects tell us to do in the end of the day. Even if you have a lot of say where you work, eventually you will join a company with an established stack over which you'll have little control.
If you're going to do web development there's zero chance you can keep this up forever unless you're working for yourself.
Don't get me wrong, I wish the industry would do more of what you're describing, unfortunately it's just not happening.
We have top-notch devops stack, but "thanks" to relying on microservices, a lot of changes in software require changing something in the devops part as well, which takes much longer than writing the software change.
I recently tried nix package manager and I gotta say - if your pain point is devops it could take away a sizeable chunk of problems. Steep learning curve though.
I prefer the term "software engineer" for a reason I haven't seen yet in this thread: clarity when speaking to people in other industries.
Among many of the people I talk to on a regular basis, if I told them I was a "developer" they would assume that I was a real estate developer.
If I told them I was a "programmer" it would be a little clearer, but before I moved into software I worked in the events industry for a few years, where "programmer" means "one who develops event programming."
In practice, I could append "software" in front of either "programmer" or "developer" to provide that clarity, but "software engineer" seems to be more common, and to me feels like it more adequately covers the totality of my job, which is as much about measuring, planning, and communicating as it is about producing code.
I think part of the discomfort is that there is no exam that software engineers have to pass (other than a few states) unlike real engineering professions. I suspect and I suspect many others suspect that a large percentage would not actually be able pass a meaningful exam.
However passing such an exam would probably only be partly correlated to success in the field. Part of this is because exams are imperfect, part because success in the field is not dependent on engineering skill, and part is because the tech field’s success is based on finding/creating/replacing/owning (new) markets rather than pure engineering.
If software is much better than what was there before, even shoddy software engineering will be superior to the existing solutions.
The exams and credentials part is certainly murky. One could argue we make it worse in tech. Among the certifications I hold is at least one with "certified engineer" in the title (RHCE), but that's hardly only ambiguous one, with "engineer" showing up in all sorts of vendor and third-party certs and "architect" and "auditor" also finding their way into many others.
Are those phrases misleading? I don't know. I certainly feel like I worked pretty hard to earn and maintain the certifications I hold, but I can't compare the rigour and level of effort to licensure, because that's not required of me for what I do.
I also know that there are quite a few "certifications" out there that aren't rigorous at all, that are basically multiple-choice exams you can cram for without actually learning anything. I've never bothered going after a CompTIA certification for that reason.
It's a tough problem. On one hand, I despise artificial barriers to entry on principle. On the other hand, being able to understand and trust a person's base level of understanding and competence does have value.
The solution IMHO is to perform your own test. It is hard to scale unless you have some superior filter or are a magnet of some sort (back channel references or your company is really hot).
The funny thing is, to be a professional engineer in Canada, the exam you take is more of an ethics and law exam rather than a skills exam. You prove that you've worked for four years or more under a P.Eng and do that exam and you've got your cert.
I immigrated into the US (from Canada) to work for a tech company, and a piece of advice I got from our legal dept was: Whenever you cross the border and the guard asks you what your job is, answer "Software Engineer". IIRC it was important I answer this correctly because that's the role that I was permitted to work for (under a TN, later a H1B; I'm now naturalized). Saying "programmer" or "developer" may have been fine (I don't know), but I do recall some emphasis on getting this right.
It was important because there were specific job requirements that had to be met in order to qualify for a TN visa. The expertise you were expected to be bringing in as a Software Engineer was architectural level knowledge of coding.
The TN visa could be revoked at any time which is why you want to be really clear when crossing the border. I worked for Microsoft and they recommended that I bring my full job description package and lawyer's letter every time I crossed the border
The best part was when I had to go to the border to apply for the TN visa. The poor guy had a list of questions to ask and clearly had no idea what any of it meant. "And will you be doing any <...long, dramatic pause> programming?"
In Canada you can't call yourself an engineer unless you studied engineering in university and went through licensing.
It's not really enforced in tech, but for me the definition is someone who at the minimum studied an engineering degree. Calling yourself an engineer when you studied Computer Science is a bit odd to me.
Lots of CS programs in the US are accredited by ABET [1] (our professional engineering standards board) and graduates from said programs are eligible to take the PE exam.
I call myself an engineer and is anyone has a problem with that, I just point out that I graduated from an engineering college and am eligible to become a PE, and will, should the world ever decide that's an important credential for building software. I work with tons of Mechanical and Aeronautical engineers, none of whom seem to take any issue with my holding a title of engineer.
That list has some rather notable omissions. Stanford isn’t on there, nor is CMU, nor any of the Ivies besides UPenn.
This frustrates me because ABET degrees are required for a bunch of government jobs (and the patent bar). While it might make sense for certain fields, it’s silly to gate CS jobs on a credential that the field evidentially doesn’t take seriously.
Accreditation is weird. I lived with some engineers at university and they had a huge range of interesting courses they could choose. In physics we had mostly core modules and a smattering of electives.
I asked whether they could take the courses they liked (eg mix a bit of civil, mechanical and electrical) and they said in theory they could, in practice nobody does because your degree wouldn't be accredited. And no accredited degree, no job in engineering. I think for civil it made a bigger difference than the others.
I always thought that was quite sad, since the mathematicians did whatever the hell they wanted between maths, engineering, CS and physics and still ended up with a maths degree.
I'm fully OK with the distinction because of the licensing process and strict requirements on engineer-certified work, but as someone with a CS degree from a Canadian university I can tell you with confidence that my friends in the software engineering pathway had probably 90% the same course load as I did.
Really the only major difference at our university (IMO) was that they had a capstone project they did as a group and took two semesters, while mine was done individually and took one semester.
In my experience at UVic (6 months fresh) the CS students did more theory of computation, and SEng had formal requirements and specification writing, engineering economics, and project management courses that CS did not. And also yes, the capstone. So, those are the features which distinguish software big-E iron-ring engineering from computer science, in my mind.
e: and yes, cf. the sibling comment, some of those courses were mandatory curricula set by The Professional Body Formerly Known As APEGBC (I forget what they're called now).
Absolutely, not disputing that. I just took offense to the "Calling yourself an engineer when you studied Computer Science is a bit odd to me" statement. I don't think the degree makes the difference, the licensing does.
I'm suspicious of any attempt to place so much importance on the name of a degree. I'm not even convinced there's a meaningful distinction that can be made between the two. Computer science topics like finite state machines are central to software engineering, and engineering ideas around correctness, safety and reliability form the basis of a lot of CS research.
The main difference is that engineers have a code of ethics they're expected to uphold, with the threat of taking away your certification if you don't.
Note that licencing is country-specific issue. Where i live 'engineer' is just an academic degree on the same level as 'master', just issued by technical university instead of 'general' university.
In Sweden, engineer is also a protected title, but computer science is aligned perfectly with software engineer because engineer basically says 3-5 years of "practical math of that field". Learning Python would not be "practical math", learning the O notation and linear algebra would.
Most US universities from what I've seen don't offer a different track for software engineering vs computer science, it's all under computer science. Most universities also have computer science in the college of engineering.
I think the issue is just university programs aren't granular enough.
Computer Science is an "engineering degree" at many universities. The distinction of which school a degree belongs to at a university is basically arbitrary.
I am definitely against the idea of licensing or professional organizations gating who gets to call themselves something. I think it's OK for an organization to invent their OWN term and branding, but they cannot take a generic word like 'engineering' and add regulatory capture on top of it. For instance, if IEEE or ACM wanted to license programmers, they are free to come up with a process for licensing with a title like "IEEE Software Engineer". The market can decide if that bears any value. But that value has to stand on its own, and not rely on government intervention granting those organizations a monopoly over the term 'engineer'.
which explains what various kinds of engineers actually do. Not at all dry and boring like it might sound! From the YouTube blurb:
Software engineering as it's taught in universities simply doesn't work. It doesn't produce software systems of high quality, and it doesn't produce them for low cost. Sometimes, even when practiced rigorously, it doesn't produce systems at all. That's odd, because in every other field, the term "engineering" is reserved for methods that work. What then, does real software engineering look like?
Sounds like some of the cynicism behind Dijkstra's bit on software engineering[0]
"A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."."
> Really I recall working for one on the big civil consultancies and we had one of our bridges fall of its supports once.
> And lets not mention the new airport in Berlin (or the NYC tube lines) in the context of low cost.
That seems to me a low-quality comment, sorry. The lack of punctuation and the spelling mistakes made it hard to parse, and until you flesh it out more, I'm not sure precisely what point you were trying to make. And more mentioning, less "lets not mention"-ing, please.
Engineers are typically required to have a license, have agreed to some code of ethics, and typically will have a membership in a professional organization. Like mechanical engineers and the SME, or electronic engineers and the IEEE.
Engineer implies a higher level of skill WRT establishing and following processes designed to minimize risk. A software engineer, like their mechanical or civil equivalents, has a strong sense of duty WRT building things that are useful, safe, reproducible, etc.
No doubt the line is gray. But, your stereotypical web app developer (failing fast while chasing a unicorn) is not an engineer.
In the real world, I'd expect Boeing to employ many software engineers [insert 737 Max joke here]. Google and Apple would employ a mix of engineers and developers. And a company that builds CRUD apps on contract would be almost exclusively developers.
All of this ignores the licensed engineer's opinion, which is often that none of us are engineers because we don't have to pass a licensing exam. And often don't even have to pass a particularly rigorous academic program.
Generally, any licensed engineer (PE or non-US equivalent) would be an engineer. That usually means a proof of skills via professional exam. Somebody could have an engineering degree, but not be a practicing engineer at all.
Of course, there is no PE for software. So, within our industry, it's a lot more squishy. There's a bit of "I know it when I see it" here...
If you're building complex systems with an eye for reliability and/or safety, you might be an engineer.
If you're just building a business/consumer app, using infrastructure and tooling that somebody else built and maintains, you might not be an engineer.
With all that said, as a hiring manager, I'm not going to be hung up on what title you held at a previous job, as long as you appear capable of doing the job now. And my career has mostly been on the "just a developer" side of the line - there's nothing wrong with that. I'm simply not building software that has massive negative repercussions if I get it wrong (beyond impact on my employer's bottom line).
> All of this ignores the licensed engineer's opinion, which is often that none of us are engineers because we don't have to pass a licensing exam. And often don't even have to pass a particularly rigorous academic program.
Also, we're not putting our licenses/careers on the line by signing off on software releases. As someone with a degree in Mechanical Engineering (but not a licensed engineer) working as a developer, I think the key difference is the accountability and incentives.
Avionics software and some medical devices do have near-Engineering cultures and practices, but a lot of software would look much different if we had real Software Engineering. Half the IoT malware magnets sold wouldn't ship if someone had to put their professional license on the line with every firmware sign-off.
Not all software would need a practicing Engineer certifying that standardized releases, just like you probably don't need a structural engineer to sign off on your patio expansion or treehouse.
Steam boiler explosions very common in the U.S. (and around the world) until we started requiring licenses to design them with serious consequences for neglecting best practices and procedures. It's one thing to bet your company's reputation and move on to somewhere else if the company fails, but quite another to set aside the corporate veil and be personally responsible.
For a look at what an Engineering-like system would look like, a good friend lives in Vienna, Austria and went to church with Joseph Mangan. [0][1] The short version of the story is that airliner air pressure control valves have three positions: (1) closed, (2) slowly bleed pressure, and (3) wide open to equalize pressure on the ground and better ventilate the cabin. Older designs used separate motors for the two different open positions. Mangan was working for an Airbus subcontractor, writing the firmware for a valve that saved weight and shifted complexity from the mechanical design to firmware by using a single motor. From the closed position, it spun the motor one way to open the valve a small amount, and spun the other way to open the valve a large amount. If the firmware were to malfunction while closing the value, it could turn the motor too far and rapidly depressurize the cabin. In order for the subcontractor to ship the product, Mangan had to sign off that a whole bunch of testing and best practices had been followed. Best practices hadn't been followed, he refused to sign off, and his manager faked his signature. (In particular, one of the required standards was that the first thing the firmware does is initialize the processor's interrupt vector to point to actual interrupt handlers. This wasn't the case.) Mangan ended up stealing a bunch of internal documents and posting them online at great personal cost in order to force the company to follow procedures. In the end, after long court battles, Mangan continued to work on certification of the valve firmware, and he eventually signed off on it once it had really met all applicable standards and he was convinced it was safe.
Engineer: Someone qualified with a B Eng or equivalent. In some countries this requires a masters level as well.
Programmer: A person who writes computer programs. I would personally also imply that the programs are typically not deployment of other programs, but this is my own view and not a standard definition. (Actually all of these are not standard definitions. At least, not anymore.)
Developer: A web developer; A person who writes or deploys applications. In the web era I guess most developers have some inherent focus on the internet as a client interface.
I would also add:
Hacker: A person who likes to probe things until nothing jumps out anymore. (These days people call this a White Hat.)
Cracker: A person who likes to probe things until nothing jumps out anymore. Then they probe some more where they really should not and the police get uneasy. (These days called a Black Hat.)
In my experience most people use them interchangeably with no distinction between them. The only time I've seen anyone show disdain for one term vs another is here on HN.
I've never cared what people refer to me as, and I've never seen anyone voice a preference for it among people I've interacted with.
I call myself a Software Engineer, because pretty much every job title I've had has used that term.
Truth be told, a lot of people with engineering degrees or titles are not doing any real quantitative engineering. Probably some sort of 80 20 rule in any field. Most "engineering" is just organizing and arranging things, fitting building blocks together. A lot of engineers stay "at the bench" just long enough to go into management. The people who keep their quantitative skills end up getting all of that kind of work.
The only anecdotal observation I had is that people in nontech, non SV companies use the term "developer". People in SV style tech companies use the term "engineer". YMMV.
The line is blurring though, as I see the term "engineer" becoming more common in nontech companies too. Just like how leetcode interviews are spreading too.
Back in about 1970, various people realized that writing code was not the cakewalk in the park that everyone (who did electrical or mechanical engineering) thought it would be. See "software crisis".
They decided that "we would have to get serious" about this whole software production thing. Some people like C.A.R. Hoare and Edsger Dijkstra said something to the effect of "formal logic..." to which the reply was, "Hol' up, there. That's too hard." They then assumed the term "software engineering" and went off in the '70s, '80s, and '90s to develop stuff like UML and the software engineeing lifecycle requirements -> code -> testing -> acceptance V-thing.
For the cynical computer science programmery-type person such as myself, the end result seems to have been the software engineering degree, sort of a lite CS degree (just enough to be employable) with more project management and what-not. At least it's more comprehensive than information technology degrees.
Engineer: builds bridges, rockets, cars, missiles, smart tvs, gaming consoles, computers, power stations, electric infrastructure, water treatment plants, etc.
You're a contractor if you work on contract. Just as you're a consultant if you consult.
(I'm most comfortable with "developer" because that corresponds most closely to what what I do feels like. I don't spend so much of my time actually programming, but very little in software is engineering-like)
The same argument used to call a programmer an engineer could be applied to anyone that writes for a living, any doctor, any lawyer, well pretty much anyone. We're all "engineers" unless we're doing something completely mechanical.
According to the dictionary, an "engineer" is a person who designs, builds, or maintains engines, machines, or public works.
A computer is a physical machine that runs programs which are encoded digitally on physical hardware (memory).
I could see an argument for considering a computer program to be an engineered "machine" that runs on a turing-complete computational platform. Just because a computer program is digital doesn't mean that it's not an engineered mechanism. In fact, early computer programs did run on physical hardware in a physically mechanical manner.
A doctor or lawer, on the other hand, is not building any type of machination. They are diagnosing patients and having arguments with judges. What exactly are they engineering?
> According to the dictionary, an "engineer" is a person who designs, builds, or maintains engines, machines, or public works.
That's exactly the point. Programmers write programs. They don't design engines, machines, or public works. Programmers are excluded from the very definition you're quoting.
If you want to expand the definition to include the application of scientific methods to solve a problem, so that it includes someone that creates a Javascript single page web app, there's no way to exclude those other professions. Programs are not machines by any conventional use of the term.
They're considered the same nowadays mostly because they've been doing overlapping jobs. Even worse, 'entrepreneur' is something that tells me absolutely nothing concrete about what the guy does.
But to come to your point, in my mind - an engineer is the one who designs the software, a programmer is the one who actually writes good code to make that design a reality, and a developer is a blanket term for someone who does both (or more) jobs.
To me, those are roles that describe different aspects of software creation. Depending on the job, those roles are needed in different proportions.
Engineers apply math to create systems. Without Newton and his math there wouldn't be engineers or the other way round: engineers are those who create the stuff that is only possible with Newton's math.
Since only few software needs math to that degree, rarely any software is developed by software engineers.
Software developers on the other hand are like real estate developers. They don't build walls, they don't do structural analysis. Instead they combine systems. Unlike real estate developers, they mostly do the plumbing by themselves.
Programmers are to engineers what words (Greek: grams) are to math. They focus on the language and care about expressing ideas in program code.
Then there are also software designers and architects who care about the overall system structure.
> Software developers on the other hand are like real estate developers. They don't build walls, they don't do structural analysis. Instead they combine systems. Unlike real estate developers, they mostly do the plumbing by themselves.
I like this analogy, because it confirms my personal biases/discomfort about web and app developing falling under the same umbrella of "engineering" as nuclear reactor design, missile guidance, and the worldwide chemical industry.
However, to advocate against my biases, in my field (ChemE), most of the fundamental work has been done. Very few BS graduates in chemical engineering will design a distillation column or a chemical reactor. Again, most of the basic science and engineering has been figured out long ago (which is why most research ChemE looks more like chemical physics, molecular/systems biology, and materials science than reactors and unit operations).
So, to an approximation, a chemical engineer won't "build" something. They'll stitch together components that were figured out a century ago. In fact, this was the entire point of "unit operations" -- black boxes that can be represented as a functional transformation on their inputs to produce outputs, and can be solved, quasi-linearly, to estimate the overall inputs and outputs of a chemical process.
In that case, by the same analogy, they wouldn't be "chemical process engineers", but "chemical process developers". Yet I wouldn't suggest a chemical engineer who pulls correlations out of Perry's isn't really an "engineer", so with critical review, it's hard for me to justify a believe that somebody who stitches together APIs for a living isn't equivalently an engineer.
[Edit: a relevant xkcd: https://xkcd.com/1988/ -- Most engineering doesn't seem to be that different]
I don't have an engineering degree, or even a CS degree.
I feel pretty uncomfortable calling myself an engineer since it seems to carry a certain weight of responsibility, but seeing as the title was bestowed upon me by my work place, I'll continue using it.
IMO the designations are meaningless until there is a real standard in place for "software engineer" and what it entails (in the US at least).
I refer to myself as a "programmer" or "developer", but I use them interchangeably.
Anyone putting any real weight on the title is splitting hairs.
I agree, I tend not to call myself an engineer because I don't have a PE license and never took a PE exam (though at one point I almost took the PE exam for electrical engineering). However, I was using the terminology of the article.
On a side note, when people ask what my job is, I usually say "programmer" or "software developer". For some reason I just feel uncomfortable calling myself an "engineer", I think I find it is just a bit pretentious.
I think you're right, it just feels a little wrong to claim a title so easily when others work hard in a specific practise to earn it and have standards designated by law for it.
It's funny, I actually have an undergraduate and graduate degree in engineering - but not software engineering - and I work as a software engineer.
Yet I tell everyone that I'm a programmer/developer. To me, having seen what goes for engineering in other fields, I feel like a small subset of engineering jobs in non-software fields is true engineering. To me, that bar is inventing something worth patenting. I'd say its an even smaller subset in software.
The thing is, I wouldn't say it the highest value work is the stuff that is true engineering. Actually implementing ideas is so much more value adding and difficult in my opinion. Execution and front lines gritty work is incredibly undervalued in every industry. So I prefer to go by developer because I take more pride in that part.
I have no issue calling myself engineer, because I have a degree in Informatics Engineering and in Portugal it is a professional title validated by the Engineers Organization and all universities must have a green light to offer such degrees.
What I have an issue with, is developers feeling like calling themselves "engineer" after a six months bootcamp, or not having any kind of engineering degree to start with.
I have a mechanical engineering BS, but I work as a "software engineer". None of my engineering friends in college had a problem with "software engineer" as a title.
Pretending that engineer is a restricted title does not match the reality of the world today, and is unnecessary at best and creates miscommunication at worst. Language evolves and certain words become more lax and widely applied. We can prevent it in cases that are sufficiently technical (Zoom does not have E2EE, that's a blatant lie), but getting the world to use "literally" as it was originally defined is no longer feasible IMO.
>I also have a problem with calling developers engineers.
Well, I for one am both a developer and an engineer. I have a B. Eng (equivalent) degree in ICT and I work as a full-stack dev. I don't really have a problem with using either "developer" or "software engineer" to describe myself.
> scarse skills are now not based on the amount of people with certain degrees, but rather with inherent abilities that are uncommon. (Take Fortran coders as an example.)
Soft skills and people skills are also scarce skills, in my experience. You can always teach a monkey a new trick (you can always teach a fresh looking young man to program in Python or to solve a differential equation), but you can't as easily teach them to: communicate in a professional manner, talk like a professional to other professionals (both people above you and people below you), write clearly, concisely, and without grammatical or orthographical mistakes, sell yourself or your product, etc.
The geeks will not inherit the Earth. Socially sophisticated people will inherit the Earth.
But unfortunately even the degrees themselves become less significant. A PhD in mathematics used to mean more than it does now. But another point is that with global literacy going up, scarse skills are now not based on the amount of people with certain degrees, but rather with inherent abilities that are uncommon. (Take Fortran coders as an example.)