# Why is computer science hard?

Data pretty regularly shows that computer science programs have among the highest failure and dropout rates of any college program. A number of sources all echo the finding that roughly one-third of incoming CS majors do not progress to a second year, higher than most other majors.

I teach computer science majors at a U.S. community college, and the non-passing rates are even higher in this context. A few times in my introductory programming course, I will mention this fact (that computer science is among the hardest majors), partly to set expectations that students will need to work hard to succeed.

This semester I had a student in my virtual office hour ask, "Why is computer science harder than other majors, as you say?", and I was a bit flat-footed for a good response.

So: What would be the best reply to a beginning CS student who asks, "Why is CS hard?"

• many factors but maybe a big one is the high mathematical content, and some abstraction, etc. and lets not forget that simply science itself is "hard" and there are a lot of indicators pointing to erosion in societal widespread scientific focus, awareness, literacy etc... there is also an old expression "nothing very worthwhile is easy...!" building really great things is hard... also there is a well recognized phenomenon of historical waves of students entering the field based on mass media/ hype, eg "social network" movie etc!
– vzn
Nov 17 '20 at 18:36
• The first link says that the drop out rate is 10% for CS, 7% for Business or Engineering, so not a huge difference. It also says that 53% dropped out because they weren't getting enough value for their money, 50% because they were not interested, and 33% because it was too hard. So, the first two causes are the important ones, showing that... these students chose a major that didn't actually fit for them. This is not the fault of CS. Why are we still kicking this can? Nov 18 '20 at 11:42
• I'm speculating that many people go into it because they perceive that this will lead them to great careers, until they realize it's something they're absolutely not into at all. In some countries, like India, computer work has been touted as the way to earn a lot of money and many people rushed into it without being interested in the topic one bit. Nov 18 '20 at 17:35
• @ScottRowe, some subjects really require at least some interest to gain enough proficiency. I think tech is one of them. Nov 18 '20 at 21:10
• Because schools no longer teach how to think logically - even as little as they used to do that they don't bother anymore - and sharing good feelz just don't go too far when it is a computer you're trying to get to do what you want it to. (I am not joking. Just look around at the questions asked by 1-rep-point newcomers on SO and you'll see a complete inability to even ask a relevant question about stuff so basic it doesn't even qualify as programming, just thinking about how do you something one step at a time. You'll see plenty of confirmation of my point.) Nov 18 '20 at 22:33

The difficulty of CS (true or imagined) and the drop out rates are not the same thing. Let me start an answer, but it might take several iterations to get all my thoughts together on the two ideas.

Two themes come immediately to mind.

The first is periodic and I don't know where we are in the period at the moment. But in certain combinations of economic factors and media hype, a lot of students go in to CS not really understanding what they are getting in to but are lured by the, perhaps elusive, draw of big salaries. There is a lot of hype out there about AI at the moment, and self driving cars, and going to Mars, etc. People get in for the wrong reasons and decide they really didn't understand what it was and that they don't really like it. It doesn't need to be hard to drive people away, just boring.

The second major theme is that there is a lot of bad teaching around CS as has always been the case. Some people teach it as misspelled mathematics, which it is not. Some people in elementary and secondary schools are forced to teaching CS and especially Advanced Placement CS when they have little understanding of the topic and just try to stay "one week ahead" of the students. This is, and has always been a recipe for disaster. I don't blame the teachers who have to do this as many are forced in to it (in the US) simply because schools are underfunded and understaffed with too few specialist teachers.

WRT the second theme, it might even be that the current push to teach "CS" in elementary schools is actually part of the problem, not the solution. A serious college level course in CS might be shocking to someone who has only dabbled in trivial elements of programming. In particular CS is NOT programming, though skill in programming is needed.

Too many beginning students and teachers think that programming is "if" and "while" and "assignment" and nothing else. The current AP curriculum, I think, is seriously flawed (dropping interfaces, in particular). Students program in "rich" languages and environments using only the lowest level concepts, never really understanding abstraction or (gasp) polymorphism. Compare that with big ideas that you find in a philosophy or (hopefully) history course.

And if you combine that with asking them to write programs that they find boring, they aren't likely to stick around for long.

• I can relate about teachers in early schools (I don't know the American education enough to know which levels) not knowing programming enough. My first programming lessons were with a math teacher who was good in algorithm but came to me regularly when a student has an issue because I started programming by myself before going to this class. I have also seen some people who thought "CS / programming is easy I go on Facebook everyday", these people did not last a long time in the programming school I went on...
– f222
Nov 17 '20 at 8:01
• The introductory AP computer science class (at least at my school) is awful. It spends more time talking about niche aspects of programming (image manipulation, databases, and so on) than it does about functions, loops, syntax, string and list manipulation. Even worse, AWS basically sponsors it so half the course is just learning to use one particular company's AI stuff. No wonder people do so badly later on... Nov 18 '20 at 15:28
• @CeesTimmerman I was in a college course that used SICP almost 40 years ago. Lisp seemed interesting up to around page 300 where they basically said, "But this won't actually work, so we need to use this big hammer to make it work." Just teach me the big hammer right away and skip the interesting digression. I lost all interest in Lisp after that. C worked from page 1. Nov 18 '20 at 19:01
• @ScottRowe And many, many problems faced by the industry stem from the very questionable things C lets you do in order to work from page 1. We would be a lot better off if more software were written in languages that forced you to do things the right way rather than letting you get sloppy in exchange for apparent success. Nov 18 '20 at 20:07
• I agree with your observations that CS is grossly misunderstood and teaching CS is grossly underestimated. But I'd like to remark none of this is new: E.W. Dijkstra already made these observations back in the 80's. (I think a summary of Dijkstra's essay is worth an answer on its own, as he has more interesting hypotheses on why CS is hard as well, but I unfortunately cannot afford to spend the time on it, so this comment will have to do. ) Nov 18 '20 at 21:21

First, I somewhat dispute the premise of the question. I don't necessarily believe that it is harder. I think there may be some other elements at play.

Unlike many other college fields, students often have little to no formal background in the topic prior to entry -- in fact, many have little to no relevant background at all. That means that they're coming in blind. By contrast, many college majors come populated with students who have years of background in a topic, and are fairly certain that they like aspects of the field. (Consider majors like mathematics, music, or English, in which students will typically enter in with many, many years of built-up skills.)

(As an aside, there is a small added difficulty. Using modern apps on phones and websites not only teaches students little about computer science, but in my experience, it has almost been a negative. It gives students the feeling that they are mastering aspects of computing, but hides away so many details that I believe it can actually add to the frustrations of students once they are faced with actual programming, working with command lines, importing libraries, etc.)

Additionally, CS has also, and fairly suddenly, become a wildly popular major. They come, I think, largely because they believe that this is where the jobs are. Few of them come because they have deep enthusiasm about the field. In reality, most of the students entering have little to no practical experience.

This will make for some frustrating mismatches. To use an example from above, if a large population of students who had literally never read an eighth note (quaver) suddenly enter into college music majors, do you expect that the results would be very different from what you are seeing among your computer science population? Certainly, a fair number of them will be able to pick up and get things sorted out, but there will absolutely be a sizeable population who will find that wall too hard to climb.

• This is somewhat the answer I was going to write - why do people begin a course of study at 18 with no experience? That seems bananas to me, and is the real issue that needs to be addressed. For most complex subjects, apprenticeship is what has worked, historically, and what will work for human beings. The formula is: get people to do simple but useful things when they are young, and gradually raise the level of difficulty so that they gain expertise in a reasonable way. They each top out somewhere and you have the normal range of mastery. The only problem is: you can't package and sell that. Nov 18 '20 at 11:53
• @ScottRowe Apprenticeships work well when there are enough unskilled tasks that someone can do whilst learning the skill. The problem with software engineering is that there is so much to learn to be sufficiently competent for the reletively unskilled tasks that apprenticeship style teaching only really becomes relevant once you reach the level that CS undergraduate course teach to. Nov 18 '20 at 13:22
• As to why people don't have enough prior experiance, a big part is that software engineering salaries are high enough compared to educators salaries that you really need some other compensation to provide a comparable package to industry, and only academia can offer that where teachers are primarily researchers. And even that is hit and miss. Nov 18 '20 at 13:23
• "They come, I think, largely because they believe that this is where the jobs are." Which is not wrong. CS is one of the fields where it is common to hire dropouts and not too hard to land a job even if you didn't finish the degree. So why would students that are mostly interested in the money side of the equation keep studying when they are already offered well paid jobs long before they reach the end of the program? Nov 19 '20 at 13:20
• @blues I think that this question mostly refers to the students who are dropping out from cs1, because they either didn't like it or couldn't keep up. But that's certainly a good observation about upperclassmen, and also about graduate students who don't finish because they are specialized enough in something like AI to earn mid-6-figure salaries even without their PhD.
– Ben I.
Nov 19 '20 at 15:48

Here's an attempt at an answer, with some reflections, and then hopefully at the end a concise reply that we could deliver to an introductory student. For the purposes of this answer, I'll assume that in the first year or so, teaching computer science is synonymous with teaching software engineering.

Motivating Quote

Edsger Dijkstra wrote in his paper, On the cruelty of really teaching computer science (1988):

From a bit to a few hundred megabytes, from a microsecond to a half an hour of computing confronts us with the completely baffling ratio of $$10^9$$! The programmer is in the unique position that his is the only discipline and profession in which such a gigantic ratio, which totally baffles our imagination, has to be bridged by a single technology. He has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before.

An Open Question

Prelude A: This is an area of ongoing research, and there's no consensus theory at this time. While the difficulty (as evidenced by high fail rates) has been known for decades, no predictive educational theory as to why this is the case has garnered significant evidence. (Intriguing example from 2015 that ultimately did not support its hypothesis.)

STEM, but Moreso

Prelude B: Of course, CS is in the STEM meta-discipline, and those programs are commonly more demanding than non-STEM courses. Like any STEM field, CS is technical, detail-oriented, and has objectively right and wrong answers (at least in terms of what counts as a syntactically valid program, a program that produces logically correct results, and so forth).

That said, the data seems to show that CS has even higher non-success rates than other STEM courses, so from this point on we'll inspect what makes CS even more challenging.

A Deep Stack

As Dijkstra alluded to, CS has a uniquely "deep stack" of technologies and systems in which the practitioner must work, master, and smoothly adjust conceptual level of abstracted thought within the course of a work day. Some have called the computer the most complex creation of mankind; e.g., in the title of David Eck's introductory CS textbook, The Most Complex Machine.

Likewise, consider Joel Spolsky's Law of Leaky Abstractions: "All non-trivial abstractions, to some degree, are leaky." As much as we would like to encapsulate computing technologies into neatly abstracted layers, this turns out to not be completely feasible. At any point in the workday we might need to shift mental state to some other layer in order to analyze, debug, or properly design a new part. E.g.: It's just a few conversational steps from thinking about worldwide internet protocols, to the need for check codes and error-handling, to the existence of cosmic rays in the physical universe that might corrupt transmitted data.

In this regard, I sometimes point students to this image (I believe first originating from a website that no longer exists, but e.g., referenced here).

Syntactical Strictness

In CS, the work is mediated by the computer system itself, which is fairly demanding in its syntactical strictness. Compare to work written in math, physics, chemistry, etc.: it will likely be read by a human instructor, who may be able to forgive or fill in some smaller errors in spelling, grammar, punctuation, etc. But with computer syntax no such flexibility is possible: if a single symbol is misplaced, then no defined program exists. Particularly for students with ID's such as dyslexia, this may be a significant extra challenge.

Need for Language Skills

The computing student also needs fairly high-end reading, writing, and communication skills. Problems are almost never delivered in purely symbolic form, as may sometimes be done in math, physics, chemistry, etc. Everything is a "word problem", and students must be proficient at reading, interpreting, asking for clarification (in a natural language, e.g., English), then designing, implementing, and testing, and finally documenting and explaining the design and code (again in English). Interfaces to the user must likewise be clearly expressed. For students with weak English skills, possibly still learning the language for many foreign students, this is another significant challenge (probably more than other STEM fields).

Wide Domain Knowledge

Related to the English communication skills noted above, the student likewise needs a lot of "domain specific knowledge". Introductory problems are likely to come from many different fields -- e.g., in my own course, book exercises involve geometry, statistics, savings interest, sound waves, biological population growth, workplace employment rules, taxation, meteorology, sports, corporate finance, etc. If a student has been deprived of a wide range of learning opportunities about the world, then they will be further disadvantaged.

Technologies for Teams

The other thing that I personally find challenging in teaching introductory programming is that so many of the core features of modern languages are designed to support large teams working cooperatively on long-term projects (see Brooks, et. al.). But for many reasons (such as the need to master all the basics), students are working on assignments and tests in isolation. Features such as modular functions, scope rules, local variables, classes and objects, encapsulation and data-hiding, etc., really only make sense in terms of a large team of programmers, engaged in a division of labor, communicating in a structured way so as to not corrupt the overall system. This is a story that I'm constantly trying to tell to my students and want them to visualize, but I fear that the lack of concrete experiences with this "large team, complex software" reality makes it hard to fully appreciate.

Conclusion

So here's my stab at a brief answer to the inquiring student: Computer science is something of an everything-discipline. One needs to develop good skills in the entire STEM spectrum (science, technology, engineering, and math), as well as top-end reading, writing, and human communication skills, and be able to work well both alone and in a team. The computing professional must be detail-oriented (to the level of individual symbols), simultaneously be able to keep the big-picture in mind, and adjust the level of conceptual abstraction at any time. One also needs to be able to digest a fairly large amount of new technical detail at a rapid pace, learn about other arbitrary domains in the world to interface with them, and be committed to continually learning new fields and technologies throughout one's career.

• So: don't try to write a symphony if you can't write for any single instrument. Don't try to be a Conductor if you can't play any instruments. CS requires, as you say, ability in many areas at once. Why would we think that it is something that can be easily and directly taught? Or that many people could develop a flotilla of abilities at the same time? Because the initial success was with a few very motivated and 'gifted' people. That does not generalize. Let people choose, by doing some of it when they are young. And if they don't like it, they can do something else. Nov 18 '20 at 11:58
• Saying much the same thing, I think: computer programming is hard because "math is hard". Even though there's precious little math in most programming, there's a LOT of the same analytical skill required for geometry proofs -- and not only do geometry proofs require skills that most people hate (because apparently most people's brains aren't wired that way), but also because apparently children aren't being taught proofs like I was 40 years ago. Nov 18 '20 at 17:48
• Upvoted for pointing out that many of the techniques we learn only make sense when working on big systems and/or teams. Managing 1,000,000 lines of code is very different from managing 100 — and much harder to demonstrate… Nov 18 '20 at 21:31
• @RonJohn Computer programming per se is not CS. I can program most everyday business applications using existing tools and libraries, but I would be hard pressed if I had to attend university CS, which deals with the math underlying many of the libraries. Nov 19 '20 at 8:29
• I wasn't aware of Dijkstra comment, but I completely support it. The range and scope of what I need to be aware of is incredible in the time domain alone. When tweaking circuits on a wafer, I need to think in femtoseconds. When working with signals on a PCB, I'm usually in nanoseconds. For communication within a room, microseconds. Network hardware signaling works in milliseconds. Human reaction times in deciseconds. Long-range networks in seconds. And from there the time grows longer. Subsystem processing times. Backup retrieval times. Earth-Mars-Earth comm times. 1::10^18 already.
– cmm
Aug 6 at 2:20

From my experiences (I studied about 15-20 years ago, and my cohort lost 50% of students within the first four semesters), the main reasons are these:

• Many students do not really know what CS is about. They might think that it's about learning how to work with computers, or become "power users", or programmers, or something along these lines. I don't think the general public generally knows what CS is. I daresay this is not much different from an electrical engineering student expecting to weild a solder iron a lot; or a mechanical engineering student expecting to work with a metal lathe. At least in my western country, there really was no good way for a young pupil to really find out about this.
• Some topics actually are really hard; for example if you leave the mainstream programming languages and dig into functional, logic or constraint programming, or theoretical CS topics.
• Some topics are maybe not very hard, but unless somone is really interested in them already, the university might not necessarily present the topic in a way that creates interest. In my time, there were the classic lectures like how to build a compiler for a programming language; or more theoretical topics like automatons, temporal correctness and such. I think I can count the number of students in "my" class who were really interested in the topic on one hand, amongst dozens or in some courses hundreds.
• I don't know how this is these days, but in my country, in the 1990's, CS was strongly coupled to maths - we had plenty of obligatory maths lectures which we shared with beginning maths or physics students; hardcore linear algebra, functional analysis, statistics etc. - totally irrelevant for 99% of all CS students, but there was no way to avoid it. This most certainly got rid of quite a few students for better or worse.

By the way, this does not end in the university; the same phenomenon happens in IT companies - you get a few high-flyers who really live and breathe IT and CS (as far as CS applies to IT in modern software projects at all...), and plenty of people who just do their job on most days, or eventually find out that it's just not for them.

• Your last paragraph, is true in general. To get to the 10,000 hour mastery mark, you need to put in those first 9999 hours. Nov 18 '20 at 18:49
• This answer matches my experience pretty exactly. I studied CS from the mid-1980s to the early 1990s in a European country. 50% of the students in my cohort dropped out during the first two years as well. The last bullet point in particular rings true for me: I almost failed due to the stringent math requirements, despite doing well in math back in high school. Nov 18 '20 at 22:36
• I've always wondered why corporate IT recruiters believe CS is relevant to most of the positions they are trying to fill. The only answer I have been able to think of is: it has 'computer' in the name Nov 19 '20 at 3:06
• Your last bullet point is THE reason in my experience, and is still very true in the US today! As a current CS student, I'd love nothing more than to have a computer science class that actually challenged me, but 95% of my time has been spent on the associated math and physics requirements, which is why I'm currently in my 4th year of a "2-year" college, hoping to transfer to a "4-year" college next fall. Nov 20 '20 at 1:09

Maybe some of those who "fail" should have been somewhere else rather than funneled into computer science.

There needs to be a differentiation between those who want to study computer science (advance the state of the art) and those who just want to write programs (make use of existing techniques and tools.)

I'm in the "just write programs" camp. I don't belong in computer science.

I'm going to present the view from someone who left computer science early - one of those from the "failure and dropout" group.

Me.

I am a programmer. I make a good living writing programs.

Way back when I was young, I learned to program on home computers. Early 1980s.

Telling a machine what to do isn't difficult. It has a limited vocabulary that you can "speak" to it in, and it has a limited ability to give you responses. You break the task down to pieces and phrase it in the vocabulary the computer has and tell it how to assemble its response. No big deal, though you do have to understand the task yourself first.

When I started taking university courses, the options were MIS (management information systems - managing computer systems) and computer science. I didn't want to baby sit the machines, I wanted to program them and ended up in computer science.

Computer science at the time was more about the theory, the mathematics of how computer logic and algorithms work. That is, studying things that would let you make better computers or discover new algorithms.

That wasn't what I wanted at all. I wanted to learn how to be a better programmer.

1. Better approaches to breaking down problems.
2. Better ways to organize my work.
4. Learn how to make an easy to use program (user interfaces.)

None of that was taught in the courses available to me.

We were exposed to other programming languages - there were several courses that were dedicated to specific languages.

All I wanted was to be a better programmer, and all I could get was things that I'd need to (someday) be able to do computer science research.

I'm not in the least interested in designing a hashing algorithm. I'm interested in writing a program that makes some task easier - and that might involve using hashes or dictionaries or linked lists or what have you.

What I wanted wasn't available at that time and place, so I quit. I went off and joined the US Air Force, then got a job working in electronics, then cycled my way back to programming through my work experience.

My experience with computer science was that I want to make things, but all I was learning was how to someday be qualified for research.

Imagine somebody who is good with a hammer and a saw, and he wants to be a carpenter. He tells the folks in school that he'd like to build things - houses or furniture or bridges - and they send him to college to study mechanical engineering. Mechanical engineering teaches him how to design the things, but that's not what this guy wants. He wants to be out there on the construction site, driving nails and cutting wood. He drops out of college, and goes off looking for a way to do what he's interested in.

That's me and computer science. I want to make things with the tools and materials available, not develop new tools and materials.

It takes some theory (of course it does) to be able to write programs. You need some idea of how the machines work, and how things get from code to execution. You don't need to be able to design a CPU in order to use it.

Could it be that many of the dropouts just don't want what computer science has to offer?

We need computer science, just like we need mathematicians and physicists and architects. We also need people who write programs just like we need people who pick up a hammer and a saw and build the things the architects and engineers design.

Is there a better place to learn programming than in a computer science setting? Maybe that's where some of those "failures" and "dropouts" need to be - learning to do things with today's tools rather than looking for tomorrow's tools.

Maybe those folks who fail just needed to directed to a more appropriate place so that they can succeed at the underlying task that brought them to computer science.

• I agree that there's a long-time institutional failure to distinguish between "computer science" and "software engineering". But even if we cut out the heavy research/math components: many or most students can't pass even the introductory programming course that you're talking about. Nowadays there are indeed "coding bootcamps" to provide the non-theoretical training. But, they have little oversight, and an interesting tidbit in this article: "only 12% of bootcamp grads didn’t previously complete a four-year college degree" thepennyhoarder.com/make-money/side-gigs/coding-bootcamp Nov 18 '20 at 17:09
• It's been 35 years since I implemented a non-trivial hashing algorithm, b-tree, or invert index, and almost as long since I implemented a linked list. I also was a DP programmer (now a DBA), but even still that background has bee very useful in choosing the best library or database design to use. Nov 18 '20 at 17:57
• I don't understand why you don't think knowing how algorithms work doesn't make you a better programmer. Understanding concepts like graphs and time complexity have definitely made me a better programmer. A lot of people who I've worked with who claim CS isn't helpful for programming make very naive choices that lead to inefficient, overly complex, and inefficient solutions and have no idea how poor their choices were or why. Nov 19 '20 at 16:12
• I just found this to be a bit of a non-sequitur "... the theory, the mathematics of how computer logic and algorithms work. That is, studying things that would let you make better computers or discover new algorithms." i.e. "... the physics, the engineering of how engines and combustion work. That is, studying things that would let you make better cars or discover new automotive technologies." Knowing how things work definitely makes you a better technician. It's not just for research. Nov 19 '20 at 16:39
• But overall, I agree with your sentiment. I personally think CS programs need to get serious about having a software engineering track/degree. A lot of CS programs are pretty much already there, they just don't call it that. Maybe your program was a more rigorous CS program that what I experienced. I also started in Physics and used credits from that program to fulfill some CS requirements so my experience was somewhat unique. Nov 19 '20 at 16:42

Looking back on my experience and education as a software engineer, I think the largest inherent contributors of difficulty in computer science are that it has exceptionally strict and unforgiving standards for correctness, and that solving problems in it often requires an exceptional degree of questioning or ignoring "common sense" basic assumptions.

In many (or most?) other fields, getting something wrong by a small margin usually has an effect that is worse than desired by a correspondingly small margin. There are exceptions, of course, but there's usually a region of tolerable error. In software source code, it is not only not rare, but actually common for small mistakes to have large or even catastrophic consequences.

Those small mistakes in software source code often appear superficially to be completely correct. That apparent correctness tends to rest on an assumption so basic that programmers don't even realize they've made it. Logical reasoning as typically practiced by humans involves an enormous number of unstated assumptions, all predicated on a life experience in a world governed by physics and inhabited by other humans. Computers don't have those assumptions, and operate by their own internal logic that was artificially created by legions of computer scientists. To find and fix software errors, or to prevent them, a software engineer needs to be skilled at examining those assumptions and stripping them away to correctly follow the computer's logic, and that is a skill that actively opposes many people's instincts.

In short, to succeed well in computer science, a student needs to master a counterintuitive skill, and the bar for mastery is close to being pass/fail.

In addition to the many good answers on here, as a past student, TA and instructor in CS — most programming assignments and projects often take large amount of time, even if slimmed down to just fundamentals. There is a definite learning curve to build the skills, and personal mental model surrounding syntax, compilation, building, layout, debugging and deciphering build errors, and that’s before the more interesting data structures and algorithms kick in.

At my uni, there were the “Big 3” 4th year courses that were advised a) not to take more than one a term, b) to take a lighter course load if possible. Despite this, all nighters were a given, and some labs even had couches to crash on. The graphics course was hands down one of these, given the involved and highly detailed work required to get things working. And it is the same effort and work ethic that is essential to eg. the games industry which still motivates many people to register in CS.

Some people realize this time commitment and determine they either don’t have, or don’t want to spend their time this way.

Computer science demands a set of qualities, some of which are somewhat antithetical. One is the attention to detail. Another is the creative ability to build strong abstractions that are both powerful and useful. This involves some pretty heavy lifting in the big picture thinking department. However, it is hard to get off the ground in programming if you are unable to manage the syntactical exigencies of the language you are programming in. It is also hard to get off the ground if you cannot walk through a complex chain of logic.

In short, it requires some very serious effort and a very special mix of skills to become a good programmer.

Computer Science, as taught, is a combination of Mathematics and Computer Programming. Mathematics is the part that is the theory of computing, and programming is the art of applying it.

I'll dub the Mathematics party "theoretical", and the programming part "applied".

Now, both parts are hard. But are hard for somewhat different reasons.

## Applied Computer Science

Programming is hard for a few reasons. Every programming problem is judged first not by your instructor, but by the world's most harsh marker; the compiler/interpreter. Every program you write ends up being instructions for some idiot-savant computer to follow.

It is like trying to write an essay in English, but if your letters aren't formed right, you have any spelling mistakes, or there is any grammar errors, the teacher isn't able to actually read your essay. Instead, they are forced to examine each word in isolation, then after verifying them themselves they can look at each sentence in isolation, etc.

This creates a sharp discontinuity in your initial ability to get things done. The syntax of the languages you are using is, almost unavoidably, harsh on relative beginners.

Once you pass that tier, you end up with yet another situation where there are discontinuous errors that are harsh on relative beginners.

Programming is the art of managing insane amounts of complexity while telling a complete idiot how to solve a problem, exactly.

The ability for computers to do things exactly as described, extremely quickly, means programs are some of the most complex things humanity has ever designed on purpose. As someone learning programming, you end up building increasingly complex things. Each stage of this effort has to not only be good, but perfect, as errors in a lower tier of complexity will compound and make the next one impossible to do.

When you write a statement, your variables and operators can't have errors, or the statement won't work.

When you write a function, your statements can't have errors, or the function won't work.

When you write an algorithm, your functions can't have errors, or the algorithm won't work.

When you connect algorithms into a simple program, the algorithms can't have errors, or the program won't work.

You have to reach near-100% reliability on each tier, and learn how to deal with the less-than-100% reliability, before you can get any kind of reliability on the next.

To handle this, programmers have come up with increasingly abstract patterns. Each of these patterns is [b]hard[/b] to master, as they encapsulate extremely complex problems with seemingly arbitrary rules.

A short list of these patterns that programming students find hard to master might include:

• Variables
• Assignment vs Equality
• Control flow and looping
• Recursion
• Sub procedures/functions
• Pointers and indirection
• Code generation and macros
• Encapsulation
• Purity
• Mutability
• Asynchronicity

(in no particular order, and not comprehensive).

People learning programming often run into one of these, and just can't get it. And unless you get it, you can't get past that barrier, and often fail out. (One of the advantages of Java and other managed languages to teach programming is that you can neglect much of pointers and resource management and teach other stuff at beginner levels; the downside is you graduate people who don't have to learn that stuff.)

These are all levels of abstraction programmers have developed to manage increasingly complex programs. Strategies that work at lower levels of complexity fail at higher ones, so students who are using "ill advised" strategies can easily pass a course then fall apart in the next one.

## Theoretical Computer Science

This branch is all about understanding the idea of computation, as opposed to the art. You do need it in order to do certain kinds of applied computer science problems, so even in "professional" courses it is taught. And as academics are teaching it, often it is included anyhow, as the theoretical computer science often is needed to expand the entire field of knowledge of computer science.

This is a branch of mathematics, and like most kinds of mathematics requires iterative mastery. In order to do multiplication effectively, you have to not only be able to do addition, but you have to master it. That very simple step is mirrored along the entire tower of mathematical knowledge.

In many other fields, you can muddle along with the previous foundation layer having issues, and maybe patch it up later. But when you try to do that in mathematics things just fall apart.

Mathematics in much of the world is initially taught by people who hate and are bad at mathematics -- elementary school teachers. So we end up with a lot of people with a poor foundation in ciphering showing up in secondary education, then muddling though classes without every achieving mastery, then deciding to go into a lucrative field (programming). And without mastery of the previous tiers of mathematics, the theoretical computer science they teach is extremely difficult.

The student, whose goal was "get a highly paid programming job", finds this abstract computer science both hard and difficult to connect to their goal. Their problems with the material are foundational; they don't have the background required. The educators problem is that teaching that background requires fixing their 10 years of primary and secondary mathematics the student came in with.

Cutting theoretical computer science for applied computer science courses is plausible, but then the students aren't able to predict very well how to make programs do new tasks without taking forever to do them (programming efficiency, algorithmic complexity), or deal with logic problems surrounding multi-threaded programming, or a myriad of other important skills in the applied field.

## Real World

Programming is currently a lucrative, expanding field. This has a number of impacts.

1. Students are drawn to it not out of intrinsic interest or inclination, but because they want to make money at it.

2. Experts are harder to convince to be teachers, as not-teaching is lucrative, and teaching is difficult.

3. The number of students grows over time, so the previous generation of students (who supply the teachers) is smaller. This makes the problem of finding teachers harder.

4. The field itself is young. With other fields, we know millions of ways not to teach it; with computer science, we haven't had time to make as many mistakes and refine our education.

On top of that, the profession is a relatively solitary one. So it draws introverts; convincing introverts to have a career teaching students is an extra problem, reducing the pool of potential teachers further.

• Actually, computer science is much more than what you suggest. This presents a very narrow view. Nov 20 '20 at 16:05

I have been a professor of computer science and engineering (CSE) in the USA for a number of years in ABET accredited CAC and EAC undergraduate programs (graduate programs do not have ABET accreditation in CSE as I recall). Reading these comments, I have a few things to mention.

The first is the economic motivation -- accumulation of wealth or even gainful employment. Most of such accumulation is based upon technology, not basic science or engineering. Many of the students I have met do not understand the difference between Information Technology (IT) and CSE.

Why is CSE much more difficult than IT? CSE is a highly abstract intellectual field that nonetheless has very concrete instantiations. CSE uses, develops, and requires "higher" mathematics. Does an IT person who is "information security certified" (typically with a vendor-based credential) understand encryption in terms of the actual mathematics (for example, I use both the declassified Shannon monograph as well the details of AES as explained in the original Rijndael exposition), or quantitative threat estimation, Nash game theory and what goes beyond Nash, etc.?

Admittedly, this is beyond what is covered in an ACM CS-1 course, but the issue is "why" do students find CSE "hard" (that is, a discipline in which many cannot demonstrate understanding proficiency).

IT is by comparison "easy" -- CSE requires mathematics, some of it developed by CSE persons, not "mathematicians", and the use of other fields to understand CSE whereas most IT-trained (and vendor "certified") persons know specifics of installing and "maintaining" a particular technology from a particular vendor (more or less the equivalent of "how-tos"). As an example: why does a real computer create heat? Because it produces information and thus reduces entropy, that requires work that in turn produces waste heat (increasing the entropy external to the created information) -- and requires an understanding of at least classical thermodynamics, or preferably an understanding of statistical mechanics and how entropy arises.

Coding is not too difficult, but algorithm design and then establishing that the algorithm is provably correct is not as easy. As neurosynaptic or quantum processors become more readily deployed, the issues will only increase. An IT person working on a quantum processor will memorize rules, but will most likely not have an understanding of quantum mechanics (and the underlying mathematics).

Some may interpret these statements as "elitist"; the issues are reality, not elitism. With intensive tutoring and dedication on the part of both the student and the tutors, many students who currently do not "survive" to a CSE ABET-accredited or equivalent diploma, can graduate. I have seen it and done it (with help from my TAs and myself) -- but those who dispense resources (funds, personnel, facilities) do not provide those resources, and students who could "swim" instead "sink".

I think there is a element where people are picking up on this 'everyone in the future must be able to code' attitude that has become fashionable in the last ten years or so. This is of course as ridiculous as saying everyone must be an engine mechanic or concert pianist. Everyone should be computer-literate, able to be safe online, spot malware and so on. The young men and women with a natural ability for coding should be spotted early and put into educational streams that encourage and support them and probably into decent apprenticeships\internships afterward.

Also these days so much of the coding world revolves around web applications and one look at that insanely over-complicated mess would put anyone off.

Maybe computer science is hard, because it gets lost in translation. Consider the following:

• The processor that you are writing code for is a bunch of logic blocks
• the language that you are using is a set of logic blocks as well.

Maybe the correct way to write software manuals is to simply show the logic block behind each keyword, and restrict human language to aftermarket tutorials, and how to manuals.

• I am not quite grasping, but I think you are saying something like: two similar-seeming conceptualizations are actually about very different things, and this is never made explicit. If it was, the reaction of students might reasonably be: "just teach me the one thing that works instead of two things that I have to learn how to connect together." This is why I often say, teach how the computer actually works instead of teaching a language-focused approach, like with Lisp or other machine-independent methods. Teach about the machine, then how the language is a tool to work with the machine. May 2 at 2:23

My head of department posed a question at a staff meeting, "how can we reward those students that work really hard?". My colleagues suggested cinema tokens, shop vouchers, prizes, ..., you get the picture.

When it was my turn I said "extra homework". There was a silence, then the head of department asked me if I "was serious". To which I replied yes, because the students that work hard like the subject and have intrinsic motivation, so they want to learn more, and so, the best reward we can offer is extra homework.

I was really thinking about Bem's theory of self perception. Self perception theory. Our political representatives and managers want to see success in STEM subjects generally, so many false promises, bribes and other forms of encouragement are applied to 'encourage' learners into STEM. I believe that particularly in CS our learners are being driven by the promise of extrinsic rewards.

Whether it is the promise of a large salary, the association of CS with 'fun' technologies or the social kudos associated with the movie images of hackery, none of the drivers are really about the subject. On arrival, instead of slick, fun and cool our learners find it takes 200 lines of C coding to put a dot on a screen, three years of pure maths courses to understand why neural networks don't work really and after reading a pile of books 2m high, countless RFCs and a half the UNIX manual pages they are still unable to understand what's wrong with their sendmail.conf or build a stable kernel, or use vim.

And why would they bother? Afterall, they are here for the salary, the fun, the kudos. They want to drive sports cars whilst playing CODwars and wearing hoodies. They don't want this. And they aren't interested in that either. Our basic problem is that they are the wrong students with the wrong motivations.

Out teaching strategies don't help either. Nobody is going to get taught CS. A few might learn if they're motivated though. If the teacher hasn't read Vygotsky and the class isn't based on some constructivist learning principles you can forget it. It was hard enough to learn CS forty years ago when it was this big. Now its like ....

The problem isn't that computer science is hard, its too easy. At least until you get to University when the truth finally kicks in (I am somewhat reminded of WW1 heroes off to 'give the old hun a kicking, hoorah' who then find themselves waiting to go over the top at Passchendaele). Out students are totally unprepared for the actual reality. CS is maths, plus compiler design, the vim editor, gray codes, the use of tensor algebra to model shapes (Bookstein), the use of analytical topology to prove results about Perceptrons (Minsky and Pappert), the Godel incompleteness theorem, using gdb effectively, engineering philosophy, automated theorem proving, why this b = (b * 0x0202020202ULL & 0x010884422010ULL) % 1023 reverses a byte in three machine operations and with solving the integer knapsack using intelligent backtracking we get the tip of the iceberg.

Great! There's loads of fun to be had in CS, infinities of it. But it isn't easy. We should return to teaching our young learners assembly language, get them editing real source code, throw all the maths from the trapezium rule to matrix inversions to axioms for semi-groups with unity at school. Its hard and maddening - work in groups, overclock the CPUs and watch them melt, rebuild kernels. Lets make it hard but lets have our students wanting to do actual CS. Failing that we will have no choice but to make it illegal, then we'll be seeing talent everywhere.

• The successful students get to keep working with computers. They actually get paid to do it. May 2 at 2:24

I would say the answer is shifting from "the strangeness of the platform" to "the raw number of operations that have to be perfect."

In the past, when computers were weaker, what made CSci so hard is that the tools did not fit the problems as well as we might like. There's something very unintuitive about how you had to work with them. And there's some real beauty in seeing how people grappled with this with cunning intuitions. The greats like Alan Turing and Grace Hopper truly revolutionized things with cunning shifts in intuition.

Nowdays, what I think makes CSci so hard is that the primary thing we do is operations that have to get repeated many many many many times. As I type this, in the USA, we are dealing with the 2020 national elections. There's great frustration in the handling of 330,000,000 slips of paper (give or take, depending on voter turnout) and getting them into the right places and making sure they're all done right. Its hard. And it has to be done 330 million times. We can afford to make a few mistakes here and there, we just try to keep them small so that they don't change the result of the election.

A while back, I did a computer science task which involved 4,000,000,000,000 operations, all of which had to be done absolutely perfectly in order for the answer to be valid. Four trillion operations.

For me, it was a Tuesady. There was nothing weird about these requirements. That was just sort of the usual daily expectations. I didn't even warm up a grid, which would have added a few zeros to that. That kind of perfection is just part of the job.

The tools you use to immaculately manage 4 trillion operations while you sit back and sip your coffee are, obviously, rather exacting. And its rare that we find places to use them outside of CSci, so there's not much room to develop intuition. I don't care how fast radix sort is, if you have to sort a bunch of numbers, you'll typically do it the intuitive way rather than the theoretically optimal way. And, having done it both ways, the theoretically optimal way is often slower (until you get to very large numbers of records).

The answer of jmoreno states: Compare those topics to https://en.wikipedia.org/wiki/List_of_unsolved_problems_in_computer_science, and try to figure out how those topics even get you started on the path to figuring out how you might even frame those questions, let alone solve them.

Computer science is hard because it’s a branch of symbolic logic and logic is hard. End excerpt.

Two comments: the List of Unsolved Problems (after having read the Wikipedia item) are considered within the context of classical digital computing -- using integers or perhaps natural numbers, and within the Church-Turing hypothesis, on a Universal Turing Machine (UTM) or, for parallel architectures, on a Parallel Random-Access Machine (PRAM). There are models different from either of these (with unsolved problems and conjectures); two of the most promising are quantum computers (and information transfer) and a rather more empirical approach, neurosynaptic computing (that has other names for similar concept). Quantum computing has a formal theory and is just starting to develop working hardware that instantiates quantum architectures. Neurosynaptic computing is a much more empirical approach to producing something akin to actual "artificial intelligence".

For example, one model uses an empirical connectome (at a specific scale of detail, not necessarily at each neuron and other brain components), observed from a non-human primate. This connectome is then modeled with solid-state electronic components (e.g., VLSI circuits that actually are fabricated). If the original biological brain has "intelligence", then the neurosynaptic electronic solid-state instantiation (model) is envisioned to have similar intelligence. The understanding of "how" the machine works, that is, a provably correct classical or quantum algorithm does not necessarily apply, but the empirical observations are intended to emulate what the biological brain would have done, including learning and adaptation to new "stimuli".

My point is this: in addition to the stated classical unsolved problems, completely different approaches to computation are being proposed and actually developed into physical machines (with the understanding that biological systems are, in this sense, physical machines -- no supernatural invocations involved). The issues that make computer science "hard" are now harder. The other point is that computer science uses logic (the first-order classical predicate calculus or perhaps higher orders), but in many ways goes beyond such logic. It requires mathematics (including "arithmetic") to establish algorithms; however, once one accepts that, one is beyond logic that provably is consistent and complete, and faces instead the problem of Gödel's incompleteness theorems.

• "because it’s a branch of symbolic logic". That is only a part of CS. There is much more. Nov 24 '20 at 13:30

I don’t see anyone mentioning the fact that programming ≠ computer science. These are two entirely different disciplines, and it seems to me that there isn’t enough emphasis on this fact.

Take a look at Stanford’s CS 101 https://online.stanford.edu/courses/soe-ycscs101-sp-computer-science-101 and the list of topics covered. Not a single one has anything to do with computer science. Compare those topics to https://en.wikipedia.org/wiki/List_of_unsolved_problems_in_computer_science, and try to figure out how those topics even get you started on the path to figuring out how you might even frame those questions, let along solve them.

Computer science is hard because it’s a branch of symbolic logic and logic is hard.

• "because it’s a branch of symbolic logic". This is the "CS is misspelled math" fallacy. There is much more to CS than that. Nov 24 '20 at 13:35
• @Buffy: yes, there is. But CS isn’t about what an Ethernet cable does. Nov 24 '20 at 23:49
• Hmmm. Given that I taught CS for about 40 years, I understand that and, moreover, what it does include. Nov 24 '20 at 23:52

This discussion may soon be moot.

Consider the following article from the New York Time Tech section:

"Meet GPT-3. It Has Learned to Code (and Blog and Argue)"

https://www.nytimes.com/2020/11/24/science/artificial-intelligence-ai-gpt3.html

That article links to this one: Where an English interpreter writes code on the fly...