I’ve seen a lot about transferable skills recently for reasons. I wonder why we still teach so many subjects that aren’t really relevant in the modern day regardless. Since a lot of the skills we’re trying to impart are irrelevant of the actual subject being chosen, why study English and not law? Why study biology and not first aid? Why study geography and not economics? History vs politics, physics vs engineering, etc etc etc
These suggested replacements are mostly applied versions of the more general topic. My point is just that since we’re teaching transferable skills like critical thinking and communication and planning, why not teach specific skills too you might use while we’re at it?
I assume the gut reaction of most people is to reject this because typically people dislike subjects the less “pure” they are. I feel like there are two actual arguments against this apart from just this feeling.
The first is that teaching applied subjects requires prior knowledge of the pure versions. I’m not sure about this. There are skills that you’d rely on to interpret the new subject, which you learned in the old subject. I feel like the skills could also be taught in the new subject, without the old subject at all. However it might be a more patchy and inefficient education. For instance, I feel like maths should still be taught since it comes up everywhere (but also almost all the maths I ever did has come up in physics or computer science too, so I could have just learned that). If it comes up everywhere perhaps I could have learned it there instead.
The second good objection might be that it’s simpler to start at the basics and work your way up through the complexity. This is probably completely correct. However, if we can’t find a way to skip over sections of learning, we will one day find that you can only teach humans so much of the total sum of human knowledge before they are 18. If we advance beyond that point as a society, then we will never be able to educate anyone beyond there. So really I feel like we have to tackle the problem of making complexities feel like basics. Having said that, this might mean simply skipping parts of the subject instead of teaching a different subject entirely.
Then there’s the whole argument that the basics and history are fundamental parts of the subject that you need in order to work any further in with it. This is probably true. I can’t think of any good examples where not teaching the basics is the better option.
So if you think you can deal with these two counter arguments, I’m interested.
So apparently when it comes to coding, I really really learn by doing. I've been having trouble lately paying attention to written tutorials (Chris Pine, the ruby intro on Socrates) because I'll read something, think "Oh, that makes sense," and then somehow not bother to store it, because somehow my brain doesn't think things that make sense are worth remembering. Because I can always understand them again later, right?
Except you don't need to just be able to understand code. You need to be able to SPEAK code. If I want to ask a computer to make me a sandwich, I need to know how to put words together to make myself understood. In programming, like in life, you don't want to be that awkward tourist with a phrase book. You need actual fluency, or you'll be stuck always eating ham sandwiches because you don't know how to ask for roast beef.
So instead of reading through tutorials and not internalizing information, I've basically been banging things together like a baby with one of those shape puzzles. Coding challenges really seem to turn my brain on, so I've been doing a lot of those--the ones on Socrates, problems from hack nights, random things I make up myself--and just seeing what comes out. And a lot of the time what comes out is kind of ridiculous.
This is good in a lot of ways--I'm getting a lot better at using Ruby docs, and googling things when I don't understand. I'm also getting acquainted with a lot of different Array/Hash/String methods. But since I'm basically banging on things until my code passes, and often not really planning logically, this frequently leads to a lot of weird and inefficient ways of doing things.
For instance, this morning I was writing a method to return the longest string out of an array of strings. For some reason--I think because I had recently been thinking about how I was bad at hashes, and how it's nice to have key-value pairs explicitly associated, rather than depending on the index not changing with the order of the array--I decided to use a hash. Note that this decision actually has very little to do with the best way to solve the problem.
First of all, what in the world am I doing? There is an entire ternary in there devoted just to making my output match what Socrates wanted (a string, or nil of the input array was empty). First of all, that should be a sign that I'm probably not doing it in the way the tutorial expected (i.e. the logical way). Second of all, I'm using join to turn a single element array into a string. There is nothing to join! There's only one element! But join is an array-to-string method that I recently learned, and so I used it. Similarly with ternary statements; they're shiny and it worked, so I used one.
A better way to do that last line, without abusing flow control and the join method, would be to just do this:
string_length.keys.last
Then let's think about what I am using that hash for. I need a method to sort an array with respect to an attribute of its elements. I was using a hash because I wanted to associate each element and its length attribute explicitly before I sorted it (since sorting things destroys the order in the array and if I just used a second array to sort my attributes I would then have no way of knowing which element a particular attribute was originally associated with it). But I still need to convert my hashes back to key and value arrays at some point, because sorting is an array function, as is max (I think anyway--can you take the max of a hash? what would that look like?), and I need one of these for certain.
You can tell also that I'm using kind of a random walk method of solving this problem, instead of breaking it up into logical steps that flow from one to the next. It's basically like I have no idea what I'm doing, but I know I need to do this one thing, and it would be nice if I had this, and once I have that I can do this other thing, and eventually through enough iterations of "what gidget is missing?" I end up with code that passes.
So oh well, my code is a little ugly, but it works, so I submit it to Socrates. And then I get to see what everyone else did! And nooooobody else used hashes, because as you will note from above, that's a lot of work. Instead, lightbulb! Array#sort can take a block! And so can Enumerable#max! And, even more weird-looking, you can chain methods even if one of your earlier methods took a block! Which actually totally makes sense, and I will now exploit this everywhere. Probably unnecessarily, until I have mentally beaten that concept to death and fully internalized it.
So, here is the way better method for doing this:
def longest_string(array) array.sort{ |a, b| a.length <=> b.length }.last end
And here is (I think) the best way of doing this:
def longest_string(array) array.max{ |a, b| a.length <=> b.length } end
So yay!
However, I will give myself some credit, because my original code (an earlier iteration, which didn't pass with Socrates because the output was an array), while ugly, is in some ways I think superior to even the prettiest method above. Because my goofy hash method that outputs an array, unlike the above, can deal with MULTIPLE STRINGS OF LONGEST LENGTH.
A long listen, but it's a peek behind the curtain at Dev Bootcamp, Wizard of Oz style. Some interesting reflections on the theory of learning/teaching and how to do it effectively.
Blogging regularly is, I think, going to be a goal of mine throughout this journey, or at least during the prep period. Seems to keep me honest, and if a whole bunch of boring blog posts are what it takes to get me to accomplish things, then oh well, the world will just have to suffer through it.
So yeah. I am continuing on my epic quest of note-taking! I had the unsettling realization last week that I have forgotten almost everything I ever knew about hashes. (Which was admittedly not a lot, but it sure would have come in handy when I was staring down Ex. 38 in Learn Ruby the Hard Way.) Thus I have launched a note-taking initiative, with the goal of creating my own personal ruby reference. And then I will NEVER FORGET ANYTHING EVER AGAIN. Or if I do, it won't matter, because I will be able to quickly look it up! Outsourcing my brain to a piece of paper. It's gonna work.
So far I have revisited the first two chapters of the Codecademy Ruby track and duly noted everything I learned therein, which was surprisingly a lot. I'm kind of impressed with how much those seemingly goofy little lessons manage to teach you, 'cause I sure didn't think I had absorbed that much info when I was gaily traipsing through it the first time round. (Okay, so it was more of a panicked dash in anticipation of my dev bootcamp interview. But it was fun panic!)
Also simultaneously hitting up this tutorial on Socrates, which is a nice review and is doing a good job of filling in the gaps so far. I suspect however it's going to get a good bit fancier as we go on, so I'm excited for that.
