Lots of students switch majors after taking classes in other subjects. Besides, if you laser focus on one specialty, you lose all the serendipity that comes from knowing multiple fields.

I was trained as a mechanical engineer. Yet I write compilers. And yeah, a lot of things I learned from ME have made it into the seemingly utterly different compilers. I see a lot of mistakes SE's make because they are completely unaware of other fields.

> a lot of things I learned from ME have made it into the seemingly utterly different compilers.

Do you mind elaborating on this or providing a link if you've discussed this before?

A couple articles I wrote years ago:

https://www.digitalmars.com/articles/b39.html

https://www.digitalmars.com/articles/b40.html

And one about its influence on compilers:

https://dl.acm.org/doi/abs/10.1145/3386323

I agree. I hated bad professors all throughout my college career. They were the bane of my existence. Especially for the same courses you list and even more for the ones my degree focused on.

These bad professors would take forever to grade, if not that then they would do what you describe and give us irrelevant information and odd spiels about whatever thing was bugging them in the politics world, or maybe even something their dog or cat did the week before that totally delayed them getting us our grades or assignments. I remember in my statistics course the guy spilled coffee all over our written mid terms! How careless.

I, not much unlike yourself would try and find any easy way to get ahead of the curve. Now, a common theme among these bad professors is definitely giving irrelevant information, being lazy, or even completely disorganized to no hope. With all these mistakes, they end up making huge mistakes in their own syllabus. You have no idea how many terrible things these people would do in their own work!

A neat little thing I found that nearly all bad professors do is list the exact material they would cover throughout the course, maybe not always week by week but an overview of the material we would touch on. How silly of them.

That's not even the kicker, these bad professors would even list the exact place where they took things from. Hilarious indeed. It was usually under some strange section called 'Required Course Materials' or 'Recommended for Review'. These suckers couldn't be any worse at their job, practically giving us the answers.

When I figured this out, I started going all in with the cheating. After getting the syllabus I would get this thing and read it from the beginning to the end, trying to cover as much material going topic by topic to be covered in the schedule. I could finish the course in practically 2 weeks, didn't even have to wait for these lectures that were pretty much a waste of time after going through it. By the 3rd bi-weekly lecture, I would have learned the entire course. Those fools never knew what hit them either, I would ace their assignments and finish exams before anyone else. I would even stop showing up to class with how adept I was at cheating. No one even suspected that I was cheating.

I would try and get others to follow my path. They would always ask how I did it, how did I, who really wasn't all that special, or smart, get so many A's. Even in spite of the quality of instruction.

The answer was always the same - read the textbook!

I’m not sure I understand how learning a published syllabus could be qualified as cheating?

It’s a joke.

it's not. reading ahead is never cheating.

Yeah, I agree that if the professors have plagiarized their course materials, then they shouldn’t be disappointed about the students doing the same…

By the way, I don’t think you really cheated (in an academic integrity sense), you thoroughly read the course material to get these grades. You deserve to get these grades since you already know how to study on your own.

… pretty sure OP is sarcasm.

Except for professors who didn't list everything out and had lecture specific material. It's hard for me to believe no one had professors like this when I have friends from places like Stanford and MIT (schools some people would think is filled with all great professors) who can attest to some of their own experiences being like this.

None of what you describe is cheating. At all.

You literally just studied and worked ahead. That is not cheating...

…that's the joke.

statistics is pretty useful in computer science...and as someone has has worked in biotech on the software side...chemistry can be as well. Heck even anthropology and philosophy were pretty relevant when I took my courses on NLP years ago.

As someone with 10 years as a software engineer I haven't needed it.

I’m sure there are 10y SWEs (and 1 yr) that use it every day.

Obviously it’s going to be irrelevant to compilers or something, but not to heuristic approaches or anything with some quantifiable (and actively quantified) nondeterminism.

It will be very relevant in any field that does performance testing. And that includes compilers.

I don't think you need a statistics class to do performance testing.

You change an optimizer pass. Looks good on a microbenchmark. But then you try it out on some samples of real code. Turns out, it probably makes some real code a little bit faster. No difference on other real code, but the data are noisy, so it's hard to tell. And on one piece of code, it seems to actually cause a regression - but again, the data from multiple runs are noisy.

Should you enable the optimizer change by default, or not? Or do you still need to collect more data? How much more data? What data - more runs or more different code samples? How confident do you want to be, and how confident can you be?

These are questions you will face in your real day to day work, and a few statistics courses will be incredibly helpful to you in answering them.

I knew someone would say something like that, but I've never seen that sort of thing done personally and I really doubt lack of statistical knowledge is even close to the biggest obstacle to writing faster software. For micro-optimizations so subtle you need fancy techniques to even tell they work, non-quantitative factors (code impact, will it enable other optimizations, etc.) are more likely to be decisive. Techniques to reduce noise are either non-statistical (warming up caches) or unsophisticated (average many trials, best of three).

The amount of programming jobs (out of all possible programming positions available) that require proper statistics or chemistry for that matter are so low that it doesn't make sense to learn those subjects (in the context of computer science) preemptively. Even if people who take and succeed in subjects like Chemistry who do end up in a job that may use it down the line probably won't remember what they learned anyway.

The jobs don't require it, but the people who are not aware of statistics or chemistry are unable to recognize when it would help them. I.e. it becomes a self-fulfilling prophecy.

(It has nothing to do with "in the context of computer science").

I imagine they'd either have coworkers who are more involved in those domains (if actually needed for the job) who can guide them on the right path or can just google their problems and end up on a path of self-discovery that leads them to those subjects. Prematurely surveying other subjects not pertinent to the job one is going to university in the first place for seems silly in that regard. I'm sure many would rather focus their time on learning more of the things that are shared in the majority of the job market (or at least more things that actually interest them).

You'd imagine wrong. (In my experience.)

For example, in mechanical engineering, I know how to make reliable systems out of unreliable parts. Software engineering is still focused on a hopeless quest to make software perfect. How to do it assuming unreliability has been slowly seeping into software engineering the hard way, bit by bit, over my entire career.

One example: running the brake software on the same computer that is connected wirelessly to the internet.

I have to disagree with that. One obvious example is Google, who made a fabulously reliable and fast machine out of cobbled-together ultra cheap commodity hardware, and conquered the world with it. That was in the 90s, and their way of doing things took over completely. It's why companies like Sun went out of business -- they had the super-reliable (and overpriced) systems, but nobody wanted them anymore.

What you're describing (the brake system) is just simply incompetence.

You're right about how companies managed to scale their internet server farms. But that was late (1990s) and still has not seeped into the rest of the industry.

> What you're describing (the brake system) is just simply incompetence.

I regularly discuss this with people who are convinced they can make such a system secure.

For another example, I frequently advocate on HN for embedded systems to have physical write-enable switches for reprogramming the system memory. This makes it a physical impossibility for malware to infect that memory. Nobody agrees with me. They all think they can write bulletproof code.

I can't buy disk drives with physical write-enable switches, either, not since the 1990s. This is necessary so if you try to restore from a backup drive, you can't make a mistake and overwrite the backup, and the ransomware on your system cannot write to it. This is a regression in the industry.

And yet nobody on HN thinks this is a good idea, because it's inconvenient. Or they'll suggest a software switch, which of course is inherently corruptible.

BTW, the aviation industry gets this right. The stabilizer trim has a physical cutoff switch on all their airplanes, including the 737MAX. Unfortunately, in the 3 incidents of MCAS runaway, only one use the switch properly (and you never hear about that incident). The second never used the switch at all, and the third crew decided to disable the trim system when the airplane was in a non-recoverable dive without using trim. (The electric trim switches also are physical and override the software.)

The number of programming jobs that require statistics is huge though?

The MLE job market is booming.

For that matter the number of programming jobs that require computer science is pretty low.

For a programming job that requires knowledge of chemistry, it's easier to find a chemist who can program. Likewise physics, math, statistics, electronics, etc.

I’d say psychology is a good a thing to know as well.

agree. composition and anthropology were such a waste of time. the composition class was harder than the stem classes though because the teacher was pretty meticulous about writing.

Writing is good for your career as a software engineer.

Writing is how you promote yourself through articles, presentations, etc.

Not at all. Writing entails some creative freedom. It was more like "read this essay and make sure your opinion does not depart too far from the professor's"

I don't bother reading articles by people who can't form a complete sentence. In my experience, there's a strong correlation between bad writing and having nothing perceptive to say.

There are exceptions, but in general, an ability to communicate clearly correlates to an ability to think clearly.

I expected saying that would be unpopular. But I'm hardly alone in this attitude, and so it pays to learn how to write.

Composition can be incredible. It's a blank canvas type course that can be about anything the professor wants as long as they're teaching you to write. My composition class was a passionate introduction to western philosophy. Incredible class. Pedagogical laziness, overly prescriptive syllabi, or lack of creativity make classes like composition bad— not the subject itself.