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.

Medical school will teach you the basic science and theory and give you basic clinical experience, one still needs to complete a 3 to 7 year residency in the field one wants to practice in. Then there are fellowships that one may want to do if they want to specialize even further.

It's definitely not the case that you learn everything you need to know in school.

> 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

You seem to be an example of a programmer that can be good and proficient in many different fields, languages, and scopes. You don't really see that in law or medicine. Doctors can't jump around from orthopedic surgeon to psychiatrist to dermatologist. And it's very uncommon (at least for lawyers under 60 or so) to be both a corporate lawyer and a litigator.

As giobox mentioned, the sheer size of the domains of law and medicine all but require doctors and lawyers to specialize. That's certainly true to some extent with computer science but it doesn't seem to be quite as strong in that field.

The magnitude of knowledge needed to push a company to become public or undergo a merger, to litigate a divorce with children in custody, to defend an individual in a murder trial, or to litigate an aboriginal rights claim is substantial and there is very little overlap between them.

The issue isn't the regulatory requirement for competence - it's that the fields of specialization require years to become decent in.

But I will say one of the MAJOR things that I LOVE about programming is its relative lack of artificial and social barriers. In psyche, med, law, science: even if i am good enough to pick something up in 6-12 months, or even if I have already been studying or been experienced in said field (say because I have a family member who has been surreptitiously teaching me or bringing me along on the side), there is an inescapable time, money, and social barrier that is effectively immutable.

I can't REALLY do law/medicine without running them in serial, paying the fixed costs of time/money for both (which almost no one has), and I can't fast-track through either or leap-frog students or peers of lesser ability. And god help you if, half-way through, you then think that something in chem/physics might be interesting and applicable. Or if you have the insight/ability to say: i think i'd learn more over there (well too bad, these are the requirements for the program and this is the course structure and this is what you need to do to get your practicing certificate...and except in exceptional circumstances, that's even if you had someone in a position of authority who would agree with you).

Those barriers have not yet been established effectively in programming. Sure, some people tried earlier to establish things like certification and structure, and we're now starting to see the germination of university degrees in arbitrary specializations, and that force will always be there, but few people take them comparatively seriously. The barriers to entry are low (you could almost always even just pirate some software to get started and install it on relatively cheap generic hardware). And if you want to apply it to different fields, you quickly find the barriers aren't generally from the computing/programming side, but from the social/structural barriers inherent in those fields in our society.

Now to be sure, we get the downside of this too: cranks, frauds, used-car-salesmen, agile coaches, wannabes, fads, marketing, etc.

But they don't stop me learning for my own ends, and if i ignore them they have no effect on what I can learn for myself once I pass the relatively low barrier of stable employment and income and basic hardware. And my knowledge makes me more employable and more attractive.

Whereas there is no way I can participate or do the same with engineering, medicine, or law etc without effectively cancelling my life and/or desires in other fields.

And whereas my knowledge and self-direction make me immediately more employable and desirable NOW and at all times in the future in programming, i have huge sunk, upfront, and opportunity costs for several years to participate formally in each of those other fields.

That's why in most countries lawyer candidates are required to do mandatory legal internships. And even after becoming a lawyer, you need to gain a lot of experience before you can be trusted to practice law without the supervision of an experienced lawyer.

Why in the world would that be insulting and who is it insulting to? If anything it's a reflection of how immature the industry is and how computer science degrees have minute overlap with software engineering.

It’s insulting to diminish the legitimate achievements of other people through unjustified comparison, in particular when doing so results in the elevation of the person doing it.

There is no objective criteria by which we can state computer science is a more difficult field than law or medicine. To imply that is therefore offensive, and people are not “immature” just because they react to offensive things by being insulted, even if you believe they shouldn’t feel insulted.

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.

Dereference the wrong pointer and the rocket blows up. Forget a memory barrier and the robot brain gets corrupted memory and sees human life as an impediment to paper clip maximization. Forget to zero out some memory in a goto: cleanup section and suddenly there's a back door in a popular security library leaving machines to the whim of any curious script kiddie.

I know a lot of people aren't working on real time systems or encryption libraries that have the same level of significant consequences as what you're describing, but some are.

When you're starting from scratch, I think the bigger barrier isn't "where do I store this data", it's "what the hell is data"? Try to explain to a computer illiterate person that the latest Mariah Carey CD is just a really big number and you'll get a glimpse of this. The person who knows they can jump on Stack Exchange is already past the worst part of the learning curve.

And other times. I've been working in software for almost two decades. I ran into a particular data problem that I could describe but didn't know the name of (a la wizard of earthsea). So I couldn't search to see how others had tackled this.

Google and blogs and YouTube and stackoverflow have pushed the boundaries of knowledge. You don't need to know exactly how to do something (for many kinds of tasks) but you do need to know what it is called, and how to adapt what you find on the net to your situation.

That said, it's often a great resource.

And you're the reason why I have to mop up poor performance because someone decided to use MongoDB for highly-relational data.

[1] Well, not me in particular! I know the important things and only use SE for looking up trivial details, of course. But maybe not everyone agrees with me which is which...

The reason is that software systems are at another level of complexity.

The Space Shuttle is often given as an example of the most complex machine every built, with more than 2.5 million parts. The Airbus A380 has about 4 million parts.

https://www.quora.com/Whats-the-most-complex-machine-ever-bu...

The Linux Kernel, not necessarily the most complex software ever written, has nearly 10 million lines of executable code, over 12 million with comments, scattered over 36,000+ files.

https://www.quora.com/How-many-lines-of-code-are-in-the-Linu...

Google's back-end cluster and services are frequently given as the most complex software existing.

The full LoC in Debian GNU/Linux has been estimated as 324 million as of 2009. This is the stable archive, which includes somewhere between about 30k to 70k individual software packages (I'd have to do some digging to see what the count was for the stable release as of 2009).

https://unix.stackexchange.com/questions/111281/exploding-am...

I used to do that but I got burned more than a few times.

These days I do a bunch of research - sometimes days, including tracking down obscure blog posts about obscure issues, reading issue trackers and spiking code. Can feel like a waste to begin with but it's saved me from some very dark places.

I would not trust stack exchange or stack overflow for a technology recommendation ever.

I think the biggest barrier in programming is just how abstract and alien it is, cognitive load can be enormous. Try to teach engineer about materials or steel liquation or semiconductors - it might be abstract or complex but at least it is dealing with real life physical processes.

With programming it is whole different galaxy. Like explaining pointer arithmetic to someone who just started learning CS. Or recursion, or asking someone to rotate tree in their head - there is a huge chance it will simply BSOD them. Programming is much more close to theoretical physics or maths than engineering.

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.

There are are also formalized methods of teaching how diagnostics. And training on how to teach it. So yes, you can teach a monkey how to teach another monkey to do X.

Between learning to program and learning to practice law, once you get past your chosen programming language's syntax and a few core CS concepts - learning to program is much easier.

I have the feeling that a lot of people can believe they have learned to program while all what they did is to go past their chosen programming language syntax and grasped a few core CS concepts.

That's quite a low barrier to entry, but if that's what people mean when they hear the word "programming", then I'd argue that Software Engineering would be a better name for the field we're here comparing with practising law.

Programming education is totally ad-hoc and you can be a great programmer even with a degree in agriculture.

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.

https://news.ycombinator.com/item?id=15164948#15168430

https://news.ycombinator.com/item?id=12589473#12592521

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.

Most professional programmers would put in more hours of hands on programming in a months work.

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.

Law and medicine also trend towards bimodal compensation.

There is an enourmous earnings difference between the top echelon of lawyers and all the other lawyers.

Same thing for specialist surgeons.

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.

And they typically have to pay enormous sums of money to hire the talent required to clean up.

This is large part helps create the bimodal compensation model.

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.

While the gameplay in your first game may still be simple, it can look great because the engine does most of the work. It absolutely won't look like something from a C64 (unless you want it to).

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.)

The students were asked to write out instructions to build a paper airplane. One by one, I would follow their directions as loosely as possible and build lopsided airplanes. The lesson did a reasonably good job of explaining how computers handled algorithms and code.

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) scale for the low end. As an engineer, I’ve made a game where I have customers worldwide that pay me something like 25 cents a week. A lawyer can’t really do work that scales out at the low end like that. It’s not a brain power thing, it’s just the nature of the work product.

2) at the high end, a big company like Google or a financial institution can keep hiring programmers at say $100k, and have them produce tiny detailed enhancements that produce say 150k or or more of revenue per year over a multi year period. Most large systems can always sustain a little more enhancement that will produce an optimization of revenue.

I think this is the key difference between programming and other kinds of work. Programming is scalable at both the low end (distributable to very cheap consumers) and the high end (can always get more revenue through optimization). And at both ends of this spectrum the machine keeps earning money even when the programmer is sleeping or working on a new project.

Programmers definitely have leverage due to scale, but lawyers also have a lot of leverage when dealing with cases that have large $$$ amounts tied to them. Traders obviously have leverage by using large quantities of capital in their trades.

A lawyer can make a change in a corporate structure to lower a company's tax rate indefinitely

From the perspective of lawyers adding value to the law firm, a good lawyer can do this with dozens or hundreds of clients a year, and increase the firms revenue by bringing in tons of new clients. Creative lawyers can also figure out a way to differentiate themselves in a particular sector, like tech startups, and one lawyer who becomes a leader in an area can add millions in rev to the firm a year, for many years, by bringing in new business

Some law firms also take equity, and good decisions about when to do this can bring in huge windfalls

I was referring more to the intellectual challenge of the work. In investment banking there is basically no intellectual challenge at a jr level and at senior level it's all relationship management. The trading side can be hard but increasingly that's a programming job

I'm sure there are some super challenging law assignments but from what I understand from friends at top firms there's a lot of template changing and standard cases for a lot of stuff. At startups I try to do as much of that basic work myself so we can save on legal fees. Of course I get lawywers to review / sign off, but it's usually easy for them to do so

But programming is hard at an intellectual level in a way that is different from banking and consulting work and from what I understand, legal work. The first time I did a problem set in C involving memory allocation it took me like 20 hours to get it right. And the engineers working on massive systems that have to run perfectly, fast and be maintainable by hundreds of random people have work that is orders of magnitude harder. In programming, the difficulty of the work seeks to scale as your skill does. Don't know many other professions like that

I interned at google not as a programmer, and you are right that the work life balance there can be amazing, but it probably is the best company in the world for work life balance. Lots of programmers at other companies like work crazy hours as well, and often for non technical bosses or poor managers who make those long hours unpleasant

I'm not convinced. From what I hear, being a developer at Google can actually be stressful, if only for the fact that your peers are likely to be talented and ambitious - so it will take effort to keep on par with them.

Compare that to countless corporations which also hire developers, but where the motivation and talent levels are lower. In many of those jobs, you will be fine with doing maybe 15 hours of real work peer week. I'm not sure it would fly at Google. Based on this, I recently declined an interview invitation from Google recruiter - precisely because I was worried that my work-life balance would plummet.

There's also a very important point to be made here. Large-scale software development and self-directed programming have very, very little overlap in terms of time allocation and mental effort. To exaggerate the difference somewhat, it is like comparing building a go-kart in your garage with designing a factory that produces commercial, road-ready cars.

There's a huge jump in intellectual challenge of hobby programming vs the analysis you do in investment banking, and I'm sure there's another huge jump between hobby programming and large scale swe. Though I don't know which jump is harder. And I'd imagine that designing the factory in your analogy probably is the work of very experienced engineers, and jr eng is probably more like designing and building the machine that attaches all the wheels as part of a massively complex automated system

The life of the average programmer certainly does not involve endless burritos or massages, and the compensation is probably below yours.

Another key difference is that in most top tier law firms, literally 2-3% of every starting class can expect to have a full career there. I've heard tech has a similar concept called stack ranking, but it seems much milder in terms of the forced attrition. Not to mention you don't need a full career at Google - you can always take that resume line and go to another big tech company, a startup or something midmarket. Law is much more segmented. The M&A lawyer laid off during a recession isn't going to find a job at a small firm because those generally do not do M&A.

I don't really hear of top tier software engineers struggling to find work - happens to out of work top tier lawyers all the time.

Oh, and for the record 15% of law school grads get that sweet 180k starting salary (a trajectory most won't stay on).

There are many, many lawyers making 40-60k a year working horrendous hours with no real hope of advancement.

Let me be clear: I have zero doubt in my mind, even with my very limited knowledge of the software engineering market, that I have no doubt the median software engineer is far better off than the median lawyer, likely in terms of pay, hours, and prospects all at the same time.

My question related solely to the top tier because that's where it's even remotely competitive.

You might get sued by a client, but from what I have seen getting disbarred is really hard to do. Like, you have to blatantly defraud a client or something. Just doing shitty work, or even (as some I have known has acutely experienced) actively screwing over your client in a technically-legal-but-totally-sleazy way, the Bar Association will give you a slap on the wrist, if anything.

[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.

I woerked in banking and agree it is a hard work environment , but getting the deliverables done was easy and not intellectually challenging. From my friends in big consulting and law firms the work sounds similar in nature

I'm sort of mixing apples and oranges but it makes sense in my head :)

Are you saying this as a programmer, or are you saying this as a banker/consultant/lawyer?

The stuff you do in investment banking is at least an order of magnitude simpler than making any useful software. It's basically modifying excel templates and debugging complex models, making slide decks that are 80% template slides, and working on deals that are intellectually challenging on occasion but a lot of it is blocking and tackling and managing processes

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.

Of all the programmers I have met in my life, I would trust only a select few to do the things that most professional engineers do on a daily basis. For example, control system engineering, where quite literally, life-and-death attention to detail is required. The scope of the knowledge required and (in)tolerance to error is astounding. Meanwhile, try to get a programmer to do something as essential and mundane as writing comments. It's like this eternal, "unsolvable" problem in the industry that nobody can fix.

Most of the well-paid programmers I know (including quite a few at AmaGooFaceSoft) can't wrap their heads around databases well enough to deploy a low-traffic web application. And this industry is now rather routinely hiring totally inexperienced people, right out of bootcamps, at salaries that are mind-blowing to most professionals. It's clear that this stuff isn't rocket science.

Well, yeah. That's what I'm saying. And so is the original article.

"...so it doesn't matter."

This does not follow. Maybe it does matter, but the market is irrational. For example: maybe there are a lot of highly-paid, under-utilized software engineers sitting around FaceGooAmaSoft, because FaceGooAmaSoft are terrified of what those people might do, if they weren't twiddling their thumbs and enjoying complimentary massages while eating catered lunches.

"There's a limited amount of people that can do programming, but also limited amount of people that can do safety-critical engineering. Perhaps there is some overlap. But can you engineer a bridge that's used by a billion people every day? Probably not, hence the salary differences."

Prove your claim. Most programmers making big salaries are affecting maybe hundreds of thousands of people a day, at best. It's pretty rare to find gigs where you affect even millions of people a day. Even inside GooAmaFaceSoft, those are coveted positions, with lots of cookie-licking and internal politics.

It seems more plausible to me that the market is where it is because of deep pockets and a willingness to engage in defensive spending, more than any kind of individual productivity. But yeah, this isn't an argument that is going to flatter most HN readers.

I honestly don't believe this. You did caveat that this is anecdotal, but it's such a bold claim of ignorance I think it should be qualified.

> And this industry is now rather routinely hiring totally inexperienced people, right out of bootcamps, at salaries that are mind-blowing to most professionals

This is also dubious. It clearly does occasionally happen, but those candidates are also not as inexperienced as you imply ( e.g they typically hold STEM degrees like mechEng, chem, physics, Maths - often from prestigious Universities - or have years of experience with non-dev technical work like security, IT, ETL, etc. )

Sorry, but no. It happens All. The. Time. Bootcamp grads are working everywhere, especially in SF. Throw a stone at the next Off the Grid, and you'll hit one, the stone will ricochet, and you'll hit another. These sorts of folks are readily employed in the writing of CSS and creation of web forms, which is ~99.8% of all day-to-day webapp work.

(Also: holding a physics degree and attending a bootcamp doesn't mean you're a competent programmer. Imagine suggesting that a BS in Physics makes you a competent structural engineer. The fact that you would imply this almost makes my point for me.)

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

  while( elephant.mass > 0 )
  {
     eater.TakeABite( elephant );
  }

(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.

Here's O(1):

    elephant.invisible = true;

The drop out rates from programming courses suggest otherwise.

The qualities of those people who have ever successfully written software programs suggest that there is no magical determinant that would prevent any motivated person from doing it.

Apply the construction from the Pixar film Ratatouille. "Anyone can cook" does not mean that everyone can, just that there's no one who couldn't.

I suppose some kinds of brain defect or brain damage could prevent it, if you really want to pick nits. But in that case the condition would likely also prevent that person from doing much of anything else.

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.

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.

The big problem with engineering isn't the specialisms, it's the name. Outsiders still think engineers are people who wear oil-covered overalls and are essentially mechanics.

Not one person in fifty understands that the job is mostly mathematical modelling of complex systems.

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.

Perhaps the second mark not only includes being good and knowing someone, but being good and providing a larger value, like being able to analyze and communicate with a company and quantitatively save them money through business process automation.

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.

Also, "Europe" means many things. I am talking about Berlin here. I also know other places, like Madrid, where you just simply earn pennies in comparison so the difference becomes even higher (Madrid is more expensive than Berlin, earn less)

I still decided to stay here though (because of quality of living, work culture, music and partying, politics).

Obviously, there are also US-based companies with globally distributed remote workforce, but those are a minority.

Yes: people who don't prioritize excellence in development. And it does require compromises in your life choices. You generally need to move to where the most interesting jobs are, where the cutting edge tech is being developed. It's a virtuous cycle: SV attracts the next generation of high quality developers because it's the place that already has the highest concentration of good developers.

> I didn't know the United States had unrestricted immigration.

FWIW, even though I got my H-1B visa, I stayed in London. It would definitely have been a better career move to follow through and emigrate. I have zero doubt it has cost me in career prospects and quality of opportunities.

Living in London is already a compromise in my quality of life.

My passion is research and free software, so yes I do "prioritize excellence in development." I don't have to move to the Silicon Valley nor the United States to take part in that.

You can definitely prioritize excellence in development, but only within the scale of a few humans. You cannot research what it is like to work at scale.

Scale of hosts, requests, code, people, money. It's an experience to itself.

It's always funny to "break" open source tools people rave about. Most recently elasticsearch is barely coping with some of my teams volumes and we have to do some really tricky distributed computing stuff to workaround and keep it happy. Mind you, like a Honda Civic, it is an amazing tool, and works brilliantly for most almost all uses, but at certain scale you need a Ferrari and that isn't something you can get anywhere but big companies. And when you learn by designing and debugging a Ferrari, everything else becomes trivial very quickly.

Given, he works at a company with stack ranking so I guess that company is self-selecting for developers like him.

"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.

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.