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.
Do you mind elaborating on this or providing a link if you've discussed this before?
https://www.digitalmars.com/articles/b39.html
https://www.digitalmars.com/articles/b40.html
And one about its influence on compilers:
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!
You literally just studied and worked ahead. That is not cheating...
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.
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.
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.
(It has nothing to do with "in the context of computer science").
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.
What you're describing (the brake system) is just simply incompetence.
> 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 MLE job market is booming.
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.
Writing is how you promote yourself through articles, presentations, etc.