If a student can't handle C/C++ in nano/vim/emacs and debugging with gdb, maybe a computer science degree just isn't right for them.
Also, learning Computer Science has very little to do with programming language or tools. Computer Science is a Science (it's in the name). You can learn about logic, grammars, discrete math, computational complexity etc, without knowing anything about Java or C#.
The point with learning with simple tools is that you learn from first principles with as much as possible stripped down. Most of the time C has a straightforward correlation with the instructions emitted by the compiler, and the language rarely does something behind your back. Try explaining memory management (in detail) to a first year student using JavaScript or Python.
It is to teach a person how to learn and how to approach problems. If someone does not get it then yes bootcamp will be better for him.
Thought experiment: so where's the degree for people who want practical and applicable skills and an in depth knowledge of actually building systems with the modern tools that are popular within the industry, as opposed to just being familiar with the theoretical aspects? Surely you'll agree that a bootcamp is in no way equivalent to a degree of any sort (due to time constraints in most cases, the very concept means that you won't get 4-5 years of material's worth), nor do the current degrees actually focus on the practical aspects that much.
After getting a Bachelor's and then a Master's in CS, i still feel that the degrees left me unprepared for software development in the industry, since a lot of the things that i learnt while working within a company in parallel wasn't covered at all! And surely we can't expect people to gradually pick up all of the tools and practices as they go along, because not everyone is going to end up in companies that follow the best practices?
Some examples of things that i feel weren't covered enough:
- organization: issue management systems, versioning policies, team organization (silos vs open communications) and other management aspects
- organization: release management, ways of shipping software (public repositories of various sorts, using SFTP servers, container registries etc.)
- practical system design: when to use SOAP, REST, gRPC, GraphQL or others
- practical system design: the tradeoffs of event based systems, distributed systems, what happens when you have message queues, other ways of dealing with backpressure
- practical system design: more about horizontal scalability and how to achieve it, versus vertical scalability as well as eventual consistency/single source of truth
- practical system design: how to do DDD properly and work with bounded contexts, to split systems into logical chunks
- security: talking more about permission management, ACLs, as well as encryption algorithms and systems for managing credentials (e.g. Vault) and identities/permissions (e.g. OAuth2)
- security: talking more about VPNs, tunnels, encryption, service meshes, observability/auditing, intrusion detection etc.
- development: how to efficiently use all that IDEs offer you and how to work with large legacy codebases while limiting the impact of everything breaking, like in the book "Working Effectively with Legacy Code"
- development: proper testing, not just saying that tests are important and giving vague examples of unit testing, but a course that would focus on nothing but the many ways of testing, everything from unit tests, integration tests, browser automation, performance testing and getting to 100% test coverage whilst also ensuring that no CI steps pass when it falls below that
- development: speaking of which, CI should also be covered more, everything from Jenkins, to GitLab CI, GitHub Actions, the benefits of all of these, as well as the tradeoffs that are there, how to setup your project's build steps and tests in a fully automated way
- ops: how to manage servers, use something like Chef, Puppet or Ansible, install packages, properly configure permissions and a bit more about all of the POSIX cruft that has accumulated over the years and that you'll have to deal with as well as everything from creating systemd services properly, to navigating the filesystem
- ops: using log shipping systems (like Graylog), monitoring systems for the servers (like Zabbix), performance monitoring systems for the applications (like Skywalking APM), analytics systems (like Matomo)
- and so on...
Yet, the current outcome is that people learn a lot about theory and two people with similar knowledge in that regard might have wildly different outcomes overall, because one of them would get to work in a company that follows best practices and lets them learn a lot of new things, whereas the other ends up in a body shop where their knowledge is silo'd and they can't learn much, instead just writing code to meet the business goals.
Perhaps universities fail at doing this, because they're not even trying to - since apparently the industry moves too fast for them to maintain a relevant curriculum. But if that's the case and we as society value formalized education, what other approach would let me learn about all of the above and more, even the concepts and practices that i'm not aware of? It feels like we're still stuck in the medieval approach of "guilds", where people are handed over to those more knowledgeable (senior devs & teams) and learn by doing, which has certain tradeoffs and perhaps isn't the best approach overall.
Many European countries have a two-tiered system of higher education. There are research universities that teach both theoretical subjects (such as CS and history) and research-based applied subjects (such as medicine and law). Then there are vocational universities where the teaching focuses on more immediately applicable skills.
The drawback of a system like that is that people generally consider degrees from research universities more prestigious. As a result, research universities can be more selective with their student intake and their graduates have better employment prospects.
Also, when we are talking about degree-based education, the focus should always be on what is needed 10-20 years from now. The delay from making decisions to getting a nontrivial number of graduates to positions where they are ready to contribute is easily a decade. When there are more immediate needs, the industry has the responsibility to provide the necessary education.
Sounds like a software engineering degree to me.
- Professional Master Degree in Computer Systems and Qualification of Programming Engineer
- Bachelor Degree Of Engineering Science in Computer Control and Computer Science
The curriculum was too slow to move otherwise, at least in my opinion - i guess that their way out of that situation is having the "Professional" degree, which requires you to do case studies and spend months working in an actual company, which in my case was just continuing to work at the company that i was already working at during my Bachelor's, which sort of reminds me of the guild/apprenticeship systems that i mentioned previously.
I might be wrong, but the balance between theory and practice ends up at an impasse often. Maybe degrees should just take longer to complete and cover things more thoroughly? Or do we as a society expect them not to be enough to make someone ready for working in the industry, and accept that as something normal?
No, it's not. But it's purpose is almost certainly not teaching people how to use CLIs.
None of those CLIs have a lick to do with the 'not writing software' parts of CS. They are an implementation detail, that either helps you solve a particular problem, or get in the way. Most of the time in the undergraduate curriculum, they get in the way.
Perhaps though the root of these endless discussions seems to be that the name of the degree means different things to different people.
Some see that degree as a way to learn programming, some see it as a route to a doctorate, ultimately to a career in theoretical science, some see it as understanding how hardware works, and so on.
Ultimately since schools, and students, have such a wide interpretation of the term, making blanket statements in any form about compurt science education is always both right and wrong depending on context.
OP wasn't saying "you can't pass the designated curriculum of a CS degree without this arcane knowledge", they were saying you shouldn't pursue it in the first place. There are many reasons to pursue a CS degree, therefore there are many different situations you'd need to evaluate their statement on. It's quite ambiguous.
It's perfectly easy to learn to write simple programs using a text-editor and a command-line. If that's too challenging, please stay away from production code!
There's an approach to teaching that's been referred to as "circular learning" - the first time around, you cover most of the basics, then you go around again, deepening your understanding - lather, rinse, repeat. "Spiral learning" is probably a better term. It does require the curriculum to be somewhat integrated, though - not just a bunch of independent, standalone modules.
Like, you can't learn to program without some understanding of computer architecture. It's very helpful when learning computer architecture to have some programming skills. But you get taught these things in separate, supposedly-standalone modules that don't reinforce one-another.
Having already some experience with other similar but simpler things will enable the students to pick up later on those more advanced things more quickly with less effort, and especially with much less pain.
Also things become simpler to teach as more background is already know to the students. Needing to explain "everything" at once is not a simple task. This will cause a lot of confusion usually as people don't have yet the proper mental models to sort things into. It becomes harder to actually teach things.
My point is: Lessons in itself shouldn't be "the worthiness test".
The goal is to teach people programming, not torture them. You can test and verify the understanding of the things taught in the next step.
Also it's in general much simpler to teach things along a structure where you go form the big picture gradually down to the details instead the other way around — otherwise people may not see the forest for the trees for a long time. Needing to much details only to get basic things going will cause confusion and a lot of unnecessary frustration in my opinion.
I started years ago with C++ in HS with Codeblocks and felt like this is painful environment to operate, getting external libraries felt like I needed to copy files manually from the internet; idk whether I eventually figured it out
because then somebody showed me C# and I quickly realized how it makes my life 10 times easier just due to allowing me to focus on actual problem solving instead of fighting with obscure language at its ancient version with probably some random compiler and random IDE cuz in CPP world there's many versions of everything with its own quirks. Bonus points when I have to compile LLVM and it takes 30min and eats whole avaliable RAM where compiling .NET's Roslyn is order of magnitude "cheaper'
Thus, dealing with CPP's "weaknesses" is not a good proxy on your performance during your engineering or master's degree in comp sci.
Let alone that computer science ain't school of programming or using X debugger, it's mostly math and theoretical informatics
2. You're mixing "low-level tools" and "ancient user interfaces". An argument could be made that a student should understand low-level tools, just like a mechanical engineer should understand physics. But there is absolutely no argument to be made for using old-school UIs the same way there's no reason for an engineer to use compasses and rulers instead of CAD. Actually, even that makes more sense, because there might be situations where they won't hve anything else, like in the field. There is no situation where the average programmer would only have access to CLIs.
3. CompSci !== SWE. A CS student developing novel learning-based image processing methods has no need for knowledge of obscure gdb commands and C++'s pointer and dependency voodoo. A SWE student could benefit from that knowledge, but even then, will rarely need more than a surface understanding of it when not actually developing using those tools.
It was fairly typical for me to have SSH-only access to the production/staging server and no other tools than Vim/git to alter/store its configuration.
Not to mention you probably shouldn't be doing that directly in the first place, especially as "just" a programmer. Sysadmins need to deal with CLI stuff, but programmers generally have no reason to. Of course many of us have both of these roles, but that's beside the point. As programmers, we should not even need to see the production server and as sysadmins, we shouldn't need to know things like gdb and proper development in CLI editors.
We have the tools, we just don't use them. How many issues from bad edits in remote scripts could've been prevented if we used an IDE with linting via sftp instead of barebones vim?
Absolutely not always. The SSH may be provided through multiple proxies by a mess of convoluted Bash scripts. Because reasons or compliance or whatnot.
> Not to mention you probably shouldn't be doing that directly in the first place, especially as "just" a programmer.
Yeah, if you have a dedicated sysadmin to start with, and not just a team of five-ten-fifty enthusiasts who are fully comfortable with managing servers themselves.
> How many issues from bad edits in remote scripts could've been prevented if we used an IDE with linting via sftp instead of barebones vim?
Yeah, that would be wonderful.
Mastering vim/git/cli has been the most productive thing I've learnt as a software engineer. It's something I would recommend. Not to freshman student but at some point
I guess you could argue that AlexNet was the product of one very motivated CS student who was very proefficient with C++ and CUDA. This particular skill set had a very deep impact on the computer vision community. Today, how ever, you don't need it because all that has been abstracted away. But someone had to lead the way.
The best progress happens when you have both of these groups, not just one. As well as some application development plebs like myself (jk) to allow end users to benefit from all of that progress.
I did the slog part before I went to university, but there were people who, at the age of 21, decided to try CS, and did the intro courses. Thank goodness for Eclipse, that an English major can feasibly learn enough in a semester not to back out.
Not everyone wants to Go Build Real World Programs, either. Please let’s not raise the bar to exclude anyone who isn’t already and won’t soon be hooked up to a terminal speaking in tongues and reciting the fast inverse square root incantations of their forebears.