One (semi-pedantic) quibble with the article: there absolutely are barriers to entry for programming. Programming is hard! These barriers may not be artificial, but they are real.
To use a non-software example, there are barriers to entry to chip manufacturers and power companies even under anarchy. Fabs are tremendously hard to build. Power plants are extremely hard to build. Building up knowledge and skills about computers is also very hard, especially when our genes don't seem to guide us toward thinking highly logically.
And programming is hard because it requires us to understand a bunch of modular systems and then the systems they're built on, all the way down, and in some cases, all the way up. Then, we have to understand the whole integrated system of the individual modules. Not all programming problems require this level of difficulty, but these problems do exist. I've been on teams where I'm the only one who understands what the OS is doing or the CPU is doing or what the network is doing or why some other distributed component might have stopped working. Most of my teammates in these cases seemed to enjoy programming, but didn't care to become overall experts in computers as a whole.
I once had a top-tier business school grad friend claim that programming really isn't that hard and that we're all whiners. He is a genuinely smart person. Today, he himself is trying to code in JavaScript on the client side. He's a friend so I help him, but the problems he has are junior-level or even entry-level. Suffice it to say, I haven't heard much more about how programmers are "whiners" when we say programming is hard.
If you want to know just how hard programming is, try teaching it to someone.
Programmers have to remember a vast amount of domain knowledge. Consider the basic task of choosing where you are going to store some data, well first you need to know which options exist and there's dozens of them (do you want Postgres, SQLite, Redis, LevelDB, ..?). Then you need to know the strengths and weaknesses of each. And I hope you have been keeping your knowledge up-to-date because the answer in 2018 is very different to the answer in 2008.
The lack of barriers to entry actually makes it harder. There are "law schools" and "med schools" to teach you all the knowledge required to become a lawyer or a doctor. There is no "programming school", every programmer is self-taught. A computer science degree hardly scratches the surface.
While there are specialisms, such as game development or embedded development, most programmers are expected to be generalists. You may find yourself needing to write networking code, and there's a whole bunch of knowledge that goes along with that. Or, many programmers end up having a working knowledge of cryptography.
Sure, almost anybody can learn JavaScript or Python, and write code, but learning a programming language is only 1% of the job.
> There are "law schools" and "med schools" to teach you all the knowledge required to become a lawyer or a doctor.
Programmer now, gained a law degree in a previous life. Know lots of folks who studied medicine.
The idea that med school or law school teach you "all the knowledge required to become a lawyer or a doctor" is laughable and a truly absurd statement. The sheer size of the problem domains these subjects cover alone renders this impossible, and furthermore I'd argue it's pretty insulting to insinuate that Computer Science is somehow more difficult in this regard.
While I can't speak fully for medics, a law degree "hardly scratches the surface" as you put it either.
> Programmers have to remember a vast amount of domain knowledge. Consider the basic task of choosing where you are going to store some data, well first you need to know which options exist and there's dozens of them (do you want Postgres, SQLite, Redis, LevelDB, ..?). Then you need to know the strengths and weaknesses of each. And I hope you have been keeping your knowledge up-to-date because the answer in 2018 is very different to the answer in 2008.
I'm pretty sure 90% of us would just look for a Stack Exchange question describing a bunch of popular database platforms and choose whichever looked best after thinking about it for a few minutes, and that outside of extreme circumstances (>terabytes of data, distributed over an actually unreliable network, other exotica) almost any option would work well enough.
Which is to say, programming is complicated but it's not very precise. Compare to mechanical engineering, where if you use the wrong steel your bridge will fall down; or to medicine, where if you prescribe the wrong drug someone might just die. So while there's lots that's useful for a programmer to know, if they don't know it they can get by alright almost all the time, and it's really hard for their managers to tell the difference. (Which is also why we can get away with not having a "programming school" beyond a handful of required courses for a CS degree.) So it's hard for this to seem like a very effective barrier to entry.
Programmers have to remember a vast amount of domain knowledge.
It's even more elementary than that, I think. I've encountered lots of intelligent people who lack any sort of diagnostics skills - absolutely essential for being a programmer.
Things like.. the landline is broken. Well, then, get another phone, plug it in and see if it works. If it does, then it's the phone we need to look at, if it doesn't, we need to move further up the line.
It frequently boggles my mind how many people struggle with simple elimination, experimentation, and narrowing down to resolve problems, and I'm not sure such people could become developers without this ability.
I have an issue with that: law school and medical school certainly do not teach you how to practice law or medicine. Computer science sounds akin to both: you get theoretical underpinnings (many of which are outdated or will be unneeded for your specialty) but all your actual learning is on the job.
> Consider the basic task of choosing where you are going to store some data
Yes, do consider.
In many, many cases the appropriate answer is "whatever stack you're familiar with".
In maybe 10% of cases the answer will boil down to technical requirements and you'll need familiarity with "Postgres, SQLite, Redis, LevelDB, ..."
And that's where the bimodal distribution comes from.
> There are "law schools" and "med schools" to teach you all the knowledge required to become a lawyer or a doctor. There is no "programming school", every programmer is self-taught
I don't know a lot about the law.
But if you think that MDs are not "self-taught" in the same way bootcamp graduates or CS graduates are "self-taught", you should talk to an MD some time.
> If you want to know just how hard programming is, try teaching it to someone.
> The lack of barriers to entry actually makes it harder. There are "law schools" and "med schools" to teach you all the knowledge required to become a lawyer or a doctor. There is no "programming school", every programmer is self-taught. A computer science degree hardly scratches the surface.
+1024
I have said quite a few times that the best CS program is one where you learn how to learn without being spoon fed. In fact, I know a couple great programmers who were _not_ CS (one studied econ; the other, physics), and they similarly learned how to learn without being spoon fed.
Which is why I question the usefulness of a computer science program/degree for the vast majority of dev positions. Learning how to learn would I imagine be the best use of such a degree; but then one with at least half a brain, given a few years in the field, starts to pick that up independently.
I chose to avoid computer science degrees because in those days, in the late 90's, it was pretty much 80-90% math classes. I don't regret getting a degree in a totally different discipline: it turns out learning philosophy, history, linguistics, writing, etc. etc. was far useful to me as a person (and, arguably, a worker) than some boring math classes ever would have been.
Have comp sci curriculums improved in that time? Given that job interviews these days last 4-8 hours, require group approval and whiteboarding in front of an audience, I would argue, NO. Obviously, no one trusts the degree.
The funny thing to me is that you implicitly mention something else in this point. The languages/databases you specify are all popular in web/mobile/end user based applications, and almost exclusively never used in enterprise where C#/java/Sql/Oracle still make the vast majority of tech stacks.
You could add another layer to what you are saying as do you want to build apps? platforms? or enterprise line of business software? if so you need to know entirely different stacks. Then you need to know what is important to being "good" at the chosen stack.
This is just a long winded way of agreeing with you, there are vast amounts of knowledge required to "make it". Most importantly you cant ever feel like you know enough and stop trying to learn. I took about 12 months off from stretching myself and now I feel 3 years behind...
> If you want to know just how hard programming is, try teaching it to someone.
Continuing with the example from the article: law and medicine are also hard. Try teaching those to the same set of people.
> Programmers have to remember a vast amount of domain knowledge.
Programmers are not at all unique in their need to understand significant domain knowledge. Essentially every knowledge-based field, including those with licensing barriers to entry, also have this requirement (and arguably to a greater extent).
> And I hope you have been keeping your knowledge up-to-date because the answer in 2018 is very different to the answer in 2008.
Lawyers and doctors must also keep current with their field and the industry in general. If anything, the degree to which they must keep up with their respective fields seems to be a difference of degree when compared to software developers, not of category.
I don’t think any of this difficulty is the reason why programming enjoys high salaries, because (circling back to the article’s thesis), it isn’t distinct from other fields with higher barriers to entry in that respect.
> Programmers have to remember a vast amount of domain knowledge. Consider the basic task of choosing where you are going to store some data, well first you need to know which options exist and there's dozens of them (do you want Postgres, SQLite, Redis, LevelDB, ..?). Then you need to know the strengths and weaknesses of each. And I hope you have been keeping your knowledge up-to-date because the answer in 2018 is very different to the answer in 2008.
And yet there are a lot of examples of companies that got it wrong, picked objectively-shitty options, and still succeeded massively and then had the money to pour into cleaning up the resulting messes.
There's countless options, but they don't seem to matter as much as people believe. As much as it would be nice to think Lisp is a superweapon and it's easy to replicate Paul Graham's stories, that's not what's happening in the market.
There's an interesting split the OP discusses that seems to largely be a B2C vs B2B thing. With a few exceptions at the high end, many of the winners in both of these spaces aren't determined by "purely better technology" but by other things. However, in the B2B space, battles can be won much more easily on the strength of salespeople and business strategy, whereas in the consumer space, it requires more skilled implementation of ideas - great UX doesn't require technically great programming, but it requires competent execution of the original idea, in a way that a medical records system sold to a hospital administration board doesn't.
if you want to create a CRUD app, then you probably don't need the best and latest library.
There are plenty of apps out there today which support millions of users but didn't choose the most optimal database, wasn't well architected, and has mountains of sloppy technical debt.
You can learn academic computer science, or know a lot of trivia about programming and computers, but without years of dedicated practice it doesn't translate into actual productivity.
In Electrical Engineering, which the article often mentions as a counterexample, the 10-year veteran is not nearly as likely to drop out of the profession. Programming has a constant bleed-out of people who learning how to program, became veterans, and then were dismayed to discover that they were going to have to do it all over again, because the libraries, frameworks, languages, etc. were different. Some just do it, but some move into management or out of the field entirely. This happens in engineering as well, but not nearly as often, and it means there is a more nearly constant shortage, I think.
In my experience, while there is a new library/framework/language every day, most of them aren't introducing brand new concepts that the developer has to worry about. A lot of the patterns they implement are also common in other language/frameworks. Nothing against React, but every other day someone posts a new concept that is very similar to a pattern that has existed for years.
Edit: I should note, on the last sentence, this may be done by a veteran developer who knows better but is trying to introduce the concept in a new light. It could also just be a developer figuring out a common pattern on their own. I've heard the actor model pattern was developed by several different people at the same time who were unaware of each others work. I'm not saying it's a bad thing.
I always wonder if some of the veteran drop-out in programming is that improvement (in my lone experience anyway) is couple with/ consists of realizing what else could go wrong. Every step up the ladder of experience affords a better view of how things can fail and that can be hard to deal with. I feel like I keep getting slower as I get older but not simply because of age; some of it is the motivation to sit down and write something that is probably going to come back and bite me in the ass (possibly through no fault of my own) later on down the line. A lifetime of programming means a whole horde of problems to think about at night.
I think the EE drop out rate may be slower, but from what I see electrical engineers tend to migrate at some point into something that isn't exactly EE. Typically that means systems engineering, management, software, or product management.
You are right. Now thinking about that It seems to me generic Software world seems more comparable to interior designing or fancy restaurants where patrons keep spending because tastes change faster than requirements.
I don't know. Is it having to learn new things, or is it having to do the same things over and over, with the names changed?
Once you get the principles, there isn't much difference in languages, etc. But if you are a senior developer after 5 years, or 3 years, there isn't much room to go up.
I'm not sure they all have a choice, sure you can learn new frameworks or technologies but without real experience it's difficult to demonstrate competence in them. How many employers would hire a Cobol programmer who learnt Angular in their spare time?
There is one point where the article asks why programmers seem to get compensated well compared to other professions.
> The second most common comment that I hear is that, of course programmers are well paid, software companies are worth so much, which makes it inevitable. But there’s nothing inevitable about workers actually being well compensated because a company is profitable. If we look at this list of the most profitable companies per employee, we see companies that pay well, like Alphabet (Google) and Facebook, but we also see hardware companies like Qualcomm, Cisco, TSMC (and arguably ARM now that they’ve been acquired by SoftBank) that don’t even pay as well software companies that don’t turn a profit, and that the compensation between the software companies that are listed isn’t very strongly related to their profit per employee.
The relevant barriers to entry perhaps aren't to programming-the-skill, but programming-the-business-activity. In other words, the barriers to entering business of profiting from programming. And that makes software engineers higher priced commodity because there is higher competition from other companies, but also self-starts.
Hardware companies don't have pay their engineers as well because those engineers have a harder time leaving for other businesses. There are fewer capitalized companies, and self-capitalizing a chip HW business is very difficult. (and arguably the many smaller company options in that industry are rapidly consolidating - so employer options are going down rapidly).
So in the end software is paid well perhaps because the software profession deals with business areas which yield high value return on the labor, _and_ the low capital business barriers to those activites supports higher competition for software labor.
This is absolutely true. I've claimed for years that programming is easy and it's not hard to teach to children, but I started when I was six. For older people, the field is hard to break into due to a cognitive barrier I've seen. "I don't know how to program and computers are mysterious-- therefore I don't know how to learn how to program."
The biggest impediment to much larger participation in the top tiers of software engineering is imposter syndrome and the elitism of the industry when faced with a trainable candidate. Every startup aims to hire someone who can "hit the ground running" and who doesn't need an assist from anyone.
Also, the largest tech companies have chosen to use LeetCode-like problems almost solely to assess candidates, which are unlike most tasks done on the job most days. These tend to select for people who trained specifically for the interview and for coding competitions, such as ACM.
It's not just old people. When I was a kid, the Commodore 64 was the absolute state of the art in consumer computer hardware. What I was able to produce in C64 Basic after a few months of trying was, at least to a first order of approximation, comparable to the sorts of things that were considered professional software back then: the machine just couldn't do that much, so writing a simple game with an amorphous blob that was controlled by the joystick and shot at other amorphous blobs was not _that_ far off from the sorts of games you could buy; I felt like I was doing "real" programming. Compare that to the situation today. Modern games have gigabytes of 3D rendered playfields. Even iphone games like jungle run are in 3D. But what a beginner can produce after a few months of practice still probably looks like something that might have been state-of-the-art on a C64 back in 1986 (in fact, may be harder, because the development tools are so fragmented these days). What felt like a real accomplishment to me when I was 12 feels like failure to my kids - once they realize what a hurdle they have to climb, they wonder if their efforts might be better spent elsewhere.
I think we're kindred spirits in a way. I don't find programming terribly vexing, either (I started when I was 12), but trying to teach others has given me more appreciation for how difficult it is to grok something so rigidly logical.
That said, I have no patience for the "smartest boy" syndrome or the, as you say, "LeetCode-like problems" given in interviews.
I suspect that these interviews do "work" in the sense that they successfully filter those who know what they're doing (albeit rejecting numerous ones who do as well), but they run the risk of encouraging elitism, rockstars and "smartest boy" cultures. (I also think programmers are uniquely bad a hiring because when we can't reduce a problem to something solvable by an algorithm, we tend to try to find the cheapest heuristic.)
Part of that might be because you started so early, but part of it might just be some innate properties of how you think. Is your brain good at programming because you started so young, or did you start so young because your brain is good at programming?
1) programming seems to be one of the only "hard" professions that pays well (compared to math researchers, hard science researchers, or even things like some social work -- that's really hard in entirely different ways). Of course I'm probably missing some hard stuff that pays well
2) programming seems to be the "hardest" of the high paying jobs mentioned. Once you get them, banking, consulting and law jobs actually have a lot of mindless or not super challenging work
I guess the grass is always greener. I'm a lawyer who lurks here occasionally. Most legal jobs involve 60+ hours of work, being on call 24/7, and there is pretty much no legal equivalent of a 10Xer because almost all work is billed by the hour. There is no way to make a contract that's 10x as valuable as your competitor's, and certainly no legal equivalent of scaling to the degree of Google or Facebook.
Law is incredibly challenging work - I know more than one lawyer who complains that they should have went into programming to work 9-5 at Google between free massages and endless burritos or whatever other perks you guys have.
It's certainly not work you can casually do while watching youtube - especially considered there's such a thing as legal malpractice a.k.a. get something less than perfect and you could personally be on the hook for your license. Also, it seems like career longevity in software engineering is a lot higher than in law - most lawyers for the top firms (the Google/Facebook equivalents in pay) wash out by the 4th year and practically all do by the 8th.
I always wondered if I made a mistake picking law over software engineering. I don't have any strong passions and I was good at reading/writing so I went into law, but have been kicking myself for missing out on stock options and equivalent pay for a laid back lifestyle. Glad to see there are programmers who think lawyers have it easy.
Programming is one of the few "hard" jobs that is demanded in very large quantities. There are roughly 1.6 million people working as programmers in the US[1]. That is approximately as many as all engineering professions combined (the largest individual engineering profession is mechanical with 285k). It is roughly 50% more than all life, physical and social sciences combined.
banking - extremely long hours with unpredictable work, huge attrition rate (most people who start in banking don't stay in banking), eventual career progression is into sales
consulting - long hours, weekly travel, huge attrition rate (most people who start in consulting don't stay in consulting), eventual career progression is into sales
law - long hours, high attrition rate (most people who start in big law don't stay in big law), eventual career progression is into sales
At least for me software engineering is much easier than any of those.
> 2) programming seems to be the "hardest" of the high paying jobs mentioned. Once you get them, banking, consulting and law jobs actually have a lot of mindless or not super challenging work
Are you saying this as a programmer, or are you saying this as a banker/consultant/lawyer?
Having been both an attorney and a programmer, the better jobs in both industries will be quite challenging. I personally find writing software much more rewarding than practicing law, but it's certainly not more mentally taxing.
Once you've become a highly paid software engineer it's very human to try and justify your status by claiming that programming is exceptionally hard and therefore your status/salary is justified.
That's not to say that the job isn't hard... but lots of jobs are hard. Dealing with the constant loss of people around you if you work in a retirement home or hospice is also hard; but those jobs aren't rewarded equally.
"Dealing with the constant loss of people around you if you work in a retirement home or hospice is also hard; but those jobs aren't rewarded equally."
That is a completely different sense of the word "hard" from "programming is hard". Working in the retirement home requires enduring emotional pain and sacrifice. Programming (at least some kinds of programming) requires a high degree of skill, knowledge, and intelligence.
The distinction being there may be a larger number of people with the skills to work in a retirement home, than there are people with the skills to write particularly difficult programs.
> Once you've become a highly paid software engineer it's very human to try and justify your status by claiming that programming is exceptionally hard and therefore your status/salary is justified.
Salaries for the vast majority of occupations are driven by the supply and demand for employees - its a job market after all. Demand for programmers is increasing. Supply is increasing too, but is generally limited by, among other things, how technically "hard" the job is. "Deserve" isn't even part of the equation.
Writing software is not difficult. Anyone can do it. The hard part is learning to structure your thinking such that the software you will be writing will actually solve a problem as it currently exists in a cost-effective way.
With that skill, you don't even always need to know how to write software programs. Sometimes, you're better off delegating specific tasks to humans.
When someone hands you a problem like "make this dead elephant disappear" other people will still be scratching their heads after the programmer has already figured out
And they think to themselves, "I can vanish an elephant in two lines." Everyone else is still thinking about the problem in terms of tons. The chewing and swallowing is a trivial implementation detail.
(Meanwhile, some other programmer will be at the north pole wondering what happened to the elephant they left in Cairo.)
Some people simply aren't able to deal with problems they have not encountered before, that are too far beyond their domain of comfort. They can learn, but they don't innovate. As long as such people exist, they will have to pay other people to teach them how to cope with changes in their environment. Software engineers get paid well because a lot of them can effectively solve problems without needing to be domain experts in anything.
Not only is it hard, but the landscape changes frequently. You wouldn't design a system like you designed it pre-mobile, and you wouldn't design a system pre-mobile like you designed it pre-internet, and those are just the big shifts. Cloud is another big shift. A lot of people read how so and so design a system. So and so is successful, so I will design my systems that way. That's rarely ideal. Also, designs can change company to company, depending on what the company structure is, who they serve, etc. Designs can change when a company changes, so hopefully your software can change with it.
Sometimes you inherit a bad system, so how do you fix it while keeping your releases in stride. That's not easy, especially when then original designers aren't there anymore. Speaking of which, what's the best release stride for this company? You might have to adjust design for that too. Was this weird code done on purpose, is it a bug, or were they trying to hack around a mistake somewhere else? Time to roll the dice, because you need to change it. How do you minimize the collateral damage if you are wrong?
You also need to consider your limitations like network and persistence storage. That's a huge part that many haven't even considered yet. How are networks designed today? How is data persistence designed today? What are my options and what are my limitations with this company? What type of reports does this company need? That's a big one. How about failover, what does your system do when the network or database quits? Do you lose any data? Are you sure? How important is it to not lose data? It's not that bad if Facebook loses a post, but it sure is bad if a bank loses half of a transaction.
Programming has a lot of levels that we don't even realize until we hit a new one. Turning good specs into working code is level 1. It takes a hell of a lot of brainpower and abstract thinking to just do that.
> One (semi-pedantic) quibble with the article: there absolutely are barriers to entry for programming. Programming is hard! These barriers may not be artificial, but they are real.
Barriers don’t refer to how hard a discipline is skill-wise, they refer to how hard it is to enter the discipline. Law and medicine are also hard disciplines, but they have actual barriers to entry that cannot be surmounted by self-study. In this sense (which is the sense that the article means), programming does not have those barriers, no.
Considering that, unless you’re going to mount an argument that programming is objectively harder than those other fields skill-wise, it doesn’t seem productive to talk about an orthogonal “barrier” to entry that the other two also share. They are all difficult, so we end up in the same position.
Your comment here has spawned a large thread of people talking about how hard programming is (which frankly seems a bit self-congratulatory for this community, to be honest), but that’s completely separate from the core point being forwarded in the article; vis-a-vis, that programming is interesting and unique precisely because it has such a high compensation for a field without a central body limiting the supply (among other things). Law and medicine are also hard fields, and lawyers and doctors would be happy to explain why they’re difficult and have their own “skill-based” barriers aside from the licensing ones.
I've seen a few variants of this comment, so I wanted to address it.
I don't think we disagree much here.
I agree that medicine in particular is hard on its own. I'm not entirely sure about law, because the legal profession has only become highly-credentialed (in the US at least, which is the subject of this article) relatively recently. Regardless, to not make the trap of my b-school friend, I don't know enough to dispute whether law is super hard. I suspect it's not easy.
(Just as an aside, I'll note that from what I do know about medicine and law, both professions also require an extremely logical approach. I suspect certain specialties in medicine like surgery or anesthesiology or oncology are much harder than programming for various reasons. From cursory web searches, these specialties appear to earn much more than programmers do, and even much more than other physicians.)
Thus, assuming that medicine and law are also very hard (on the same order of difficulty as programming), we can likely say that even without licensing and credentialing requirements, entering the medical or legal professions would be hard.
I suspect we have slightly different ideas when using the term "barriers to entry". Indeed, I might have made a better argument if I had said programming has "high" barriers to entry, since what I'm talking about is clearly a continuum and not a boolean. C'est la vie. When I use "barriers to entry" as a concept, I'm using it broadly. To me, it encapsulates not only legal or political costs, but any cost, which is why I mentioned building a power plant or a semiconductor fab. I am using it the same way I see it used in the various economics literature. In this case, I suspect the cost is that most people seem to feel uncomfortable thinking abstractly and logically, and haven't refined those skills over time. Alternatively, high capital costs are a common contributor to barriers to entry in economic analysis. "Human capital" (another econ term) is exactly how I'd categorize the learning required to practice programming, whether it is acquired through formal training or self-direction.
As far as the self-congratulation, I agree, although that was not my intention. As long as I stay a few standard deviations from Erik Meijer[1] (whom I otherwise deeply respect), I'll consider it a success. ;)
Sure, programming is hard, but so is any job that pays more than the median wage. Hence why they pay more than the median wage. No one refers to "shit is hard" as a barrier-to-entry, because this "barrier" is so ubiquitous, it doesn't even need to be mentioned.
Artificial barriers-to-entry though, such as the licensing requirements for doctors/lawyers, are unique to some specific professions. Hence why they are worth highlighting.
This isn't popular with the "everyone can learn to code" crowd but one significant barrier to becoming a proficient programmer is intelligence.
Maybe intelligence isn't the right word (after all how smart is it really to sit in front of a computer all day shuffling bits around?), a certain way of thinking or aptitude might be better. Education doesn't overcome this, training only partially overcomes this, experience doesn't necessarily overcome this. I bet most of us in the field have come across individuals with high levels of training, perhaps even very "intelligent" individuals who simply fail to fit concepts together in a useful way. Who get the pieces, who can answer quiz questions, who know facts and trivia, but simply cannot bring it all together into a useful, coherent, maintainable whole in a reasonable time frame. And I don't see this barrier being broken.
Anything that can be taught by rote memorization can be automated. Anything that requires higher levels of abstract thinking may never be automated.
Lack of knowledge doesn't neccesarily stop one from programming. There's nothing stopping you from calling yourself a programmer, or applying for programming jobs, and so on. Whereas to be a lawyer or a doctor you usually have to be licensed by some sort of government authority.
Actually, I think that if someone has got to the point where they are dealing with the details of CPU and OS then they’re well along the learning curve.
Many, perhaps most, people have trouble with the basics of programming. Pointers, functions, even basic iteration are concepts that cause a lot of people to flunk out of introductory programming.
Yes, it is. And the example used in the article of chemical engineering reinforces the point. It ties into computer science quite nicely.
To become a chemical engineer, you first have to complete the course work for a degree in chemistry. Chemistry as chemistry is an extremely modular subject matter; you can solve most problems in discrete steps in isolation. In a computer science sense, chemistry is about pure functions. Very easy to analyze, as material side effects (like spontaneous detonation) are rare.
Chemical engineering, on the other hand, is about analyzing systems that leak their state everywhere and have effects that feedback into other parts of the system. But it needs to be extremely efficient nonetheless. There is no isolation because it doesn't exist in real-world complex systems. I have seen excellent chemists absolutely fail to grok chemical engineering even though it is literally the same subject matter. The only difference is that chemical engineers are required to reason about complex distributed systems; as with computer science, only a minority of practitioners ever seem to grok it despite their best efforts. Same problem, different domain. And chemical engineers are paid on a different scale than chemists as a result.
In engineering, bimodal distributions are the sorting of people that naturally have the ability to easily reason about complex distributed systems with many concurrent moving parts and people that cannot. Increasingly, the market is discriminating on this characteristic and it is reflected in wages.
Anecdotally, it is somewhat well-known that people competent at chemical engineering find advanced software engineering to be intuitive; it is a very easy second "language" to pick up. An inordinate number of chemical engineers end up in high paying software engineering careers -- it comes very naturally and lends itself to the abstract analytical toolset you develop as a chemical engineer.
>To become a chemical engineer, you first have to complete the course work for a degree in chemistry.
That is incorrect.
Look at the programme of study for a chemical engineering undergraduate degree [1]. It doesn't cover anywhere near the same content as an undergraduate chemistry degree [2].
I was typing a similar response. I did a 4-year MEng in ChemEng and there were only a few non-elective courses in organic and physical chemistry. The bulk of the content is fluid mechanics, thermodynamics, vessel design, safety, control systems, mathematics etc.
I probably over-generalized from my own experience. The only chemistry degree coursework we could avoid was a class about lab operations, basically safety/hazard management.
This turned it into a de facto 5-year degree even though they stripped most of the non-related coursework to a bare minimum; you still had two years of coursework for the engineering program after the chemistry. People that lost their appetite for chemical engineering after compressing all their chemistry into three years could switch to chemistry, which meant they spent their last year taking the filler non-technical courses that the engineers were allowed to avoid.
It was nearly correct in my case: While getting a BS in ChemE at CU Boulder, I also earned a got a minor in chemistry and biochemistry (and inorganic chemistry, but I was only allowed two minors for whatever reason).
> In engineering, bimodal distributions are the sorting of people that naturally have the ability to easily reason about complex distributed systems with many concurrent moving parts and people that cannot. Increasingly, the market is discriminating on this characteristic and it is reflected in wages.
What faith in the system :). The truth I think is "it's who you know" more than "what you know". The best paid engineers are ones who spend a lot of time positioning themselves to get well paid. Why that is bi-modal I can't be sure - but my guess is that once you hit a certain network effect you start to make a lot more.
Tbt, I haven't seen that much evidence that correlates developer ability with salary. For example, developers living in the Silicon Valley are paid the most. Not because they are the best, but because they are living in the Silicon Valley. Geographical factors play a much bigger role in compensation than developer ability.
But that 'greater' SV salary for a junior developer can give you less purchasing power than a 'lower' salary for a senior somewhere in Europe, due to cost of living.
Granted, money is 'absolute' if you use it to e.g travel around the world, but most people don't do that. In general money is 'relative' to one's environment.
Have you investigated the correlation between developer location and developer ability?
Do you think developers who are very good want to work with the best, thinking the best are in SV, then move to SV? Or perhaps they think they'll get the best return on their effort if they're working on software with big impact, and software with the biggest consumer impact is mostly written in SV?
So you're pointing to the ability to manage complexity? I had not heard it put that way before but it feels right to me. From TFA the author said
"How is it possible that programmers are paid so well without these other barriers to entry that similarly remunerative fields have? "
My initial thought was that there are people who get it those that don't. But you can teach many people the tools of programming. It's using those tools to do something interesting that seems to be the challenge. By interesting I suppose I mean something exceeding some level of complexity.
This makes sense, I don't see our schools teaching anything too complex - it tends to be compartmentalized.
Also, because software developers are like soldiers or litigation lawyers. The more other people have, the more you will need.
If company X is your competitor, and they employ 10 software developers, sooner or later, whatever it is they're working on will release, and that might provide X with a massive competitive advantage over you. So you have to hire your own people to keep up with your side of the arms race. And sometimes, a brand new person comes along with a bunch of software folks to create company Y, and they devastate both you and X within their first 5 years.
> Anecdotally, it is somewhat well-known that people competent at chemical engineering find advanced software engineering to be intuitive; it is a very easy second "language" to pick up. An inordinate number of chemical engineers end up in high paying software engineering careers -- it comes very naturally and lends itself to the abstract analytical toolset you develop as a chemical engineer.
As someone trained as a chemical engineer who now is a Data Engineer (SQL & Python pipe fitter), feel free to add me to your anec-data :-)
I thought it was just because the GAFA tech giants are currently in a bidding war for programmers in a very expensive part of the country. I've met and worked with many very talented engineers, fully capable of grokking complex systems, not working in Silicon Valley.
I'd definitely call that the best explanation. You spend a few years working at a GAFAM, and now you've got a hugely prestigious resume from an expensive, high-cost-of-living area that other companies will shell out for, big time. You spend any time outside that cluster, even doing excellent and difficult work, and you just don't have the prestige.
It's also a matter of scale: the GAFAMs just ship more units in terms of revenue per employee. Sure, that's largely because of monopoly and network effects, but hey.
Fascinating argument, which fits me well (PhD ChemE who learned software and is now SWE at large tech firm).
Allow me to take an alternative argument: Highly-driven students, especially those driven by money, became ChemEs to earn a lot of money and prestige. They looked up highest paying majors and chose ChemE for these reasons. I think it is now obvious SWE is very high paying and prestigious -- perhaps more so than ChemE -- so these highly-driven people switched. It had nothing to do with the topics intrinsically, but rather ChemE was largely perceived as the hardest/most-prestigious field and now SWE is.
To offer my own anecdote: In pure/theoretical Chemistry you conveniently ignore in-situ solvation effects to think about mechanisms of the organic reaction.
Then in the real world, you can't replicate someone else's paper because of humidity differences between your lab and the author's.
> as material side effects (like spontaneous detonation) are rare.
My father has been responsible for every chemical (including, explicitly, explosives) factory in the entire country (Hungary, 80s) and later for just one pharmaceutical company for those "side effects" to stay rare. They do not stay rare without some very stern rules.
The OP was explicitly referring to the difference between chemistry in the lab (when you can conduct perfectly isolated, small scale experiments -> very low risks) and chemistry in industry (which is what you're referring to), where risks are much higher.
>Chemical engineering, on the other hand, is about analyzing systems that leak their state everywhere and have effects that feedback into other parts of the system. But it needs to be extremely efficient nonetheless. There is no isolation because it doesn't exist in real-world complex systems.
Is it not possible to engineer in isolation on real world complex chemical engineering system?
I try to do that with software, and most software can certainly benefit from stricter isolation (e.g. looser coupling), but most software teams - even well paid ones - often have an in-built bias against investing in less tangible work which means that you ultimately end up with these complex systems are that hard to reason about.
Not that I feel like I should be complaining about this if it is indeed the reason I'm paid well.
Almost all professional and semi-professional salaries are becoming bimodal.
I'm too tired at the moment to look this up, but the NY Times had a piece sometime in the last couple of years where they were discussing income distributions, and had an interactive, and what they looked like, almost across the board, was a bigger lower mode, and then a second, smaller, more spiked mode much higher.
What struck me about that piece was that it was framed in terms of skewed incomes, but the bimodality of it didn't get discussed much at all, nor the fact it was so widespread across different disciplines.
To me it was very disturbing, because it suggested that there was a growth, across disciplines, of two "classes", one established, with a relatively large income, and another, larger class, with a much smaller income.
I was very curious about this, and have wondered what the groups are--if it's because of older, senior individuals and younger, junior individuals. Maybe the latter are trainees? Maybe the latter came into the labor market at a less favorable time? Maybe there's just a kind of winner-takes-all sort of phenomenon?
It was really disturbing to me, and seems difficult to explain in terms of any specific features of any field, because it was so, so widespread across labor areas. It was partially disturbing that it was sitting right here in these graphs at a major news outlet about income distributions, and was not being acknowledged even then. It was probably more disturbing to me than the general long-tailed skewed income distribution that gets discussed, because it suggested (at least to me) very unnatural about how incomes were being allocated, even more so than the stereotypical long-tailed but unimodal curve.
I can imagine a simple explanation where one mode of gratification aims to pay as low as possible to keep the workforce willing to work at all, and another mode is to use pay amount to avoid talent from going away. Pay is thought about and used differently in both modes, and it's a simple enough management pattern that it could translate to every field.
This is an over simplistic hypothesis and it would need more info to confirm but it seems potentially reasonable to me.
I think that's true from the management side. I also think it reflects personalities on the employee side: you have to be able to risk rejection and possibly worse to ask for a significant raise which means you either need to be very risk tolerant or in a situation where you can afford to fail.
>Another possibility is that U.S. immigration laws act as a protectionist barrier to prop up programmer compensation. It seems impossible for this to last (why shouldn’t there by really valuable non-U.S. companies), but it does appear to be somewhat true for now.
I feel like this is the real issue here. The reason that the US has great companies is simply from the availability of large amounts of capital. And if the millions and millions of Indian, Chinese, and Eastern European programmers who are inifinitely more talented/driven/intelligent/educated than myself were able to simply move here and seek employment with no immigration restraints, I know that I would be out of a job instantly. In that sense it feels perversly exploitative and priveleged to make so much more money than practically anyone else on earth due to nothing but the physical location I was born.
> In that sense it feels perversly exploitative and priveleged to make so much more money than practically anyone else on earth due to nothing but the physical location I was born.
Is it perverse to go swimming because you were born near a beach? Is it perverse to visit the Louvre if you are Parisian? Is it perverse to go to a good university because the universities in Elbonia aren't good?
You're not entirely wrong, but that's a very limited view on how the world works. It's not all random. We're not all rolling dice and separating into "haves" and "haven'ts".
Once upon a time: Somebody's parents moved to the coast. Somebody's predecessors funded and built the Louvre (and managed to keep priceless things safe despite war, disease, famine, etc.). Various parties spent decades (or centuries!) of history recruiting and utilizing world-class talent, raising world-class capital reserves, and building world-class facilities for their universities.
> Is it perverse to go swimming because you were born near a beach? Is it perverse to visit the Louvre if you are Parisian? Is it perverse to go to a good university because the universities in Elbonia aren't good?
If you actively promote or passively allow politicians and legislation that bars other people from having a shot at earning those things themselves, then yes.
The difference is that others' lack of access to the Louvre or the beach isn't preventing them from feeding their families.
To a degree, we should feel bad for having access to capital when there are far greater needs for this capital elsewhere. Most of us don't have any real power to change the situation unfortunately. But it is definitely something to be conscious of and you should reflect on what you can do to help turn the tide for those less fortunate.
I don't understand the self-loathing that is so popular these days. Somehow we've convinced a generation of perfectly decent human beings that they are "exploiting" the weak and that their "privilege" is oppressing the rest of the world, just by going about their business.
You're a programmer. Maybe you're decent, maybe you're not. It is VERY unlikely that the "millions and millions" of "infinitely more talented" Eastern European/Indian/Chinese programmers you mention actually exist. And even if they did, there are many societal and economic reasons besides "US Immigration Laws" that would prevent them from coming here and taking your job for an order of magnitude less money.
Truth be told, most software development doesn't require a high amount of intelligence, skill, or innate talent.
I'm not afraid of a superior person taking my job. They would be no better at it than I am. I would probably be more productive if I were less intelligent (or on booze, but employers frown on that).
I don't know what type of code you write, or where you went to school, but I had a professor who actually put the exam score distribution on the whiteboard after each test in a second level CS class, and the bimodal distribution was stark. And these are people motivated or interested enough to spend their academic career pursuing it beyond intro level washout.
This is wrong. Even simple software requires a radically different way of thinking than the way most are trained. I've taught 6th graders how to code and it is clear that the way of approaching problems and creating solutions (i.e. creative thinking, intellectual curiosity, and willingness to collaborate and ask questions) really separates the students from who "get it" and thse who don't. Don't sell it short because the industry has made tools and languages that abstract over some of the simpler concepts for entry-level tasks.
This is true. I recently applied for a job in the US and one in the UK. In the US, I got a ridiculously good salary offer. The UK job's compensation was maybe half what the US job offered. My cost of living is also lower than the folks in London, so it's just perverse no matter how you slice it.
I honestly don't think it will last, though. Economically, it just doesn't make sense. My recommendation to any of my fellow US developers: save as much as you can while the money is good.
To be honest, I think if anything the trend will continue and the salaries will go up. There will still be a shortage of highly skilled developers who demand higher salaries. At my company we've been trying to hire a senior frontend developer for the last 6 months; it's hard, especially outside of major tech areas. Most people come unprepared, lie in their resumes, and suffer intensely from the Dunning Kruger effect. I don't see this trend of lying to get the job that pays good money to stop anytime soon. Out the 1.6M programmers employed in the US, I think a large portion still have the job because companies are desperate to hire, but don't know how hire for this industry.
Have you seen the revenues? Have you seen the stock prices? Besides that they obviously can afford to keep raising salaries to compete with each other, they also have to keep raising salaries to compete with the devs. Market entry has such a low barrier, they have to essentially pay every developer to not simply take their knowledge, walk out the door, and set up their own shingle.
Someone in my family has fought for the US in every war since the civil war. They have fought, bled, and died for this country, paid taxes, and helped build it from a weak country to the most powerful civilization in human history. They did it because they wanted their children and grandchildren to have a better life. Why should I feel guilty about this?
>Another possibility is that U.S. immigration laws act as a protectionist barrier to prop up programmer compensation. It seems impossible for this to last (why shouldn’t there by really valuable non-U.S. companies), but it does appear to be somewhat true for now.
I find this quote confusing. Historically, the poaching of highly-skilled foreigners has been an important step in developing mere import substitutions into products which can be competitive on a global scale.
The Tudor government (Henry VII-Elizabeth I) kicked off its finished-wool-import-substitution program by poaching skilled weavers and machinists from the low countries (e.g. Flanders, Holland, France). Then, as the export of finished wool goods grew, so did restrictions on the exportation of raw materials and the importation of finished wool. Nearly 100 years later, England had the ability to drive European countries to famine by simply banning the export of raw wool.[0]
In the early 18th century, France started poaching British watchmakers, weavers and metalworkers; Britain responded by outlawing the emigration of skilled workers in 1719.[1]
With that context, I find it odd to hear that U.S. immigration policy has started to work in opposition to the what I believe is the largest benefit of immigration. What incentive is there to keep highly skilled workers, along with their advanced knowledge, out of the U.S.?
[0] - Chang, Ha-Joon. Bad Samaritans: The Myth of Free Trade and the Secret History of Capitalism. New York, NY: Bloomsbury Press, 2008. Print. pg. 40-42
[1] - Chang, Ha-Joon. Bad Samaritans: The Myth of Free Trade and the Secret History of Capitalism. New York, NY: Bloomsbury Press, 2008. Print. pg. 129
> And if the millions and millions of Indian, Chinese, and Eastern European programmers who are inifinitely more talented/driven/intelligent/educated than myself were able to simply move here and seek employment with no immigration restraints, I know that I would be out of a job instantly.
Couldn't you say the same thing about other professions?
Where's all the great Indian, Chinese and Eastern European software? Seriously wondering, because most software I saw from these regions was mediocre at best.
The whole world uses operating systems, browsers and development tools made in western countries.
The best ones are making all the software that western companies use. The US (coast) pays an absurdly average high salary as compared to other countries for CS roles.
Now, the quality of engineering education received at top CS/engg. institutes and a local college is night and day. This means that only a small subset of the graduating engineers get any decent quality of education.
Most of these people, often considered the cream of the crop are poached by the aforementioned western companies or go for graduate studies.
Graduate institutes in India are underwhelming, so these students land up in the west as well.
The rest of the cream have to choose between software engineering roles that pay around $15-25k with very little vertical movement and business analyst/ consultancy roles where you might earn a bit more and have a much clearer clearer progression up the ladder. These are often referred to as the MBA crowd.
Look at people like Sanjay Ghemawat, whose achievements are as noteworthy as Jeff Dean, having been a fundamental part of developing MapReduce, BigTable, Tensorflow, GFS and Spanner.
It is actually a very ironic situation. One one hand the US is complaining about negative intellectual biases against Asian immigrants, while both the Indian and Chinese govt. are lamenting how they are losing the cream of the crop to the US as well.
If both are the be believed, India and China's best are leaving the countries, but the US is not getting competent people from these countries. So, I guess these people have vanished into thin air. In the mean time Chinese and Indians increasingly churn out ground breaking papers and research in CS.
My experience is that culturally, places outside of North America and West Europe have lagged in attitudes to software development. Tech is still referred to as "IT" and engineers are still seen as code-monkeys or a cost-centre.
This is very much changing, especially in China, but I presume there is still some lag. The other thing worth bearing in mind is that Chinese products are very insular. They are slow to get localized if ever so unless you have a reason to be going out to download them, you are unlikely to ever be using them.
Eh, nginx? All JetBrains IDEs? Yandex still beating Google locally? Ukraine being a huge outsourcing hub for US companies? China having ten clones for every service blocked by GFW?
And where's the great German, English, French, Japanese etc. software? The truth is that the global software market is thoroughly dominated by American companies, probably in large part due to its unique investing environment (lots of VCs willing to take risks on startups).
The job of government is to represent the interests of its citizens. Purposely lowering the standard of living of citizens via unlimited immigration is a great way to get yourself out of office.
I think that’s a touch more complex a problem than you’re making it out to be.
Maybe you were born in the right place for the economical opportunity for someone born “lower” (please be generous with my terms here), but maybe it’s that these others were born “higher” to a place where higher education is easier to accumulate granting them a severe advantage competitively should you have to compete in an economic arena on the same level.
Or do we accept that being born to an economic disadvantage due to whatever factors mean you should be solely relegated to your caste of manual labour, service occupations, or direct servitude?
Second to that problem is what value does higher education really have in application in what are varied circumstances.
My understanding was the founding of the US was quite counter to that idea— and it’s one ideal that many countries have thankfully sought to incorporate.
Though I think you’re on to a problem—one that includes the consideration that current rules don’t exactly line up with the values we might wish to pursue as a (human, global) society. Partly because it might be necessary in what appears to be a period of transition.
Ask the other side of the equation: why don't their countries have well-heeled tech companies attracting capital and ideas with the same investment opportunity so that they can live a comparable lifestyle to you where they come from?
It seems like there should be more arbitrage? Google at least has engineering offices all over the world. If immigration barriers were the main issue, it seems like more companies should be doing the same.
I don't completely disagree with you, but software development as a job is not purely based on how talented of a coder you are. There are many, many other aspects to the job that really have nothing to do with computers/computer science.
Instead of worrying about potential foreigners competing for your job, you should wonder why there are so few jobs out there: it's because the rich are hoarding them. The money for them, that is. There is so much work to be done, plenty of work for you and your Indian and Chinese friends to all have well-paying jobs. The reason we all don't have them is that we are just extremely bad at allocating resources: we choose the most inefficient method, market capitalism. We, essentially at random, select a tiny group of elite wealth hoarders who centrally plan and distribute nearly all of the world's wealth without any concern for social good or welfare or anything other than their continued accumulation of wealth and power. Then we beg them to give us jobs, to give us their table scraps and we fight each other for them, terrified at any moment our benefactors might take away our livelihood instead of rolling up our sleeves and getting to work.
I completely agree that the main problem is lack of spending money in the hands of people who actually need it. There's plenty of work to be done, if only the people who need it had money to pay for it.
However, capitalism (in the form of Walmart and its suppliers, for example) does seem quite efficient at supplying material things to poor people. More spending power in the right places would go pretty far to fix the problem, along with boosting the economy.
I think the reason for high compensations is that software is the enabling factor for capital.
If software can automate, reduce inefficiencies and generally be the means to accomplish the business goal, then it makes sense for the business side to invest heavily into what is essentially a competitive differentiator.
The bimodal compensation reflects a growing split between software activities that are seen as an necessary operational burden, and those which are the "secret sauce" of the business. That's why fintech has traditionally been the highest paying field, as the return on investment is the most obvious for them.
Of course, salaries are largely determined by the industry one is in. If you can position yourself at a place in the economy that attracts large amounts of money (per person) then you will be able to siphon off a relatively large amount for yourself.
As software embeds itself in everything we do, developer earning potential will reflect the industry one is in.
High tech firms like Apple and Google make huge amounts of money per employee, so people that work for them make huge amounts of money too. Not just software developers, but also people in sales and strategy, etc. Same for people in finance.
I agree. I wonder why people do not make this correlation more often that cloud/fintech companies etc have likely put huge number of people out of work across the world. And disproportional chunk of that compensation has been collected by cloud companies and their employees.
I think the explanation for bimodal dev salaries is pretty clear, and is similar to the explanation for the bi-modality in Lawyer salaries.
Google, Facebook, Amazon, and whatever other big name you want to throw in the pot, are competing for developers. However, they are not competing for the same developers as Epic Systems, for example. FAANG (or whatever) are competing for a highly skilled subset of devs that can meet their demanding hiring criteria. Similarly, top law firms are only competing for a subset of all law grads -- those that meet their demanding hiring criteria.
The difference here is that, in law, that criteria is focused around a prestigious degree. Presumably, this is because it is hard to thoroughly test a lawyer's competency as a lawyer in an interview setting. However, in programming, many top companies, apparently, find that a series of intense whiteboard interviews are sufficient to determine whether or not a dev meets their high standard.
However, we also have a shortage of devs across the board, for all companies. If CS enrollment increased by 100%, then presumably the "lower" distribution of salaries would stabilize at a lower number -- probably close to what traditional engineers make nowadays. However, the salaries of the GooBooks of the world will only be affected if a sufficiently high proportion of those grads can meet a very difficult hiring criteria.
Similarly, law schools have seen a dramatic increase in enrollment over the past few decades. Lower salaries have stabilized, since the market is now saturated. However, the salaries for top law firms remain high, because a similarly low number of candidates meet their difficult hiring criteria: Harvard, Yale, and etc. are producing more or less the same number of law grads as before, with respect to demand.
This is why Google can open an office across the street from Epic and yet still pay devs twice as much. This is also why I don't think immigration is a huge factor. Sure, if companies were able to immigrate significantly more workers, then salaries at top companies might drop to a degree. But the real drop would be seen in the salaries of devs at typical companies.
Lawyer salaries are bimodal for a very specific reason. No law firms really believe that a graduate in the top 9% is worth 160k/year, but a graduate in the 11th percentile is only worth 60k.
But they all have to pay the same because it's a signal to their clients that they are the best. If they paid less than their clients would consider their firm second tier not top tier.
And Google is hiring the same devs as everyone else. Having worked in a large company and seeing several people move to Google. They got some smart devs who stood out on their team, but they also got mediocre devs. The average dev they poached was definitely better than the average dev who worked there but it was a moderate difference in degree not kind.
Maybe, but top firms are still only hiring lawyers from top schools. And as far as salaries go, that bottleneck is the only differentiating factor.
You could also argue that maybe Facebook doesn't need devs to be able to independently produce Tarjan's algorithm while standing on their heads, blindfolded. But for some reason, these companies believe that it is essential. Maybe that's well-founded -- maybe not. But it remains the case.
I think skill differentials in programming is a contributing factor to the bimodal distribution. I think there's also another factor which is the degree to which one is an active "curator" of one's own career. I've known some devs who were quite talented but were perfectly content to stay at low-paying jobs where the value they generated for their companies for developing CRUD or other low-multiplier apps was moderate. Others who were much more deliberate about developing skills in areas of software where much higher multiples were possible and choosing jobs strategically to build their careers made MUCH more money than the former despite not necessarily being more technically skilled. These latter developers are much more likely to be the ones working at FAANGs (or whatever) for $200k+.
Sure, and top companies are not necessarily discriminating amongst dev candidates based solely on technical merit. In fact, there are plenty of recent articles that claim that Google is looking for more and more "soft" skills in addition to high technical merit.
Point being, there are probably lots of factors that combine to make a candidate skilled enough to get hired at Facemazon. It's just that having that combination of skills is rare, so the salary gap persists.
Interesting to choose Epic as an example. In my exit interview there (leaving for SV), the whole interview was about how they could be more competitive when hiring against Google etc (obvious answers were vacation policies and equity, where Epic was woefully behind). So Epic is (or was, ~3 years ago) definitely competing for the same developers as those big companies.
I just chose Epic because the author did. I honestly don't know anything about it.
However, I do have to point out that it seems that Epic is trying to become more competitive with regard to that same subset of engineers that Google hires. Presumably, if they're trying to become more competitive, then they're not yet competitive. Either Epic will have to pay some engineers the same as what Google pays (including equity etc.) or they won't remain competitive for that small pool of devs.
Also, worth noting that I'm saying that as someone that was once rejected by Google on a first-round phone screen.
I'm partial to the O-ring explanation. Software engineering is uniquely multiplicative because it's possible for a software engineer to create software that does software engineering.
Chemical/electrical/mechanical engineers can't use their field to automate their field. Doctors and lawyers are almost exclusively service jobs, unlike the manufacturing nature of engineering.
Automation is a force multiplier, and software engineering benefits from being able to create automation, apply automation to others, as well as being able to apply automation to itself.
Chemical/electrical/mechanical engineers can't use their field to automate their field.
A mechanical engineer designing a new manufacturing technique or robot is most certainly using their field to automate their field. Most of computing exists because electronic engineers used their field to automate their field. Software is not unique in this respect.
Every field is working to automate their field with the help of software. For which you need software developers. The article raises the question of why people are hired as software developers even if they don't have such a degree. Its because companies see it as an automation problem and not as a software engineering problem. That is also why quality or experience of the developer is irrelevant most of the time, there is no one else to judge it, so if its working then its working.
> Software engineering is uniquely multiplicative because it's possible for a software engineer to create software that does software engineering.
I think you misunderstood the O-ring explanation by citing that idea as an example. It doesn't mean building AI. It applies to any of those fields you mentioned. Good people in field X work together with other good people in field X in top firms -> multiplicative productivity.
This feels like it could quickly descend in to self congratulation. So to cast this in a different light perhaps another way to think about this is that programming is just becoming a basic skill, like reading, writing, basic mathematics required for all disciplines.
Most dedicated software engineers exist because this new basic skill hasn’t yet gained widespread adoption as a basic skill in other disciplines. But with time it will, and the number of dedicated software engineers required will decline.
It takes a child several years in full-time education to learn how to fluently read and write. Basic mathematics takes even longer. Similarly, a typical person will become a skilled and highly productive software engineer only through spending several years working full-time at the profession, ideally with the assistance of one or more mentors. Having only a basic grasp of the concepts behind programming does not enable anyone to achieve anything particularly useful, and someone working in a different profession will not have the time or energy to acquire the skills needed to roll their own applications, unless they're an unusually dedicated hobbyist.
For programming you need at least someone who has no problems with algebra, that's a bit above the basic maths.
I say that not because you will need algebra for programming but because you must be capable of manipulating abstractions.
Yeah, but the questions is if creating tools (software that does software engineering) is so complex that only a few developers can do it well? Otherwise this tool creation would still be subject to market prices just as regular development.
You are looking at differences between developers, but try pretending for a while that they are all the same, moderately qualified to adapt to any environment. I'm pretty sure that you would still see roughly the same distribution, since all environments are not created equal, and neither are the different positions inside those environments.
The stagnant bog of billing hours to captive (e.g. internal) customers for example does not lend itself very well to a toolmaking microsingularity. Bimodality of pay is at least as much about the task as it about the one one executing.
There is of course still a lot of correlation between ability and high value positions, but that's a natural consequence of matchmaking: both high value positions and high value developers get disproportional choice relative to their lesser peers.
I am too, and it seems testable, at least for large companies. Are the salaries bimodal within companies or not? If not, then the hypothesis would seem to hold water.
A good answer to why software pays more than industries like law or medicine is that profit per employee in software is enormous. Of the 12 American companies on this chart of the highest profit per employee, 6 are software companies: http://www.businessinsider.com/apple-facebook-alphabet-most-...
I would love to hear an economist explain why this might or might not lead to higher salaries. My hypothesis is there is an element of human nature: if you're rolling in cash you don't have to be stingy.
High profit per employee leads to a higher divergence in salaries - same as it does for industries like financial trading and research.
If profit per "average" developer is $1 million, then the company is way better off paying $100k extra (i.e. double) to get developers that are 20% more productive than the average - and if the company doesn't do that, then their best people get poached by companies who do.
And while it is impossible to hire the mythical "10x developer", it is not all that hard to find the "1.2x developers" if you are willing to pay double to get them...
Not an economist but B.A. Econ here. (Comp sci degree/career came later.)
The difference is the product. In the products these companies sell, especially for us, with web based software, the marginal cost of selling to one more customer is very low. An EE could design an excellent device, but the marginal cost of selling that device is still high. As are the services offered by Lawyers etc. It is the efficient scaling of products that make them so valuable. Those companies that have scaled (or have the potential to scale) their product typically have a lot of money to throw at building it. Those individuals which have the capacity to build scale-able products are in high demand and hence have high pay. My two cents anyway.
I'm not sure that list is a fair way to determine an industry's profit per employee.
Law firms aren't allowed to form C corps, which limits their size and would keep them off that list. I would expect top law firms to be in those ranges in for profit per employee, but they're much smaller so it isn't a fair comparison.
at my university's law school, which is a T14, the average starting salary is 125-150k.
Which is a lot, but not as much when considering that most law grads have mountains of debt plus the opportunity cost of not being the workforce for 3 years. Plus they average 55+ hours per week. And usually cannot work from home.
You're better off doing CS undergrad and working for a Big 10. The hours are on average and can be flexible if you're an efficient worker.
Readit News
To use a non-software example, there are barriers to entry to chip manufacturers and power companies even under anarchy. Fabs are tremendously hard to build. Power plants are extremely hard to build. Building up knowledge and skills about computers is also very hard, especially when our genes don't seem to guide us toward thinking highly logically.
And programming is hard because it requires us to understand a bunch of modular systems and then the systems they're built on, all the way down, and in some cases, all the way up. Then, we have to understand the whole integrated system of the individual modules. Not all programming problems require this level of difficulty, but these problems do exist. I've been on teams where I'm the only one who understands what the OS is doing or the CPU is doing or what the network is doing or why some other distributed component might have stopped working. Most of my teammates in these cases seemed to enjoy programming, but didn't care to become overall experts in computers as a whole.
I once had a top-tier business school grad friend claim that programming really isn't that hard and that we're all whiners. He is a genuinely smart person. Today, he himself is trying to code in JavaScript on the client side. He's a friend so I help him, but the problems he has are junior-level or even entry-level. Suffice it to say, I haven't heard much more about how programmers are "whiners" when we say programming is hard.
Programmers have to remember a vast amount of domain knowledge. Consider the basic task of choosing where you are going to store some data, well first you need to know which options exist and there's dozens of them (do you want Postgres, SQLite, Redis, LevelDB, ..?). Then you need to know the strengths and weaknesses of each. And I hope you have been keeping your knowledge up-to-date because the answer in 2018 is very different to the answer in 2008.
The lack of barriers to entry actually makes it harder. There are "law schools" and "med schools" to teach you all the knowledge required to become a lawyer or a doctor. There is no "programming school", every programmer is self-taught. A computer science degree hardly scratches the surface.
While there are specialisms, such as game development or embedded development, most programmers are expected to be generalists. You may find yourself needing to write networking code, and there's a whole bunch of knowledge that goes along with that. Or, many programmers end up having a working knowledge of cryptography.
Sure, almost anybody can learn JavaScript or Python, and write code, but learning a programming language is only 1% of the job.
Programmer now, gained a law degree in a previous life. Know lots of folks who studied medicine.
The idea that med school or law school teach you "all the knowledge required to become a lawyer or a doctor" is laughable and a truly absurd statement. The sheer size of the problem domains these subjects cover alone renders this impossible, and furthermore I'd argue it's pretty insulting to insinuate that Computer Science is somehow more difficult in this regard.
While I can't speak fully for medics, a law degree "hardly scratches the surface" as you put it either.
I'm pretty sure 90% of us would just look for a Stack Exchange question describing a bunch of popular database platforms and choose whichever looked best after thinking about it for a few minutes, and that outside of extreme circumstances (>terabytes of data, distributed over an actually unreliable network, other exotica) almost any option would work well enough.
Which is to say, programming is complicated but it's not very precise. Compare to mechanical engineering, where if you use the wrong steel your bridge will fall down; or to medicine, where if you prescribe the wrong drug someone might just die. So while there's lots that's useful for a programmer to know, if they don't know it they can get by alright almost all the time, and it's really hard for their managers to tell the difference. (Which is also why we can get away with not having a "programming school" beyond a handful of required courses for a CS degree.) So it's hard for this to seem like a very effective barrier to entry.
It's even more elementary than that, I think. I've encountered lots of intelligent people who lack any sort of diagnostics skills - absolutely essential for being a programmer.
Things like.. the landline is broken. Well, then, get another phone, plug it in and see if it works. If it does, then it's the phone we need to look at, if it doesn't, we need to move further up the line.
It frequently boggles my mind how many people struggle with simple elimination, experimentation, and narrowing down to resolve problems, and I'm not sure such people could become developers without this ability.
Yes, do consider.
In many, many cases the appropriate answer is "whatever stack you're familiar with".
In maybe 10% of cases the answer will boil down to technical requirements and you'll need familiarity with "Postgres, SQLite, Redis, LevelDB, ..."
And that's where the bimodal distribution comes from.
> There are "law schools" and "med schools" to teach you all the knowledge required to become a lawyer or a doctor. There is no "programming school", every programmer is self-taught
I don't know a lot about the law.
But if you think that MDs are not "self-taught" in the same way bootcamp graduates or CS graduates are "self-taught", you should talk to an MD some time.
> The lack of barriers to entry actually makes it harder. There are "law schools" and "med schools" to teach you all the knowledge required to become a lawyer or a doctor. There is no "programming school", every programmer is self-taught. A computer science degree hardly scratches the surface.
+1024
I have said quite a few times that the best CS program is one where you learn how to learn without being spoon fed. In fact, I know a couple great programmers who were _not_ CS (one studied econ; the other, physics), and they similarly learned how to learn without being spoon fed.
I chose to avoid computer science degrees because in those days, in the late 90's, it was pretty much 80-90% math classes. I don't regret getting a degree in a totally different discipline: it turns out learning philosophy, history, linguistics, writing, etc. etc. was far useful to me as a person (and, arguably, a worker) than some boring math classes ever would have been.
Have comp sci curriculums improved in that time? Given that job interviews these days last 4-8 hours, require group approval and whiteboarding in front of an audience, I would argue, NO. Obviously, no one trusts the degree.
You could add another layer to what you are saying as do you want to build apps? platforms? or enterprise line of business software? if so you need to know entirely different stacks. Then you need to know what is important to being "good" at the chosen stack.
This is just a long winded way of agreeing with you, there are vast amounts of knowledge required to "make it". Most importantly you cant ever feel like you know enough and stop trying to learn. I took about 12 months off from stretching myself and now I feel 3 years behind...
Continuing with the example from the article: law and medicine are also hard. Try teaching those to the same set of people.
> Programmers have to remember a vast amount of domain knowledge.
Programmers are not at all unique in their need to understand significant domain knowledge. Essentially every knowledge-based field, including those with licensing barriers to entry, also have this requirement (and arguably to a greater extent).
> And I hope you have been keeping your knowledge up-to-date because the answer in 2018 is very different to the answer in 2008.
Lawyers and doctors must also keep current with their field and the industry in general. If anything, the degree to which they must keep up with their respective fields seems to be a difference of degree when compared to software developers, not of category.
I don’t think any of this difficulty is the reason why programming enjoys high salaries, because (circling back to the article’s thesis), it isn’t distinct from other fields with higher barriers to entry in that respect.
And yet there are a lot of examples of companies that got it wrong, picked objectively-shitty options, and still succeeded massively and then had the money to pour into cleaning up the resulting messes.
There's countless options, but they don't seem to matter as much as people believe. As much as it would be nice to think Lisp is a superweapon and it's easy to replicate Paul Graham's stories, that's not what's happening in the market.
There's an interesting split the OP discusses that seems to largely be a B2C vs B2B thing. With a few exceptions at the high end, many of the winners in both of these spaces aren't determined by "purely better technology" but by other things. However, in the B2B space, battles can be won much more easily on the strength of salespeople and business strategy, whereas in the consumer space, it requires more skilled implementation of ideas - great UX doesn't require technically great programming, but it requires competent execution of the original idea, in a way that a medical records system sold to a hospital administration board doesn't.
There are plenty of apps out there today which support millions of users but didn't choose the most optimal database, wasn't well architected, and has mountains of sloppy technical debt.
And that is only half the job. You also have to practice, a lot.
I think "Teach Yourself Programming in Ten Years" is about right http://norvig.com/21-days.html
You can learn academic computer science, or know a lot of trivia about programming and computers, but without years of dedicated practice it doesn't translate into actual productivity.
Edit: I should note, on the last sentence, this may be done by a veteran developer who knows better but is trying to introduce the concept in a new light. It could also just be a developer figuring out a common pattern on their own. I've heard the actor model pattern was developed by several different people at the same time who were unaware of each others work. I'm not saying it's a bad thing.
Once you get the principles, there isn't much difference in languages, etc. But if you are a senior developer after 5 years, or 3 years, there isn't much room to go up.
> The second most common comment that I hear is that, of course programmers are well paid, software companies are worth so much, which makes it inevitable. But there’s nothing inevitable about workers actually being well compensated because a company is profitable. If we look at this list of the most profitable companies per employee, we see companies that pay well, like Alphabet (Google) and Facebook, but we also see hardware companies like Qualcomm, Cisco, TSMC (and arguably ARM now that they’ve been acquired by SoftBank) that don’t even pay as well software companies that don’t turn a profit, and that the compensation between the software companies that are listed isn’t very strongly related to their profit per employee.
The relevant barriers to entry perhaps aren't to programming-the-skill, but programming-the-business-activity. In other words, the barriers to entering business of profiting from programming. And that makes software engineers higher priced commodity because there is higher competition from other companies, but also self-starts.
Hardware companies don't have pay their engineers as well because those engineers have a harder time leaving for other businesses. There are fewer capitalized companies, and self-capitalizing a chip HW business is very difficult. (and arguably the many smaller company options in that industry are rapidly consolidating - so employer options are going down rapidly).
So in the end software is paid well perhaps because the software profession deals with business areas which yield high value return on the labor, _and_ the low capital business barriers to those activites supports higher competition for software labor.
The biggest impediment to much larger participation in the top tiers of software engineering is imposter syndrome and the elitism of the industry when faced with a trainable candidate. Every startup aims to hire someone who can "hit the ground running" and who doesn't need an assist from anyone.
Also, the largest tech companies have chosen to use LeetCode-like problems almost solely to assess candidates, which are unlike most tasks done on the job most days. These tend to select for people who trained specifically for the interview and for coding competitions, such as ACM.
That said, I have no patience for the "smartest boy" syndrome or the, as you say, "LeetCode-like problems" given in interviews.
I suspect that these interviews do "work" in the sense that they successfully filter those who know what they're doing (albeit rejecting numerous ones who do as well), but they run the risk of encouraging elitism, rockstars and "smartest boy" cultures. (I also think programmers are uniquely bad a hiring because when we can't reduce a problem to something solvable by an algorithm, we tend to try to find the cheapest heuristic.)
1) programming seems to be one of the only "hard" professions that pays well (compared to math researchers, hard science researchers, or even things like some social work -- that's really hard in entirely different ways). Of course I'm probably missing some hard stuff that pays well
2) programming seems to be the "hardest" of the high paying jobs mentioned. Once you get them, banking, consulting and law jobs actually have a lot of mindless or not super challenging work
Law is incredibly challenging work - I know more than one lawyer who complains that they should have went into programming to work 9-5 at Google between free massages and endless burritos or whatever other perks you guys have. It's certainly not work you can casually do while watching youtube - especially considered there's such a thing as legal malpractice a.k.a. get something less than perfect and you could personally be on the hook for your license. Also, it seems like career longevity in software engineering is a lot higher than in law - most lawyers for the top firms (the Google/Facebook equivalents in pay) wash out by the 4th year and practically all do by the 8th.
I always wondered if I made a mistake picking law over software engineering. I don't have any strong passions and I was good at reading/writing so I went into law, but have been kicking myself for missing out on stock options and equivalent pay for a laid back lifestyle. Glad to see there are programmers who think lawyers have it easy.
[1] https://www.bls.gov/oes/current/oes_nat.htm#17-0000
banking - extremely long hours with unpredictable work, huge attrition rate (most people who start in banking don't stay in banking), eventual career progression is into sales
consulting - long hours, weekly travel, huge attrition rate (most people who start in consulting don't stay in consulting), eventual career progression is into sales
law - long hours, high attrition rate (most people who start in big law don't stay in big law), eventual career progression is into sales
At least for me software engineering is much easier than any of those.
Are you saying this as a programmer, or are you saying this as a banker/consultant/lawyer?
Hitting major league pitching.
Perhaps for some people. Most of what I spend my time on is little more than simple data munging, some trivial analysis and glorified crud apps.
That's not to say that the job isn't hard... but lots of jobs are hard. Dealing with the constant loss of people around you if you work in a retirement home or hospice is also hard; but those jobs aren't rewarded equally.
That is a completely different sense of the word "hard" from "programming is hard". Working in the retirement home requires enduring emotional pain and sacrifice. Programming (at least some kinds of programming) requires a high degree of skill, knowledge, and intelligence.
The distinction being there may be a larger number of people with the skills to work in a retirement home, than there are people with the skills to write particularly difficult programs.
Salaries for the vast majority of occupations are driven by the supply and demand for employees - its a job market after all. Demand for programmers is increasing. Supply is increasing too, but is generally limited by, among other things, how technically "hard" the job is. "Deserve" isn't even part of the equation.
With that skill, you don't even always need to know how to write software programs. Sometimes, you're better off delegating specific tasks to humans.
When someone hands you a problem like "make this dead elephant disappear" other people will still be scratching their heads after the programmer has already figured out
And they think to themselves, "I can vanish an elephant in two lines." Everyone else is still thinking about the problem in terms of tons. The chewing and swallowing is a trivial implementation detail.(Meanwhile, some other programmer will be at the north pole wondering what happened to the elephant they left in Cairo.)
Some people simply aren't able to deal with problems they have not encountered before, that are too far beyond their domain of comfort. They can learn, but they don't innovate. As long as such people exist, they will have to pay other people to teach them how to cope with changes in their environment. Software engineers get paid well because a lot of them can effectively solve problems without needing to be domain experts in anything.
I often get in trouble for saying things are easy or hard. For instance, building a website can be easy but costly. So what language would help here?
Sometimes you inherit a bad system, so how do you fix it while keeping your releases in stride. That's not easy, especially when then original designers aren't there anymore. Speaking of which, what's the best release stride for this company? You might have to adjust design for that too. Was this weird code done on purpose, is it a bug, or were they trying to hack around a mistake somewhere else? Time to roll the dice, because you need to change it. How do you minimize the collateral damage if you are wrong?
You also need to consider your limitations like network and persistence storage. That's a huge part that many haven't even considered yet. How are networks designed today? How is data persistence designed today? What are my options and what are my limitations with this company? What type of reports does this company need? That's a big one. How about failover, what does your system do when the network or database quits? Do you lose any data? Are you sure? How important is it to not lose data? It's not that bad if Facebook loses a post, but it sure is bad if a bank loses half of a transaction.
Programming has a lot of levels that we don't even realize until we hit a new one. Turning good specs into working code is level 1. It takes a hell of a lot of brainpower and abstract thinking to just do that.
Barriers don’t refer to how hard a discipline is skill-wise, they refer to how hard it is to enter the discipline. Law and medicine are also hard disciplines, but they have actual barriers to entry that cannot be surmounted by self-study. In this sense (which is the sense that the article means), programming does not have those barriers, no.
Considering that, unless you’re going to mount an argument that programming is objectively harder than those other fields skill-wise, it doesn’t seem productive to talk about an orthogonal “barrier” to entry that the other two also share. They are all difficult, so we end up in the same position.
Your comment here has spawned a large thread of people talking about how hard programming is (which frankly seems a bit self-congratulatory for this community, to be honest), but that’s completely separate from the core point being forwarded in the article; vis-a-vis, that programming is interesting and unique precisely because it has such a high compensation for a field without a central body limiting the supply (among other things). Law and medicine are also hard fields, and lawyers and doctors would be happy to explain why they’re difficult and have their own “skill-based” barriers aside from the licensing ones.
I don't think we disagree much here.
I agree that medicine in particular is hard on its own. I'm not entirely sure about law, because the legal profession has only become highly-credentialed (in the US at least, which is the subject of this article) relatively recently. Regardless, to not make the trap of my b-school friend, I don't know enough to dispute whether law is super hard. I suspect it's not easy.
(Just as an aside, I'll note that from what I do know about medicine and law, both professions also require an extremely logical approach. I suspect certain specialties in medicine like surgery or anesthesiology or oncology are much harder than programming for various reasons. From cursory web searches, these specialties appear to earn much more than programmers do, and even much more than other physicians.)
Thus, assuming that medicine and law are also very hard (on the same order of difficulty as programming), we can likely say that even without licensing and credentialing requirements, entering the medical or legal professions would be hard.
I suspect we have slightly different ideas when using the term "barriers to entry". Indeed, I might have made a better argument if I had said programming has "high" barriers to entry, since what I'm talking about is clearly a continuum and not a boolean. C'est la vie. When I use "barriers to entry" as a concept, I'm using it broadly. To me, it encapsulates not only legal or political costs, but any cost, which is why I mentioned building a power plant or a semiconductor fab. I am using it the same way I see it used in the various economics literature. In this case, I suspect the cost is that most people seem to feel uncomfortable thinking abstractly and logically, and haven't refined those skills over time. Alternatively, high capital costs are a common contributor to barriers to entry in economic analysis. "Human capital" (another econ term) is exactly how I'd categorize the learning required to practice programming, whether it is acquired through formal training or self-direction.
As far as the self-congratulation, I agree, although that was not my intention. As long as I stay a few standard deviations from Erik Meijer[1] (whom I otherwise deeply respect), I'll consider it a success. ;)
[1] https://vimeo.com/110554082
Artificial barriers-to-entry though, such as the licensing requirements for doctors/lawyers, are unique to some specific professions. Hence why they are worth highlighting.
Maybe intelligence isn't the right word (after all how smart is it really to sit in front of a computer all day shuffling bits around?), a certain way of thinking or aptitude might be better. Education doesn't overcome this, training only partially overcomes this, experience doesn't necessarily overcome this. I bet most of us in the field have come across individuals with high levels of training, perhaps even very "intelligent" individuals who simply fail to fit concepts together in a useful way. Who get the pieces, who can answer quiz questions, who know facts and trivia, but simply cannot bring it all together into a useful, coherent, maintainable whole in a reasonable time frame. And I don't see this barrier being broken.
Anything that can be taught by rote memorization can be automated. Anything that requires higher levels of abstract thinking may never be automated.
Many, perhaps most, people have trouble with the basics of programming. Pointers, functions, even basic iteration are concepts that cause a lot of people to flunk out of introductory programming.
Real and non-artificial? Could it be?! :P
It truly is amazing how people outside of a field always seem to have the best idea of how long something in that field takes to do.
https://xkcd.com/1831/
To become a chemical engineer, you first have to complete the course work for a degree in chemistry. Chemistry as chemistry is an extremely modular subject matter; you can solve most problems in discrete steps in isolation. In a computer science sense, chemistry is about pure functions. Very easy to analyze, as material side effects (like spontaneous detonation) are rare.
Chemical engineering, on the other hand, is about analyzing systems that leak their state everywhere and have effects that feedback into other parts of the system. But it needs to be extremely efficient nonetheless. There is no isolation because it doesn't exist in real-world complex systems. I have seen excellent chemists absolutely fail to grok chemical engineering even though it is literally the same subject matter. The only difference is that chemical engineers are required to reason about complex distributed systems; as with computer science, only a minority of practitioners ever seem to grok it despite their best efforts. Same problem, different domain. And chemical engineers are paid on a different scale than chemists as a result.
In engineering, bimodal distributions are the sorting of people that naturally have the ability to easily reason about complex distributed systems with many concurrent moving parts and people that cannot. Increasingly, the market is discriminating on this characteristic and it is reflected in wages.
Anecdotally, it is somewhat well-known that people competent at chemical engineering find advanced software engineering to be intuitive; it is a very easy second "language" to pick up. An inordinate number of chemical engineers end up in high paying software engineering careers -- it comes very naturally and lends itself to the abstract analytical toolset you develop as a chemical engineer.
That is incorrect.
Look at the programme of study for a chemical engineering undergraduate degree [1]. It doesn't cover anywhere near the same content as an undergraduate chemistry degree [2].
[1]: http://www.imperial.ac.uk/study/ug/courses/chemical-engineer...
[2]: https://www.imperial.ac.uk/study/ug/courses/chemistry-depart...
This turned it into a de facto 5-year degree even though they stripped most of the non-related coursework to a bare minimum; you still had two years of coursework for the engineering program after the chemistry. People that lost their appetite for chemical engineering after compressing all their chemistry into three years could switch to chemistry, which meant they spent their last year taking the filler non-technical courses that the engineers were allowed to avoid.
My classmates from Chem.E had more classes in common with us mechanical engineers than any other branch.
Thermo, fluid dynamics, CFD and heat transfer is where it is at.
What faith in the system :). The truth I think is "it's who you know" more than "what you know". The best paid engineers are ones who spend a lot of time positioning themselves to get well paid. Why that is bi-modal I can't be sure - but my guess is that once you hit a certain network effect you start to make a lot more.
Granted, money is 'absolute' if you use it to e.g travel around the world, but most people don't do that. In general money is 'relative' to one's environment.
Do you think developers who are very good want to work with the best, thinking the best are in SV, then move to SV? Or perhaps they think they'll get the best return on their effort if they're working on software with big impact, and software with the biggest consumer impact is mostly written in SV?
"How is it possible that programmers are paid so well without these other barriers to entry that similarly remunerative fields have? "
My initial thought was that there are people who get it those that don't. But you can teach many people the tools of programming. It's using those tools to do something interesting that seems to be the challenge. By interesting I suppose I mean something exceeding some level of complexity.
This makes sense, I don't see our schools teaching anything too complex - it tends to be compartmentalized.
If company X is your competitor, and they employ 10 software developers, sooner or later, whatever it is they're working on will release, and that might provide X with a massive competitive advantage over you. So you have to hire your own people to keep up with your side of the arms race. And sometimes, a brand new person comes along with a bunch of software folks to create company Y, and they devastate both you and X within their first 5 years.
As someone trained as a chemical engineer who now is a Data Engineer (SQL & Python pipe fitter), feel free to add me to your anec-data :-)
It's also a matter of scale: the GAFAMs just ship more units in terms of revenue per employee. Sure, that's largely because of monopoly and network effects, but hey.
Allow me to take an alternative argument: Highly-driven students, especially those driven by money, became ChemEs to earn a lot of money and prestige. They looked up highest paying majors and chose ChemE for these reasons. I think it is now obvious SWE is very high paying and prestigious -- perhaps more so than ChemE -- so these highly-driven people switched. It had nothing to do with the topics intrinsically, but rather ChemE was largely perceived as the hardest/most-prestigious field and now SWE is.
To offer my own anecdote: In pure/theoretical Chemistry you conveniently ignore in-situ solvation effects to think about mechanisms of the organic reaction.
Then in the real world, you can't replicate someone else's paper because of humidity differences between your lab and the author's.
My father has been responsible for every chemical (including, explicitly, explosives) factory in the entire country (Hungary, 80s) and later for just one pharmaceutical company for those "side effects" to stay rare. They do not stay rare without some very stern rules.
Is it not possible to engineer in isolation on real world complex chemical engineering system?
I try to do that with software, and most software can certainly benefit from stricter isolation (e.g. looser coupling), but most software teams - even well paid ones - often have an in-built bias against investing in less tangible work which means that you ultimately end up with these complex systems are that hard to reason about.
Not that I feel like I should be complaining about this if it is indeed the reason I'm paid well.
Deleted Comment
Deleted Comment
I'm too tired at the moment to look this up, but the NY Times had a piece sometime in the last couple of years where they were discussing income distributions, and had an interactive, and what they looked like, almost across the board, was a bigger lower mode, and then a second, smaller, more spiked mode much higher.
What struck me about that piece was that it was framed in terms of skewed incomes, but the bimodality of it didn't get discussed much at all, nor the fact it was so widespread across different disciplines.
To me it was very disturbing, because it suggested that there was a growth, across disciplines, of two "classes", one established, with a relatively large income, and another, larger class, with a much smaller income.
I was very curious about this, and have wondered what the groups are--if it's because of older, senior individuals and younger, junior individuals. Maybe the latter are trainees? Maybe the latter came into the labor market at a less favorable time? Maybe there's just a kind of winner-takes-all sort of phenomenon?
It was really disturbing to me, and seems difficult to explain in terms of any specific features of any field, because it was so, so widespread across labor areas. It was partially disturbing that it was sitting right here in these graphs at a major news outlet about income distributions, and was not being acknowledged even then. It was probably more disturbing to me than the general long-tailed skewed income distribution that gets discussed, because it suggested (at least to me) very unnatural about how incomes were being allocated, even more so than the stereotypical long-tailed but unimodal curve.
Deleted Comment
Dead Comment
I feel like this is the real issue here. The reason that the US has great companies is simply from the availability of large amounts of capital. And if the millions and millions of Indian, Chinese, and Eastern European programmers who are inifinitely more talented/driven/intelligent/educated than myself were able to simply move here and seek employment with no immigration restraints, I know that I would be out of a job instantly. In that sense it feels perversly exploitative and priveleged to make so much more money than practically anyone else on earth due to nothing but the physical location I was born.
Is it perverse to go swimming because you were born near a beach? Is it perverse to visit the Louvre if you are Parisian? Is it perverse to go to a good university because the universities in Elbonia aren't good?
You're not entirely wrong, but that's a very limited view on how the world works. It's not all random. We're not all rolling dice and separating into "haves" and "haven'ts".
Once upon a time: Somebody's parents moved to the coast. Somebody's predecessors funded and built the Louvre (and managed to keep priceless things safe despite war, disease, famine, etc.). Various parties spent decades (or centuries!) of history recruiting and utilizing world-class talent, raising world-class capital reserves, and building world-class facilities for their universities.
If you actively promote or passively allow politicians and legislation that bars other people from having a shot at earning those things themselves, then yes.
To a degree, we should feel bad for having access to capital when there are far greater needs for this capital elsewhere. Most of us don't have any real power to change the situation unfortunately. But it is definitely something to be conscious of and you should reflect on what you can do to help turn the tide for those less fortunate.
You're a programmer. Maybe you're decent, maybe you're not. It is VERY unlikely that the "millions and millions" of "infinitely more talented" Eastern European/Indian/Chinese programmers you mention actually exist. And even if they did, there are many societal and economic reasons besides "US Immigration Laws" that would prevent them from coming here and taking your job for an order of magnitude less money.
I'm not afraid of a superior person taking my job. They would be no better at it than I am. I would probably be more productive if I were less intelligent (or on booze, but employers frown on that).
There are thousands of developers making fractions of what their equally talented counterparts make in the US.
I honestly don't think it will last, though. Economically, it just doesn't make sense. My recommendation to any of my fellow US developers: save as much as you can while the money is good.
It's almost impossible to immigrate to England (much harder than the US), yet programmers in SF are far better compensated than those in London.
Immigration per se may be hard, but working is much easier than the US; I know several Romanians working as programmers in London.
Most people feel at least sheepish about their own success when faced with others, no less deserving, who experience failure.
Deleted Comment
I find this quote confusing. Historically, the poaching of highly-skilled foreigners has been an important step in developing mere import substitutions into products which can be competitive on a global scale.
The Tudor government (Henry VII-Elizabeth I) kicked off its finished-wool-import-substitution program by poaching skilled weavers and machinists from the low countries (e.g. Flanders, Holland, France). Then, as the export of finished wool goods grew, so did restrictions on the exportation of raw materials and the importation of finished wool. Nearly 100 years later, England had the ability to drive European countries to famine by simply banning the export of raw wool.[0]
In the early 18th century, France started poaching British watchmakers, weavers and metalworkers; Britain responded by outlawing the emigration of skilled workers in 1719.[1]
With that context, I find it odd to hear that U.S. immigration policy has started to work in opposition to the what I believe is the largest benefit of immigration. What incentive is there to keep highly skilled workers, along with their advanced knowledge, out of the U.S.?
[0] - Chang, Ha-Joon. Bad Samaritans: The Myth of Free Trade and the Secret History of Capitalism. New York, NY: Bloomsbury Press, 2008. Print. pg. 40-42
[1] - Chang, Ha-Joon. Bad Samaritans: The Myth of Free Trade and the Secret History of Capitalism. New York, NY: Bloomsbury Press, 2008. Print. pg. 129
Couldn't you say the same thing about other professions?
The whole world uses operating systems, browsers and development tools made in western countries.
Now, the quality of engineering education received at top CS/engg. institutes and a local college is night and day. This means that only a small subset of the graduating engineers get any decent quality of education.
Most of these people, often considered the cream of the crop are poached by the aforementioned western companies or go for graduate studies. Graduate institutes in India are underwhelming, so these students land up in the west as well.
The rest of the cream have to choose between software engineering roles that pay around $15-25k with very little vertical movement and business analyst/ consultancy roles where you might earn a bit more and have a much clearer clearer progression up the ladder. These are often referred to as the MBA crowd.
Look at people like Sanjay Ghemawat, whose achievements are as noteworthy as Jeff Dean, having been a fundamental part of developing MapReduce, BigTable, Tensorflow, GFS and Spanner.
It is actually a very ironic situation. One one hand the US is complaining about negative intellectual biases against Asian immigrants, while both the Indian and Chinese govt. are lamenting how they are losing the cream of the crop to the US as well.
If both are the be believed, India and China's best are leaving the countries, but the US is not getting competent people from these countries. So, I guess these people have vanished into thin air. In the mean time Chinese and Indians increasingly churn out ground breaking papers and research in CS.
This is very much changing, especially in China, but I presume there is still some lag. The other thing worth bearing in mind is that Chinese products are very insular. They are slow to get localized if ever so unless you have a reason to be going out to download them, you are unlikely to ever be using them.
Maybe you were born in the right place for the economical opportunity for someone born “lower” (please be generous with my terms here), but maybe it’s that these others were born “higher” to a place where higher education is easier to accumulate granting them a severe advantage competitively should you have to compete in an economic arena on the same level.
Or do we accept that being born to an economic disadvantage due to whatever factors mean you should be solely relegated to your caste of manual labour, service occupations, or direct servitude?
Second to that problem is what value does higher education really have in application in what are varied circumstances.
My understanding was the founding of the US was quite counter to that idea— and it’s one ideal that many countries have thankfully sought to incorporate.
Though I think you’re on to a problem—one that includes the consideration that current rules don’t exactly line up with the values we might wish to pursue as a (human, global) society. Partly because it might be necessary in what appears to be a period of transition.
Don't discount your other abilities that much.
However, capitalism (in the form of Walmart and its suppliers, for example) does seem quite efficient at supplying material things to poor people. More spending power in the right places would go pretty far to fix the problem, along with boosting the economy.
The enemy are not foreigners man, the enemy are the rich!
If software can automate, reduce inefficiencies and generally be the means to accomplish the business goal, then it makes sense for the business side to invest heavily into what is essentially a competitive differentiator.
The bimodal compensation reflects a growing split between software activities that are seen as an necessary operational burden, and those which are the "secret sauce" of the business. That's why fintech has traditionally been the highest paying field, as the return on investment is the most obvious for them.
Edit: typo (thanks tzahola!)
Of course, salaries are largely determined by the industry one is in. If you can position yourself at a place in the economy that attracts large amounts of money (per person) then you will be able to siphon off a relatively large amount for yourself.
As software embeds itself in everything we do, developer earning potential will reflect the industry one is in.
High tech firms like Apple and Google make huge amounts of money per employee, so people that work for them make huge amounts of money too. Not just software developers, but also people in sales and strategy, etc. Same for people in finance.
Google, Facebook, Amazon, and whatever other big name you want to throw in the pot, are competing for developers. However, they are not competing for the same developers as Epic Systems, for example. FAANG (or whatever) are competing for a highly skilled subset of devs that can meet their demanding hiring criteria. Similarly, top law firms are only competing for a subset of all law grads -- those that meet their demanding hiring criteria.
The difference here is that, in law, that criteria is focused around a prestigious degree. Presumably, this is because it is hard to thoroughly test a lawyer's competency as a lawyer in an interview setting. However, in programming, many top companies, apparently, find that a series of intense whiteboard interviews are sufficient to determine whether or not a dev meets their high standard.
However, we also have a shortage of devs across the board, for all companies. If CS enrollment increased by 100%, then presumably the "lower" distribution of salaries would stabilize at a lower number -- probably close to what traditional engineers make nowadays. However, the salaries of the GooBooks of the world will only be affected if a sufficiently high proportion of those grads can meet a very difficult hiring criteria.
Similarly, law schools have seen a dramatic increase in enrollment over the past few decades. Lower salaries have stabilized, since the market is now saturated. However, the salaries for top law firms remain high, because a similarly low number of candidates meet their difficult hiring criteria: Harvard, Yale, and etc. are producing more or less the same number of law grads as before, with respect to demand.
This is why Google can open an office across the street from Epic and yet still pay devs twice as much. This is also why I don't think immigration is a huge factor. Sure, if companies were able to immigrate significantly more workers, then salaries at top companies might drop to a degree. But the real drop would be seen in the salaries of devs at typical companies.
EDIT: grammar
But they all have to pay the same because it's a signal to their clients that they are the best. If they paid less than their clients would consider their firm second tier not top tier.
And Google is hiring the same devs as everyone else. Having worked in a large company and seeing several people move to Google. They got some smart devs who stood out on their team, but they also got mediocre devs. The average dev they poached was definitely better than the average dev who worked there but it was a moderate difference in degree not kind.
You could also argue that maybe Facebook doesn't need devs to be able to independently produce Tarjan's algorithm while standing on their heads, blindfolded. But for some reason, these companies believe that it is essential. Maybe that's well-founded -- maybe not. But it remains the case.
Point being, there are probably lots of factors that combine to make a candidate skilled enough to get hired at Facemazon. It's just that having that combination of skills is rare, so the salary gap persists.
However, I do have to point out that it seems that Epic is trying to become more competitive with regard to that same subset of engineers that Google hires. Presumably, if they're trying to become more competitive, then they're not yet competitive. Either Epic will have to pay some engineers the same as what Google pays (including equity etc.) or they won't remain competitive for that small pool of devs.
Also, worth noting that I'm saying that as someone that was once rejected by Google on a first-round phone screen.
Is this not the lump of labor fallacy?
Chemical/electrical/mechanical engineers can't use their field to automate their field. Doctors and lawyers are almost exclusively service jobs, unlike the manufacturing nature of engineering.
Automation is a force multiplier, and software engineering benefits from being able to create automation, apply automation to others, as well as being able to apply automation to itself.
A mechanical engineer designing a new manufacturing technique or robot is most certainly using their field to automate their field. Most of computing exists because electronic engineers used their field to automate their field. Software is not unique in this respect.
Mechanical engineering didn't have its Lisp. We do.
I think you misunderstood the O-ring explanation by citing that idea as an example. It doesn't mean building AI. It applies to any of those fields you mentioned. Good people in field X work together with other good people in field X in top firms -> multiplicative productivity.
Most dedicated software engineers exist because this new basic skill hasn’t yet gained widespread adoption as a basic skill in other disciplines. But with time it will, and the number of dedicated software engineers required will decline.
The stagnant bog of billing hours to captive (e.g. internal) customers for example does not lend itself very well to a toolmaking microsingularity. Bimodality of pay is at least as much about the task as it about the one one executing.
There is of course still a lot of correlation between ability and high value positions, but that's a natural consequence of matchmaking: both high value positions and high value developers get disproportional choice relative to their lesser peers.
I would love to hear an economist explain why this might or might not lead to higher salaries. My hypothesis is there is an element of human nature: if you're rolling in cash you don't have to be stingy.
If profit per "average" developer is $1 million, then the company is way better off paying $100k extra (i.e. double) to get developers that are 20% more productive than the average - and if the company doesn't do that, then their best people get poached by companies who do.
And while it is impossible to hire the mythical "10x developer", it is not all that hard to find the "1.2x developers" if you are willing to pay double to get them...
Law firms aren't allowed to form C corps, which limits their size and would keep them off that list. I would expect top law firms to be in those ranges in for profit per employee, but they're much smaller so it isn't a fair comparison.
2 of the top 6 in that list are in medicine.
Which is a lot, but not as much when considering that most law grads have mountains of debt plus the opportunity cost of not being the workforce for 3 years. Plus they average 55+ hours per week. And usually cannot work from home.
You're better off doing CS undergrad and working for a Big 10. The hours are on average and can be flexible if you're an efficient worker.