I once proposed a similar course at a major CS department where I was a junior faculty member. The response was “This is a university, we don't do things like this.” Result: students who couldn't use a debugger, did not know how to use source control systems, did not know how or why to write a shell script. Mostly, students didn't know how to use online help and documentation, leading to superstitious behaviour when doing lab work: “My friend told me to do this, I don't know why it works.” Yes, some of this can come in other course, but it's the first part to be dropped if time runs out. Even though a course like this should count for few if any credits, it is essential: helping students get more out of their other courses should be what is done at a university.
This feels like biblical Pharisees putting ritual cleanliness above practical concerns. The professors see themselves as pursuing higher intellectual goals, but the reality is most of their students want programming jobs, and need to be taught skills that will be essential to those jobs (like using git).
The purpose of universities is to prepare the student for academic research. If you really want a tertiary education that is more focused on practical considerations, at least in Germany there exist Fachhochschulen.
When you attend a university, but you at least want to have the option to get a programming job if you realize that academic research is not for you (which is in my opinion a very good idea considering the job prospect uncertainty in academia), you will of course additionally invest an insane amount of your free time (outside of your academic studies) to learn the necessary skills for this. If you don't do this, don't complain.
This is, again, GP's criticism of purity for its own sake.
I've had to interview people for whom academia didn't work, and they were simply ignorant in terms of real-world skills. Writing a Bash script shouldn't be an hobby pursuit, I'm sure a Master's in CS can spare 6 credits (one course, one semester) to teach Git, scripting, encoding, linting, etc.
Academia-grade code can be much better if you look past the purity of their pursuits.
I've been building up a similar list of topics that nearly every programmer will at some point be forced to learn against their will and which are not adequately covered in undergrad:
* Text file encodings, in particular Unicode, UTF-8, Mojibake
* Time: Time Zones, leap day / seconds, ISO-8601
* Locales, i18n, and local date/number formats
* IEEE 754 floats: NaN and inf, underflow, overflow, why 0.1 + 0.2 != 0.3, ±0, log1p
* Currencies, comma/dot formats, fixed-point decimal representations, and exchange rates
* Version strings, dependencies, semantic versioning, backwards compatibility
There's another list for web/REST developers, and one for data scientists, but this is the core set.
Having colleagues for who this topic is "daily business", I really don't know what you intend to teach about this topic to computer science students:
It's either
- basically trivial: you use the provided exchange rate tables which can vary from day to day; you thus just have to thoroughly pay attention concerning the exchange rates of which day you have to use for a given calculation (but this is something the business people will tell you), the rest is like unit conversion, which you learn in school: If the "exchange rate" between yards and inches is 36 in/yd, then 2.5 yd = 2.5 yd * 36 in/yd = 90 in. Similarly, if the f/x rate that is to be used is 1.1612 USD/EUR, then 2.50 EUR = 2.5 EUR * 1.1612 USD/EUR = 2.903 USD (you now just need to ask the business people whether they want to use this raw result, or the result is to be rounded. In the latter case, they will tell you which kind of rounding they want).
- or it is something that you rather need to become an auditor (or a similar qualification) for.
I just don't want them to design a data model with a single `numeric(10,2)` columns for "sale_price", or hard-code their PowerBI report to show the last five years of data using whatever the exchange rate was on the day they wrote the report. You're right - it could be covered in five minutes, but since we don't currently bother, every junior has to learn it the hard way...
In a wider scope, I’ve always thought there is an entire area on data processing and manipulation that is missing in CS (and CI) curricula. Not just CSV files, but XML, JSON, maybe some HL7, Pivot Tables, today Excel dynamic array formula, SQL and some functional style processing like data structure LINQ. Plus tools for doing processing like RE, grep, sed, maybe even AWK.
Needs to be a module on how to play politics in big corporations. If you don't you'll spend your career watching incompetents breeze ahead of you while being consigned to keeping the ship from going under.
Agreed. I thoroughly went through this before joining my first job and that massively accelerated my onboarding.
I have seen new hires spending lot of time picking up the tools on the job because of lacking fundamentals!
One thing that struck me after doing two database courses was that I didn't know how to do an sql query involving dates. It's a practical thing you'll need pretty quickly in the workplace and date types tend to vary between dbms.
I went through this course in the astronomy department of all places.
This quote is very relevant for my career progression:
>Within a month of his arrival, Randy solved some trivial computer problems for one of the other grad students. A week later, the chairman of the astronomy department called him over and said, “So, you’re the UNIX guru.”
>At the time, Randy was still stupid enough to be flattered by this attention, when he should have recognized them as bone-chilling words. Three years later, he left the Astronomy Department without a degree, and with nothing to show for his labors except six hundred dollars in his bank account and a staggeringly comprehensive knowledge of UNIX.
In the 90s, pretty much all the Math, Physics, EE, etc guys and gals all become software developers or generally worked in IT. There were no jobs in those other areas. Well, Intel was hiring CEs for awhile there. Now there are no dev jobs, either.
Ha. Reading the book again now. My all time favorite.
Neal Stephenson’s Cryptonomicon
A wonderful historical fiction novel with two main timelines, WW2 and the 1990’s, that includes the invention of the first computers, cool as heck battle scenes, adventure love sex music math statistics horror Churchill Turing Goering and wow the wrecked German submarine U553 crashing up and down on an exposed coral reef in the North Atlantic waves.
How do you benefit from reading someone’s mail without letting them know you are reading their mail?
I had a systems programming course that was (I would later realize) basically Kernighan and Pike's Unix Programming Environment followed by Oreilly's Learning Perl.
In my own studies, software engineering was mostly about structurig code, coding pattern such as visitor, singleton etc. I.E how to create a maintainable codebase
My software engineering course was about the software development life cycle, different business methodologies like agile and waterfall, and working in a group.
It was very helpful. I would have appreciated “how to create a maintainable codebase” as well though. “Singleton” was not a part of my vocabulary until 3 years into my career :/
Looking back, I wish it never had been necessary to memorize all those design patterns just to get work done! All OOP has been is a huge distraction and mostly bs. This is me looking back across 30 years of work, so don't just downvote because you love OOP--try thinking about what I'm really saying here. OOP was, to me, an enormous bend in the river that eventually got pinched off and has become a horseshoe lake, destined to dry up and just become a scar on the software engineering landscape. It feels like it was all a big waste of time and someone's money making schemes, tbh.
I understand that you're goal is getting home. It might be helpful for other viewers to share 1) a bit more about your story and 2) how them using the service helps.
Maybe people can help in other ways you don't anticipate.
I once proposed a similar course at a major CS department where I was a junior faculty member. The response was “This is a university, we don't do things like this.” Result: students who couldn't use a debugger, did not know how to use source control systems, did not know how or why to write a shell script. Mostly, students didn't know how to use online help and documentation, leading to superstitious behaviour when doing lab work: “My friend told me to do this, I don't know why it works.” Yes, some of this can come in other course, but it's the first part to be dropped if time runs out. Even though a course like this should count for few if any credits, it is essential: helping students get more out of their other courses should be what is done at a university.
I agree this shouldn't be part of the curriculum and instead be extracurricular, which my understanding this course is at MIT.
This would be more appropriate to fit in a curriculum of a vocational IT course or bootcamp.
This feels like biblical Pharisees putting ritual cleanliness above practical concerns. The professors see themselves as pursuing higher intellectual goals, but the reality is most of their students want programming jobs, and need to be taught skills that will be essential to those jobs (like using git).
The purpose of universities is to prepare the student for academic research. If you really want a tertiary education that is more focused on practical considerations, at least in Germany there exist Fachhochschulen.
When you attend a university, but you at least want to have the option to get a programming job if you realize that academic research is not for you (which is in my opinion a very good idea considering the job prospect uncertainty in academia), you will of course additionally invest an insane amount of your free time (outside of your academic studies) to learn the necessary skills for this. If you don't do this, don't complain.
This is, again, GP's criticism of purity for its own sake.
I've had to interview people for whom academia didn't work, and they were simply ignorant in terms of real-world skills. Writing a Bash script shouldn't be an hobby pursuit, I'm sure a Master's in CS can spare 6 credits (one course, one semester) to teach Git, scripting, encoding, linting, etc.
Academia-grade code can be much better if you look past the purity of their pursuits.
These skills are also useful for reproducible computational research
I've been building up a similar list of topics that nearly every programmer will at some point be forced to learn against their will and which are not adequately covered in undergrad:
* Text file encodings, in particular Unicode, UTF-8, Mojibake
* Time: Time Zones, leap day / seconds, ISO-8601
* Locales, i18n, and local date/number formats
* IEEE 754 floats: NaN and inf, underflow, overflow, why 0.1 + 0.2 != 0.3, ±0, log1p
* Currencies, comma/dot formats, fixed-point decimal representations, and exchange rates
* Version strings, dependencies, semantic versioning, backwards compatibility
There's another list for web/REST developers, and one for data scientists, but this is the core set.
What'd I miss?
> * Currencies, [...], and exchange rates
Having colleagues for who this topic is "daily business", I really don't know what you intend to teach about this topic to computer science students:
It's either
- basically trivial: you use the provided exchange rate tables which can vary from day to day; you thus just have to thoroughly pay attention concerning the exchange rates of which day you have to use for a given calculation (but this is something the business people will tell you), the rest is like unit conversion, which you learn in school: If the "exchange rate" between yards and inches is 36 in/yd, then 2.5 yd = 2.5 yd * 36 in/yd = 90 in. Similarly, if the f/x rate that is to be used is 1.1612 USD/EUR, then 2.50 EUR = 2.5 EUR * 1.1612 USD/EUR = 2.903 USD (you now just need to ask the business people whether they want to use this raw result, or the result is to be rounded. In the latter case, they will tell you which kind of rounding they want).
- or it is something that you rather need to become an auditor (or a similar qualification) for.
I just don't want them to design a data model with a single `numeric(10,2)` columns for "sale_price", or hard-code their PowerBI report to show the last five years of data using whatever the exchange rate was on the day they wrote the report. You're right - it could be covered in five minutes, but since we don't currently bother, every junior has to learn it the hard way...
CSV/Delimited file format management, for sure. (Reading, writing, choice of field/record delimiters, escaping, working with Excel's CSV quirks, etc.)
In a wider scope, I’ve always thought there is an entire area on data processing and manipulation that is missing in CS (and CI) curricula. Not just CSV files, but XML, JSON, maybe some HL7, Pivot Tables, today Excel dynamic array formula, SQL and some functional style processing like data structure LINQ. Plus tools for doing processing like RE, grep, sed, maybe even AWK.
> IEEE 754 floats: NaN and inf, underflow, overflow, why 0.1 + 0.2 != 0.3, ±0, log1p
High school AP computer science had this in the 90s.
This was covered in my computer architecture class, which was mandatory for my CS degree.
Good list. Versioning is hugely important in practice. I'd add:
* Similar to encodings and locales: Variation in line endings, path separators, command line quoting, case sensitivity
* OS and language-specific package management
* CI/CD
* VMs, containers
* Licenses
Previously:
The Missing Semester of Your CS Education (2020) - https://news.ycombinator.com/item?id=41125733 - Aug 2024 (16 comments)
The Missing Semester of Your CS Education (2020) - https://news.ycombinator.com/item?id=34934216 - Feb 2023 (336 comments)
The Missing Semester of Your CS Education (2020) - https://news.ycombinator.com/item?id=27154577 - May 2021 (185 comments)
The Missing Semester of Your CS Education - https://news.ycombinator.com/item?id=22226380 - Feb 2020 (196 comments)
Needs to be a module on how to play politics in big corporations. If you don't you'll spend your career watching incompetents breeze ahead of you while being consigned to keeping the ship from going under.
> Needs to be a module on how to play politics in big corporations.
It's a strange game. The only winning move is not to play.
If your manager is from India and you are not, you don't have a prayer.
I liken my career to having a tiger by the tail. Also use the "knife fight" analogy.
I didn't understand a single sentence. Can you clarify why an Indian manager leaves you without prayers?
Loved it when I went through the course. Deserve an update now.
Agreed. I thoroughly went through this before joining my first job and that massively accelerated my onboarding. I have seen new hires spending lot of time picking up the tools on the job because of lacking fundamentals!
As in some other comments, this is usually done in Software Engineering degrees.
One thing that struck me after doing two database courses was that I didn't know how to do an sql query involving dates. It's a practical thing you'll need pretty quickly in the workplace and date types tend to vary between dbms.
I had this course. I can’t remember what they called it. But a very enthusiastic guy in shorts taught us how to use Linux, the command line, git, etc.
I went through this course in the astronomy department of all places.
This quote is very relevant for my career progression:
>Within a month of his arrival, Randy solved some trivial computer problems for one of the other grad students. A week later, the chairman of the astronomy department called him over and said, “So, you’re the UNIX guru.”
>At the time, Randy was still stupid enough to be flattered by this attention, when he should have recognized them as bone-chilling words. Three years later, he left the Astronomy Department without a degree, and with nothing to show for his labors except six hundred dollars in his bank account and a staggeringly comprehensive knowledge of UNIX.
In the 90s, pretty much all the Math, Physics, EE, etc guys and gals all become software developers or generally worked in IT. There were no jobs in those other areas. Well, Intel was hiring CEs for awhile there. Now there are no dev jobs, either.
Ha. Reading the book again now. My all time favorite.
Neal Stephenson’s Cryptonomicon
A wonderful historical fiction novel with two main timelines, WW2 and the 1990’s, that includes the invention of the first computers, cool as heck battle scenes, adventure love sex music math statistics horror Churchill Turing Goering and wow the wrecked German submarine U553 crashing up and down on an exposed coral reef in the North Atlantic waves.
How do you benefit from reading someone’s mail without letting them know you are reading their mail?
Agreed. If you love it, also read the Baroque Cycle, REAMDE, and Fall. Cryptonomicon is the best but it all fits together.
I had a systems programming course that was (I would later realize) basically Kernighan and Pike's Unix Programming Environment followed by Oreilly's Learning Perl.
I advocated heavily for the introduction of something like this at my former institute. They didnt bodge sadly.
It‘s called software engineering.
In my own studies, software engineering was mostly about structurig code, coding pattern such as visitor, singleton etc. I.E how to create a maintainable codebase
My software engineering course was about the software development life cycle, different business methodologies like agile and waterfall, and working in a group.
It was very helpful. I would have appreciated “how to create a maintainable codebase” as well though. “Singleton” was not a part of my vocabulary until 3 years into my career :/
> “Singleton” was not a part of my vocabulary until 3 years into my career :/
If you are a more old-school style programmer, you simply use the older term "global variable". :-)
Looking back, I wish it never had been necessary to memorize all those design patterns just to get work done! All OOP has been is a huge distraction and mostly bs. This is me looking back across 30 years of work, so don't just downvote because you love OOP--try thinking about what I'm really saying here. OOP was, to me, an enormous bend in the river that eventually got pinched off and has become a horseshoe lake, destined to dry up and just become a scar on the software engineering landscape. It feels like it was all a big waste of time and someone's money making schemes, tbh.
[flagged]
I understand that you're goal is getting home. It might be helpful for other viewers to share 1) a bit more about your story and 2) how them using the service helps.
Maybe people can help in other ways you don't anticipate.
The author previously posted this to HN, where he tells a little of the backstory from his POV. Make of that what you will:
https://medium.com/@rviragh/tech-whistleblowers-handbook-d40...
[flagged]
Why are you not home?