The following thread isn't terribly controversial. While new students might not realize this, "computer science" does not teach how to code. Instead, it teaches lots of useful information that coders might need, like O(n) or OS fundamentals.
The reason, I suspect, is that you can't really teach how to program any more than you can teach somebody how to play basketball. Sure, you can instruct them on some basics, but ultimately, it requires personal effort and practice.
If you want to become a professional basketball player, then you have to spend time on the court almost every day practicing until you get good.
If you want to become a professional programmer, then the same.
If you want to become a professional programmer, then the same.
It's not just personal effort. You have to play with other players, learning from them, all the little things. Likewise, if you want to learn programming, you really need other people to bounce ideas off of.
I suppose getting mentored would help. But really, talking to people at your own level is where you'll get the most benefit. Indeed, mentoring those below your level, getting challenged by unexpected questions, may help more than getting mentored yourself.
There's some truth to the following tweet that "computer science is not a science or engineering", but at the same some falseness. It's somewhat science, math, and engineering.
Shannon's information entropy stuff is a good example where "computer science" is absolutely a "science" that helps us understand the nature of the universe.
Likewise, there are lots of places where computer science is a type of math, like big-O notation for algorithmic complexity.
Likewise, computer science and engineering overlap. Software engineering is often not respected as true engineering because people don't die when you make a mistake, but that misses the deeper understanding that it's truly engineering.
The biggest flaw in computer science is that it's decades out of date. The modern curricula was designed around 1980 and hasn't changed much since. It's more like a class in medieval literature than a class in modern literature.
For example, students are still indoctrinated into the RISC religion even though it's been obsolete since 1995 having been replaced by OoO (out-of-order) microprocessors.
My specialty, networking, is even more horrifically out of date. They an't even teach a basic concept like byte-order correctly (big-endian vs. little-endian). Don't get me started on parsers.
My other speciality, security, largely doesn't exist. College textbooks teaching how to build websites with PHP and SQL still instruction students to program in a way that will result in SQL injection.
Software engineering is largely not taught. If you do become a professional programmer, you'll be shocked by the difference between what college taught you and how it's really done in modern silicon valley companies.
No, the 737 MAX problems had nothing to do with software. The entire airplane design was faulty and they tried to patch those faults in software. Then, people blame the software.
The 737 MAX was because they needed larger diameter engines for increased fuel efficiency that wouldn't fit on the older 737 airframe. So they took a hammer and forced them to fit anyway, creating a less stable (more dangerous) plane.
The software behaved exactly as the airplane designers intended. Now they realized what they intended was bad, so change their intentions, and hence, changed the software.
It's one of the things people don't understand about software. There's the "requirements" that state what the software is supposed to do, and the "implementation" how it's engineered to solve those requirements. Software engineering can't fix bad requirements.
Boeing hardware engineers said 'pitch the nose down if the sensor says there's a stall', and the software engineers did exactly that. The crashes were when the hardware sensor failed and gave bad readings to the software.
Obviously, in hind sight, there should be redundant sensors, and easier ways for the pilots to override the software when things go wrong. These are whole system engineering problems, not software engineering problems.
In answer to the following question: there's no good text on "parsers" that I know of. It's one of the reasons why computer science taught in college is broken.
There is a "parsers" course, where they teach you how to use lex/yacc to write a compiler for a programming language, the difference between context free and context sensitive parsing, and other abstract concepts.
It's abstract, out-of-touch ivory tower nonsense, so in the networking class, they toss it all away, and teach you to parse network input in an overly concrete and ad-hoc way. This leads to students being confused by relatively simple concepts like byte-order.
They often teach code like:
x = ntohs(*(short*)p);
Which is wrong, and has been wrong since 1980, but they still teach it because college professors don't have enough real world experience to know it's wrong.
The correct way to teach it should be:
x = p[0] * 256 + p[1];
x = ntohs(*(short*)p);
Which is wrong, and has been wrong since 1980, but they still teach it because college professors don't have enough real world experience to know it's wrong.
The correct way to teach it should be:
x = p[0] * 256 + p[1];
The problem with parsing network input is that you don't get to define the perfect abstract format/language of the input. Instead, if you have to deal with real-world issues. If code generating the data is doing it wrong, you have to decide how you are going to handle it.
Do you go all Postal on the data, being liberal on following the rules, doing your best job to figure out what it means? Or do you become conservative, and deliberately break things, even though it's obvious what the other side intended?
Often times you don't get a choice. For example, your network code has to be compatible with Microsoft and Linux regardless of whatever any official standard states.
This is a common response to such threads, and I don't agree with it. If universities didn't prepare you for your later employment, then nobody but the idle rich would be going to universities.
Universities don't teach you to think. Quite the opposite, they seek to indoctrinate you into the prejudices of the professors. The continued indoctrination of the "RISC" theology is a great example.
Yes, critical thinking is important. No, it's not what they actually teach you in college. Their version of critical thinking is so that you can demonstrate why wrong answers are wrong.
Instead, critical thinking is about being critical of right answers, as in Right™ answers. It's about challenging what everyone knows to be true, or everyone on your own side of the argument believes to be true. It's being critical of deeply held beliefs of your own side.
People claim that tech people need more liberal arts to teach them critical thinking. I took liberal arts. I found the opposite to be true, that liberal arts is full of widespread prejudices that you dare not challenge. I challenged them and got in trouble.
I mean, I got in trouble on both sides. I didn't understand the Thevenin Resistence calculation I was supposed to use, so came up with my own in my experiment, then spent an hour convincing the TA it worked to upgrade my score from an F to a C.
I got a D in my German Culture class because I took it after spending a year in German and kept correcting the teacher, such as the "Zwei Stimme" when voting for parliament.
At least in tech, I could prove I was right, with math or code. In liberal arts, that's not possible, there is no right answer, only answers the professor believes to be right.
