[foamflower]

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.

[namelost]

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.

[giobox]

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

[u801e]

> While I can't speak fully for medics

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.

[laythea]

I don't think that is what he/she meant. I don't know what your professional software experience has been like, but software is applied and required to some extent in all industries nowadays, and therefore there is a broader scope required. It is also more of a moving target. I'm a contractor providing software engineering services. One contract I might be doing Subsea control systems, the next OpenGL graphics hardware programming sprinkled with Java and Eclipse, the next contract may be embedded assembly language for turbine control systems etc. Law/Medicine maybe moving, but I am fairly certain a doctor or lawyer does not "move as fast". They tend to stay specialised in maybe an area or two. In fact, for a serious medical condition, from a patients point of view, I would be quite alarmed to be seen by a doctor that has not "specialised" in my condition. Ideally, one that does nothing but my condition. I think it is easier for a doctor/lawyer to fall into the trap of becoming specialised in one or two areas alone than a software engineer, simply for the fact that if I did not constantly have to become specialised in a new area, usually for every contract), then I would not be able to pay the bills. So I imagine that is what he/she meant.

[hobbyjogger]

Your point is a good one, but to me it confirms the comment you are responding to.

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

[laythea]

I think you misinterpreted me a little. I think the reason that lawyers and doctors cannot "jump around" is not because, for example, a lawyer cannot absorb the information required to be both a good corporate lawyer and a good litigator, due to it being too much. They can. It is that the system that they choose to be in (law/medicine) demands the individual to be certified and formally trained to such an extent that it cripples this kind of professional mobility. This is not true in software. Not because of any other reason other than society is catching up. Unlike the fields of law and medicine, where those fields are growing "linearly" with society. It is also the reason that I do not by law require to be a chartered engineer to perform my job to the full extent.

[ABCLAW]

The (jurisdictions will have their own phrasing) 'demand' placed upon lawyers is that they are competent at the work they're doing.

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.

[ACow_Adonis]

I have limited idea whether its fundamentally barriers in terms of the subject-matter (because I do not know or practice in multiple fields of medicine) or in terms of the social structure (where it is pretty obvious the highly structured/time-based hierarchical regulated fields).

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.

[terminalcommand]

I am about to graduate from law school. I also agree that a law degree "hardly scratches the surface" of law.

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.

[regulation_d]

One of my law professors speculated that you learn about 3% of what you need to be a lawyer in law school. At the time, I thought that was a bit conservative. In hindsight, it seems pretty fair.

[zozin]

Do you have a throwaway email? I'd like to ask you a few questions about transitioning from law to programming. Thanks.

[giobox]

Afraid I don't really have much to say about this - I did a postgrad Computer Science Masters, applied for Software Engineer jobs and started new career immediately following completion of Masters. I've known several law graduates follow this path. If like me you've always had an interest in the field and were a reasonably competent programmer before starting the CS degree this wasn't all that difficult by comparison - I found attaining the CS Masters easier than studying Law if I'm honest.

[tostitos1979]

CS PhD here and worked over a decade. Yesterday, I made a list of over a dozen technical areas in CS I feel inadequate on. I think the issue is not that a CS Masters is easy. It is that CS knowledge is a never ending firehose. When I graduated (2008), most NoSQL systems were not even created. For anyone transitioning from law/medicine to CS, while I welcome you to the field (good for you!! tech is awesome), just be aware that tech gets obsolete very fast. While an older lawyer or doctor may be considered experienced, the newbies right out of school may run laps around you (lots of examples but the creator of Ethereum comes to mind. I know oh so many PhDs who work on distributed systems but it took a Waterloo undergrad student to think out of the box).

[DubiousPusher]

Yeah if we're talking about barrier to entry, I can't think of one much greater than the LSAT.

[sethrin]

That's an interesting idea. What would you say makes the LSAT difficult?

[pathseeker]

>furthermore I'd argue it's pretty insulting to insinuate that Computer Science is somehow more difficult in this regard

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.

[dsacco]

> Why in the world would that be insulting and who is it insulting to?

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.

[infinite8s]

It's insulting to all the people who are doctors/lawyers/any number of other fields where the degree is just the entry point to being able to work in it.

[maxander]

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

[fnord123]

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

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.

[empthought]

For software developers (and in fact, for the general public), the smart play is to rely on real engineers to provide mechanical, electric, or electronic failsafes in their designs.

[mcguire]

That seems to have worked well for Intel.

[jpindar]

Nowadays the electronics has code in it.

[woolvalley]

And most mechanical engineers are not necessarily making bridges, they are making adhoc small objects.

[13of40]

> I'm pretty sure 90% of us would just look for a Stack Exchange question

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.

[mooreds]

> When you're starting from scratch

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.

[tracker1]

You haven't seen some of the really generalized questions that come up on stack exchange then. ;-)

That said, it's often a great resource.

[TheHegemon]

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

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

[maxander]

Oh, yes[1]. I was arguing why there isn't a knowledge barrier to entry into programming, not why there shouldn't be one. :)

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

[dredmorbius]

I'd argue the reverse: that in software, very small errors can have vast consequences, but it's virtually impossible in many cases to tell what those consequences may be or where they'll fall.

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

[crdoconnor]

>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

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.

[wetpaws]

I don't think the problem with programming is that it is complex or has wast domain knowledge, it is true, but this is not a unique problem.

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.

[cdaringe]

It's a good thought, but I agree with madengr. Other disciplines are faced with abstract challenges, and even those in plain sight are very difficult to reason about. Magnetic fields. Rotational moment of inertia. RMoI--still so confusing. Even simple to explain, easy to observe concepts can still be abstract and difficult to understand.

[madengr]

Have you taken a course in semiconductors? Just as much abstraction there, and EE in general, as CS.

[petercooper]

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.

[petra]

That's learnable. For example, military forces teach enlisted people with varying levels of skills how diagnose systems, and it works.

[laythea]

I disagree. It may be possible to teach a monkey to perform X. But can you teach a monkey to teach another monkey to perform X? EDIT: no implied insult there.

[rmah]

You can disagree but you would be wrong. I have personally taught people to diagnose and repair systems. Many others have as well.

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.

[laythea]

Not if X is problem solving, which is what I was getting at really. For example, you could teach a monkey to teach X to another monkey, but what if the other monkey did not consume the learned material. Then the teacher monkey would not be able to adapt to still achieve the goal of teaching the student monkey. What you say works, assuming what is being taught is simple, and there is no feedback from the monkey that is being taught to teacher monkey.

That feedback loop from student to teacher, is similar to a problem that you tried to fix, and it still doesn't work. You then need to adapt, just as the teacher monkey would need to when the student monkey did not understand what was being taught. How you adapt to the input from that feedback can not be taught, because the particular feedback that one will receive in the future cannot be predicated (for complex troubleshooting etc).

Sorry for bad monkey examples. :)

[laythea]

This is so true. In my job, it's the problem solving ability that is valued. Not the innate knowledge of tools etc that we use to solve the problems, however that is, off course, required also.

[fuggedaboudit]

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.

[zebraflask]

Agreed. I've done both law and programming. Law school categorically does not even try to teach aspiring lawyers how to practice. The classic curriculum is designed to teach you how to "think like a lawyer." There are exceptions here and there, but if you want practical skills, you have to deliberately look for the handful of seminars and clinics that teach them.

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.

[ithkuil]

Learning how to do X can be very easy if you accept an arbitrary level of competence as enough to claim "I know how to X".

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.

[zebraflask]

Don't let the electrical and hardware engineers hear you say that, that'll just open the old debate about whether software engineering is really engineering at all. (Kidding.)

[zelos]

In the UK the practical skills are taught postgraduate in a Legal Practice Course.

[cryptonector]

To become a good programmer you need either a gift (which some young people have) or experience -- lots of experience. A CS education gives you a good foundation, but you still need to learn so much more: software engineering practices, lots and lots of details, a variety of programming languages and their huge libraries, mistakes mistakes mistakes (so you can learn the patterns, so you can spot them in code reviews, so you can avoid making them again, ...), full-stack-ness (so you can scale, so you can foresee problems before they strike), ...

[namelost]

To be honest I'm not really sure how it works in the US, but in the UK if a doctor has passed their exams to become a registrar, they are by that time reasonably competent to practice their chosen speciality (except for surgeons). Obviously being a doctor requires a lot of practical on-the-job training but the point is the whole process is managed top-down.

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

[throwawayjava]

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

[foamflower]

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

[jdmichal]

Yep. I've talked before that we are doing a huge disservice by not focusing on the sequential logic of programming, which is the first barrier to overcome. Also, we reinforce memorization over problem solving in maths throughout school. Hearing students say, "When are we ever going to use this?", was not uncommon when I was in school 15+ years ago. And as far as I can tell, the push for standardized curriculum and testing has only made this worse.

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

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

[vkou]

I've been teaching my partner bits and pieces of programming. Sequential logic, and control flow were some one of the easier topics.

[andrei_says_]

I call this the essential learning skill and am totally bummed that our public education not only does not cultivate it but actively deters it.

[austenallred]

I run a Computer Science academy, and that’s quite literally our goal.

[mancerayder]

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.

[mr_toad]

The number of hours of hands-on programming in a degree (probably only a couple of hundred a year) are too few for a graduate to learn anything but the basics.

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

[S_A_P]

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

[dsacco]

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

[sheepmullet]

> law and medicine

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.

[majormajor]

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

[sheepmullet]

> and still succeeded massively and then had the money to pour into cleaning up the resulting messes.

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.

[heedlessly2]

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.

[saas_co_de]

> Programmers have to remember a vast amount of domain knowledge

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.

[rossdavidh]

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.

[mattferderer]

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.

[seanmcdirmid]

React is interesting. It takes something that we started out with, immediate-mode style UI programming, and brings it to something we have now, retained-mode UI (i.e. the DOM). History in our field loops...a lot.

[tclancy]

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.

[q845712]

I was just trying to point this out! Though in a more pedagogic setting: I have a very smart coworker who's been out of school for ~1.5 years. He works quickly and tends to create bugs he has to fix later. I got him to contrast his style against our coworker in his 50s who is slower to merge, but the rarely has to fix a bug!

[dhbradshaw]

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.

[geodel]

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.

[mcguire]

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.

[tonyedgecombe]

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?

[digikata]

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.

[mncolinlee]

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.

[commandlinefan]

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.

[jpindar]

Have you tried creating a game in a modern engine such as Unity3d? If you try going through a few tutorials, and browse through the asset store, you might be surprised.

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

[mrbombastic]

This absolutely. As someone who started later (in college) I was unbelievably dismayed at the amount of effort it took to output something that was nowhere near comparable to the software I used daily and took for granted.

[foamflower]

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

[mncolinlee]

When I taught AP CS, I got around that rigidly logical issue by performing a very simple exercise on the first day of class to build an appreciation for algorithms.

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.

[cortesoft]

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?

[aaavl2821]

I think there are two interesting correlaries:

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

[fuggedaboudit]

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.

[unoti]

Software keeps working after the work is done. That’s the key differentiator, not the brain power. This leads to economies of scale on two fronts.

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.

[Eridrus]

Software doesn't keep running indefinitely. It has a shelf life of a few decades at the most, and usually just a few years.

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.

[aaavl2821]

A lawyer can make a small modification to a drug patent that helps a company earn for example $2B a year for 15 years rather than 12

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

[aaavl2821]

I hear you; I'm only a hobbyist programmer myself. I worked in investment banking at the beginning of my career and did an MBA so know lots of consultants and work a lot with lawyers in my work at startups, and I know those can be grueling jobs and that most people don't make nearly as much as the lucky few at the top firms

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

[badpun]

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

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.

[BookmarkSaver]

>I'm only a hobbyist programmer myself.

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.

[aaavl2821]

I tried to make that point in the post, though I don't have experience building large scale software. If hobby programming is building a go kart in your garage then the analysis you do in banking is like playing Mario kart :)

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

[solipsism]

Are you at a top tier law firm? Because you're comparing yourself to programmers at a top tier employer of programmers.

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

[fuggedaboudit]

Yep - top tier firms pay roughly the same as tech companies do as far as I can tell (with the added bonus that you don't need 250k in grad school loans to work for Google at an entry level - and a much higher ceiling for the truly, amazingly talent).

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.

[cobbzilla]

"something less than perfect and you could personally be on the hook for your license"

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.

[madengr]

Lawyers don’t have the monopoly on 60 hour weeks of deep thinking.

[TheCoelacanth]

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.

[1] https://www.bls.gov/oes/current/oes_nat.htm#17-0000

[vostok]

I think I have to disagree with both statements.

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.

[aaavl2821]

I agree with your statement but when I said "hard" I meant the work itself was hard rather than the work "lifestyle", if that makes sense

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

[vostok]

That's a good point and I mentioned it because you included social work in your list of hard careers so thought hard doesn't necessarily mean doing hard math/logic/etc.

[aaavl2821]

I think social work is a hard work "lifestyle" but also hard in the sense the problems you are trying to solve are very hard. In banking / consulting advisory work, the problem is making the client happy, which is not easy but not as hard as rapidly scaling a software system, or "solving" the problems like ptsd or homelessness that social workers deal with.

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

[dsacco]

> 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?

[georgeecollins]

Every task is easy to the person who doesn't have to do it. I usually say this to non-technical people when they ask for a feature that sounds simple to do, in their minds. But the same fallacy is at work if you think that highly paid bankers or consultants have mindless work.

[aaavl2821]

A former banker, have also done freelance consulting work and did an MBA do know lots of consultants. I'm relaying things I've heard from lawyers I've worked with in various roles. Am a hobbyist programmer, been doing 10-20 hrs of coding / week the last 18 months, and interned at a FAANG in business roles tho knew some engineers

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

[regulation_d]

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.

[jimbokun]

"Of course I'm probably missing some hard stuff that pays well"

Hitting major league pitching.

[dagw]

Programming seems to be the "hardest" of the high paying jobs mentioned

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.

[jopsen]

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.

[jimbokun]

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

[timr]

I don't know why the parent went to hospices and nursing homes as a counterexample, but your response is missing the point: lots of jobs are hard in the way that programming is hard, and don't have the same compensation levels.

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.

[guntars]

The compensation is not based on how hard the job is so it doesn't matter. 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.

[timr]

"The compensation is not based on how hard the job is"

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.

[doktrin]

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

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

[timr]

"this is also dubious. It clearly does occasionally happen, but those candidates are also not as inexperienced as you imply"

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

[kansface]

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

[logfromblammo]

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

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

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.

[hoosieree]

No real programmer would propose an O(N) solution like that.

Here's O(1):

    elephant.invisible = true;

[imtringued]

And now the world is filled with invisible elephant carcasses.

[jopsen]

Careful your not over-engineering :)

[mr_toad]

‘Writing software is not difficult. Anyone can do it’

The drop out rates from programming courses suggest otherwise.

[logfromblammo]

It is unclear whether that is due to lack of aptitude, lack of desire, or incorrect expectations.

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.

[mathgladiator]

Sure, but how much time does one need to invest to handle the constant loss at a retirement home.

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?

[Clubber]

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.

[jarsin]

Whats this thing you call "good specs"?

[wcarron]

What are "specs"? The most I get is a shout from the marketing director, "I NEEEEEEED X! Project Manager ok'd it 3 days ago!"

[Clubber]

Bad specs bumps you to level 2.

[drharby]

Very small pebbles

[dsacco]

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

[foamflower]

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

[1] https://vimeo.com/110554082

[whack]

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.

[guelo]

I studied Electrical Engineering in college and I've been a professional programmer for 10 years. EE is much harder.

[mythrwy]

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.

[siegecraft]

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.

[latj]

Programming is easy. I taught myself. It just took 5-10 years.

[mr_toad]

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.

[throwaway287391]

> These barriers may not be artificial, but they are real.

Real and non-artificial? Could it be?! :P

[s73v3r_]

"I once had a top-tier business school grad friend claim that programming really isn't that hard and that we're all whiners."

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.

[kudokatz]

https://xkcd.com/793/

https://xkcd.com/1831/