4 ms·
If you're really interested in your subject you don't need people telling you what to learn and not to learn. I mean most of University for me was a juggling a
by laichzeit0 13y ago
If you're really interested in your subject you don't need people telling you what to learn and not to learn. I mean most of University for me was a juggling act between doing the prescribed courses and learning things I thought was important because well, it was important, even though it wasn't part of the course.
Like going through Knuth's and Steven's books, or learning assembler, or how to use a debugger, or writing a 3d engine, or implementing some data compression algorithms, etc.
None of these were prescribed but it's kind of intuitive that you should at least know how to do these things if you're studying computer science, I would think?
- deleted 13y ago[deleted]
- Nursie 13y ago>> If you're really interested in your subject you don't need people telling you what to learn and not to learn. You at least need someone to expose you to what is available to learn. It's possible that without guidance a lot of people would never even think of going to the lower levels, they can be nearly invisible to someone working on (for instance) web apps with high level server frameworks and lots JS. When it comes down to it, you need to know what you don't know, and some of the low-level stuff (pointers, memory layouts, stuff...) really ought to be part of CompSci 101. Particularly in a country where pre-university computer education is inadequate or absent. Most UK CompSci folks have mathematical and science backgrounds but no formal education in computer science or programming.
- lelandbatey 13y agoThis is very true, and I can attest to it from personal experience. I grew up in Redmond Washington, in the heart of Microsoft - land, surrounded by programming and programmers. I learned a lot of the mental meta-skills that go hand in hand with programming, but I didn't ever learn to program, even though I thought it interesting and I wanted to understand it. It was a challenge to even know what I wanted to know, and there wasn't anyone around to answer my "but how, and why?" questions to begin learning. It took till I was in college for me to start learning to program, because I had excellent professors who would answer my questions for literally hours. As well, I finally had problems that needed solving (if for no other reason than I needed to turn them in).
- derleth 13y ago> some of the low-level stuff (pointers, memory layouts, stuff...) really ought to be part of CompSci 101. This is forever a balance between the universal constants of the low-level world, and stuff which seems to be a constant but it actually a flavor-of-the-month and will be obsolete by the time you're in a position to apply it. For example, someone taking an architecture course (learn assembly language from the transistor up!) will likely learn on the MIPS, because it's a simple design which fits a simple five-stage pipeline model very cleanly and it has a simple, easy-to-teach machine code ISA as well. Plus, of course, Hennessy and Patterson teach MIPS, so you get to use their well-written book if you do, too. However, spending your time learning how to schedule opcodes to take advantage of a branch delay slot, which is an intrinsic part of the MIPS worldview, is a mistake. No architecture in modern use has them: ARM, PowerPC, and even the venerable Alpha found a way to avoid the concept, and, of course, the x86 has never had them. Branch delay slots are a flavor of the month from decades ago; they're downright archaic today. (DSPs seem to have them. Will they have them a couple generations from now? Are you actually going to learn enough about the other unique features of DSPs to make learning about branch delay slots worthwhile?) OTOH, teaching the theoretical side is a lot closer to being future-proof: Even if certain algorithms get finessed by differences in future hardware design, learning to think rigorously is always a useful pursuit.
- Dewie 13y ago> If you're really interested in your subject you don't need people telling you what to learn and not to learn. And if anyone argues against you, you can just say that they're just not as passionate as you are. Brilliant.
- e12e 13y agoI'd put learning the basics of data normalization ahead of any of your concrete examples. But maybe that's just because I partially fell into/chose that - and would otherwise have followed a rather excellent computer science degree that has no compulsory data normalization stuff... And in general I'd recommend a basic course of statistics for any science degree (as impostant as some basic philosophy, really). Finally I'll just accept that if you're only doing 4-5 years of computer science, no one will be qualified to select which few parts to study without guidance. [edit: spelling]
- roel_v 13y ago"If you're really interested in your subject you don't need people telling you what to learn and not to learn." Only if you don't mind spending 5 year on what could have been done in 1 if only someone had told you what to focus on, where to start looking and every now and then points out some connections that you missed yourself. Of course it's possible to learn the same thing somebody learns in university on your own. Whether you can learn it as efficiently - that's another question.
- cossatot 13y agoI think that the combination of directed coursework and self-study is what a formal education is really about. There is no way a set curriculum can teach you everything that you may need in a dynamic world; you have to learn the curriculum, but you also have to learn what you personally are interested, and you have to learn how to teach yourself. This way you get a solid, wide base but also some specialization/expertise in whatever niche(s) you like, and gives you the tools to advance yourself. It has always frustrated me teaching, when students are unwilling to get out beyond what I or any other teacher tells them. Designing a syllabus makes it very apparent what a minuscule slice of any subject has to be distilled into a dozen lectures or exercises.