5 ms·

Yeah I don't agree with that at all. That's like saying mechanical engineers should all learn starting with hammers and nails. Computer Science isn't about the

Yeah I don't agree with that at all. That's like saying mechanical engineers should all learn starting with hammers and nails. Computer Science isn't about the tools! C/C++ nano/emacs are tools only, and mostly outdated tools used less and less by most companies. Most professional software engineers starting today are not using these tools, they are using Java, C#, Javascript, Swift, using IDEs. 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#.

LogonType10 5y ago
Do you think the only purpose of a CS degree is to teach software development? Many people with the degree don't end up writing software. The point of a CS degree isn't to teach you the tools and languages being used at companies in 2021; go to a coding bootcamp if you want that. It's to teach computer science. After you learn that, picking up languages and tools is easy. 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.
- vkou 5y ago
  > Do you think the only purpose of a CS degree is to teach software development 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.
- ozim 5y ago
  I agree that purpose of CS degree is not to teach any tool. 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.
- KronisLV 5y ago
  > The point of a CS degree isn't to teach you the tools and languages being used at companies in 2021; go to a coding bootcamp if you want that. 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... For example, in the university, when talking about designing systems we might cover the 4EM model and various aspects of planning, but where are the practical examples of systems that have succeeded because of these practices, how in particular the models translate to good implementations in practice, or quite on the contrary, what are the most typical mistakes that one can make (e.g. splitting up the system wrong and ending up with really chatty services). Case studies and post mortems would be exceedingly useful in that regard. 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.

LogonType10 5y ago

Do you think the only purpose of a CS degree is to teach software development? Many people with the degree don't end up writing software. The point of a CS degree isn't to teach you the tools and languages being used at companies in 2021; go to a coding bootcamp if you want that. It's to teach computer science. After you learn that, picking up languages and tools is easy. 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.

vkou 5y ago
> Do you think the only purpose of a CS degree is to teach software development 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.
ozim 5y ago
I agree that purpose of CS degree is not to teach any tool. 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.
KronisLV 5y ago
> The point of a CS degree isn't to teach you the tools and languages being used at companies in 2021; go to a coding bootcamp if you want that. 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... For example, in the university, when talking about designing systems we might cover the 4EM model and various aspects of planning, but where are the practical examples of systems that have succeeded because of these practices, how in particular the models translate to good implementations in practice, or quite on the contrary, what are the most typical mistakes that one can make (e.g. splitting up the system wrong and ending up with really chatty services). Case studies and post mortems would be exceedingly useful in that regard. 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.