4 ms·
“In other words, it’s easier to learn the fundamentals and then the high-level tools, rather than the high-level tools and then the fundamentals.” This is how
by alasdair_ 6y ago
“In other words, it’s easier to learn the fundamentals and then the high-level tools, rather than the high-level tools and then the fundamentals.”
This is how a lot of school works and I hate it - they teach the abstract, generalized case first and only later do students apply it. They seldom get the experience of working through a practical problem like “my code runs like dogshit when n is a million” and then learning big-oh when it has context.
I need to know why I should care about something to learn it properly - I need concrete motivation. Otherwise.the lesson is just a bunch of facts, as dry as memorizing a phone book.
I generally prefer to tinker first, then learn theory and I’m fairly sure I’m not alone in this.
- superbcarrot 6y ago> Otherwise.the lesson is just a bunch of facts, as dry as memorizing a phone book. Not in my experience. It's a system of interconnected pieces that often build on each other. With each piece you usually get some justification and relevant problems to solve. That's very far from being just a list of facts to memorize.
- wagslane 6y agoI like this take. I would say "learn the fundamentals first, but within the context of the applicability"
- md_ 6y agoI'm quite similar. But I'm not sure a good CS curriculum has to be like that. One of the neat things about most applied CS is that you can teach it hands on, with minimal equipment. Even more, you can teach it using "toy" or "educational" examples—Minix instead of a "real" OS; algorithms in Lisp or Haskell instead of Java and JS. I went to one of those universities that taught all the freshmen classes in an obscure language, and that bounced between different languages and platforms throughout the curriculum. While plenty of students complained about not learning immediately marketable skills, I thought this was great--it cut down to size the kids who thought they knew it all because they could get by with common tools; it abstracted the problem space a bit to be more of an exemplar (but, to your point, an applied example); and it stressed the importance of knowing _how_ to think, not just how to use one particular tool.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- rubicon33 6y agoYou are definitely not alone and I feel robbed of a good education because educators taught to the other 50% - people who could just absorb random facts like a robot a regurgitate them onto a test. I learn best when I have context, and a reason to learn.
- Jtsummers 6y ago> I need to know why I should care about something to learn it properly - I need concrete motivation. Otherwise.the lesson is just a bunch of facts, as dry as memorizing a phone book. What schools teach CS101 this way? At mine, the first course was taught with pseudocode so I can't say that was different than your description (but they dropped it after my year and went to Scheme and then Python, not sure what they use now). But the 2nd and 3rd courses had assignments where they threw absurdly large inputs at the program to demonstrate deficiencies in algorithms and data structures at different scales. In the 3rd course, this included not just "theoretical" issues around big-O, but also practical issues with how memory and CPU cache work (access patterns of multi-dimensional arrays in nested loops, in particular), where you were still doing a O(n^2) algorithm but just changing which loop referenced which index led to a noticeable improvement in performance.
- jerf 6y agoI like to express this as "it's hard to teach people the solution to a problem they don't have". I think it's a major problem in a lot of educational endeavors, including a lot of things like git tutorials. I think the educational ideal is something more like: 1. Teach how to do something specific, e.g., "here's how to write a simply dynamic web page in Python". 2. Once they've done that, guide the student into a problem, e.g., "what if the user puts a <script> tag in their username". 3. Solve the specific problem (encoding user input properly). 4. Now, contextualize that problem in the broader space. ("this is a pervasive problem in protocols, let's talk about parsing theory and show the mathematical way in which this is fundamentally ambiguous".) 5. Finally, show another instance of the problem to show that #4 wasn't just an academic thing ("remember the $NEWS_ARTICLE about $BAD_PROBLEM? That was a similar encoding problem only in email instead of HTML"). I think pretty much all those steps are important, all the way out to #5. You can tell #5 is often not done by how many people manage to walk out of a 4 year computer science or software engineering education convinced they've learned nothing of value, because none of the actually-quite-substantial amount of stuff they've learned was contextualized properly.
- GormanFletcher 6y agoDuring college I got to see both sides of this play out. I started out majoring in Computer Engineering, an embedded systems oriented curriculum. They started us with assembler, then C, and worked our way up. I switched over to Computer Science, which came from the other direction: Java, then C, then assembler. I learned in myself and saw in my peers that both ways can work great, just for different people. I struggled to understand how to apply C's pointers and memory management in homework without the context of how that fit into solving a problem in a program, because we hadn't yet written code that really did anything, just one-off tiny functions that demonstrated a mechanic without any purpose. Class tests felt like writing an essay about the applicability of the 4x2 Lego brick without having ever assembled a Lego set. I needed top-down learning to grasp the "why" before I could tackle the "how". Some peers expressed the same difficulty as me, but others commented that they found their Computer Science courses challenging until they dug deep enough to understand the underpinnings of the computer. They struggled with their Java courses, but got much more confident once they progressed to C and then assembler, because all the unexplained high-level incantations suddenly started making sense. Over my career, and in my hobbies, which of these approaches I need has come to vary depending on the task. When I'm learning a new way to do an old thing, I jump straight for the bottom-up information. If I'm learning something totally new, I still need to go top-down.
- sponaugle 6y agoVery interesting. I find myself in the other camp, where learning the underpinnings is by far the fastest way for me to use something. This is a good demonstration that there isn't a single best way to teach. Very cool.
- loukrazy 6y agoI remember I only understood C once I wrote a memory allocator in assembly in my Computer Architecture course
- hellbannedguy 6y agoIt’s too bad college curriculums weren’t a mix of abstract, and practical. Yes, many claim they are, but we all know the truth. I look back on my college days, and had maybe 8 classes that were actually useful, and that’s being generous. Yes, I was a STEM major. I liked the idea of Bootcamps, but the quality is so spotty. I look back at my instructors in college, and if not for that 10 year, so many were basically useless windbags. Zero practical knowledge, or if they had it kept it secret. Computers, and a Programming, is still so new that a determined student can possibly do so much more than the guy who’s just taking classes because they feel it’s a safe career. (That last paragraph only applies to guys under 35 though. I have never seen such ageism in any industry, with maybe the the exception of porn.)
- the_only_law 6y agoThe programs I’ve seen that try to do this almost always end up with the worst version of both.