< prev 21 Jan 2015 to 18 Nov 2014 next >

Posts tagged 'education'

  • Educational progression

    When students have to make a time/effort tradeoff when swamped with work, not all the work that the professor desires students to complete will be done. Students are still capable of achieving high marks in the absence of 100% commitment, which indicates that there's a disconnect between the work assigned and the demands of a given quantum of instruction.

    Matching these would be a challenge, but consider this:

    • Instructors identify the highest-level skills that students who are successful in the class should possess
    • Instructors make a hierarchy of skills that students would have to progress through in order to develop and demonstrate skills, and connect them together
    • Students are given high-level skills to practice, and if they can't manage them, are given easier and more fundamental skills until they are making progress at their experience level
  • Week 6 Day 5 - The hero of the Greeks

    Today's partner: Max

    We spent the day implementing a lot of the things that are now standard on the modern web. Notably, modifying webpages while they're open without executing a page reload… and sending and receiving data in the background asynchronously by calling on the Homeric hero Ajax to carry our data.

    Wait, no. AJAX (Asynchronous JavaScript And JSON, originally XML) is indeed a means of sending and receiving data in the background while on a website, and it is somewhat heroic in terms of making the web work, but it's mostly a marketing term. What you're actually doing when you make an AJAX site is decoupling page rendering, moving the processes responsible for making your website look and operate onto the client side by leveraging small data transfers and pre-baked rendering operations that live on the client's computer.

    Someone else remarked that they would have felt capable of making a website (with server-side rendering) last week, but now they can't imagine not using AJAX, and I agree. The magic of the web today is being able to do things without having to transition, having access to all your tools through DOM elements appearing on page and stuff just getting whisked away to the cloud without your intervention. Everything feels snappier that way, and for someone like me (who gets angry with a 20ms lag while word processing) it's practically essential. I can already think of the sorts of things I want to implement and test with AJAXy techniques, but as we keep seeing, the class rapidly moves past "the coolest thing we know". The first week, I wanted to make an app in Ruby, then I realized what huge advantages SQL offers, then I thought Rails was the bee's knees, then I thought Javascript was the coolest thing we'd see… now I'm just waiting for the next thing.

    One thing, as an aside, that I can see is that there's virtue to practicing the things you're learning, but there's only so much to be gained. If the pet project you want to do is mostly nitpicking and trying to accomplish something the world has really moved past in the meantime, and all details of implementation… I can't necessarily see the virtue. There's always something to learn that will be maximally useful (of all the things you could be doing, and given your learning style) and it's not necessarily the obvious thing, or tying off the previous lesson.

    Learning relies on practice and scaffolding, but I'm getting the feeling that a lot of technologies require total comprehension of the basics (what's a closure? what's the difference between a proc and a lambda?), some understanding of the intermediate ideas, and total ownership of the thing that makes you money. To get to that point, you have to jump to the next thing while you still have the previous thing fresh in your mind, and have everything gel as a collection of "correct practices" and good habits, … and eventually you can make progress, actually breaking new ground after reaching the top of the (first) cliff. (The rest of the cliffs, of course, are "real" problems to be solved.)

    Learning all the nuance about everything is just pointless, though. There are just too many libraries and frameworks to learn back to front, and generally (successful) people build on what came before, and so the new thing is more or less like the old thing in structure and/or syntax.

    I can foresee, or imagine, programming always tickling the dopamine receptors in my brain because there's always some new framework… in the 50s, academic languages were the forefront; in the 60s it was all about business-specific languages; the 70s saw C gain popularity, with its general purpose systems programming capabilities… but there's not so much that's new in the history of computing. And there's never a point where you can sit still, content with what you know. Maybe that's a good thing.

  • Week 5 Day 1 - Making my peace

    Today's partner: Ben

    The project today was sort of forgettable, like the last couple days. It's been good to get so much practice with Rails, and today was fun - we used Capybara to write integration tests, then wrote code to build the appropriate elements and views to pass those tests, learning a lot about how Capybara and integration testing work in general - but it was another one of those days where ultimately I'll forget what, specifically, we did.

    Everything is just forming into a big ball of stuff in my head called "rails knowledge". It's kind of cool in one way, but in another: we're halfway through the curriculum, and a lot of it is a blur.

    Story time. When I was in AP Calculus, I had a hard time keeping up with the class, but the AP test was a solid wall in front of me that was a) well-defined, b) had plenty of information available and c) had important consequences. So, the week leading up to the test, I gathered as much practice material I could, and then in the two nights before the test, I cherry-picked the problems I was having the most trouble with and did them over and over until I could do them easily.

    The repetition drove the ideas into my memory, and to this day I can understand the concepts of calculus due largely to the intentional practice with a clear goal provided by that exam.

    In the past year or so, I've come to understand that my primary advantage compared to others is my memory. When I have sufficient context and sufficient reason, I can remember just about anything quickly. When I don't have reason, context, or practice, I'm just an average person, sort of.

    So with this rails stuff, I spent most of last night—the parts where I wasn't doing readings or tumblr posts or whatever—doing parts of the practice assessment, and came in this morning ready to graft more knowledge onto what I had been getting comfortable with. We were still slower than others today, but the difference is I didn't really care. We worked well together, our tests worked well, we wrote the auth model in under an hour (give or take), and we got a lot of knowledge, both core and ancillary, out of the lesson.

    Sure, I can look at the bonus work and look into "completing" this project perhaps over the weekend, but really what will I gain? If I am able to do the things that these projects ask in a more synthetic context - creating polymorphic associations, writing tests with good coverage, etc - then what am I really missing? It would be like going back to try to re-do the test you failed in the third grade… of course you'll be able to pass it now.

    This program, and TDD in general, really make me consider some things about how we educate in this country. You don't generally test every possible route through your application; instead, you perform unit tests on individual models, then you perform integration tests on inter-related structures. The former model would involve something like n^m tests, whereas the latter demands n+m tests - where n is the number of "objects" and m is the number of "relations".

    When educating, you don't need to test to see if someone knows how to multiply on a boat, how to multiply with a goat, how to multiply nine digit numbers and ten digit numbers and eleven digit numbers… you need to see if they know how to multiply digits, then to perform carry rules, then to do more complex operations… perhaps curricula should involve unit and integration testing, like TDD. It certainly feels like a/A is doing this with us.

    Tomorrow's another solo day, but more importantly it's the day of the assessment. I plan on doing it at least once end-to-end, and maybe focusing in on re-doing a couple hotspots before 9 am, but I'm feeling remarkably comfortable with myself at the moment. Let's see if it lasts.

    Two more days until the weekend, and more studying. :)

  • Week 2 Day 1 - "We can refactor that later"

    Today's partner: Marc

    Today was the day of the first assessment. It went well—I was less nervous than when I did the practice assessment, which I guess is the point—but I ended up tripping on the same edge cases as I had doing the practice. Derp.

    (Technical gore ahead: I was writing a sort method per the instructions, specifically bubble sort—I know, I know—and wrote a helper method to implement bubble_sort! that was called by bubble_sort. Somewhere along the way I started getting wrong argument errors—0 for 1 or 1 for 0, depending on what I was doing at the time—and it took me ten minutes to see that I had been checking the function signatures for errors, when it was the call out to the helper method that was causing the problem.)

    I felt guilty for finishing early since it seemed like most everyone else was still working, but looking around it seemed a couple people finished earlier than me. Sure enough, looking at tumblrs, another student finished absurdly quickly—the specific student I expected—and really, I ought to have been just a bit slower than him.

    A lot of students have that moment when they first enter a highly selective program where they realize they're can't easily be the best anymore. I've had enough time in life to get used to that idea, but really there's little enough excuse for me not to push harder to get better. Having a decent target to reach has helped my typing speed (compared to just typing gibberish in a typing trainer) but I still have to test my assumptions about what a method can handle and what it returns too often for comfort. What I'd like, by the end of this program, is to be in the running as the "best" student and not just coast on … whatever it is that's gotten me this far in life. That will take work, and prioritization.

    As any regular reader of this blog will be able to understand, most of my biggest demons are of my own creation.

    We spent the entirety of the rest of the day working on Minesweeper. I can tell after a solid week that one of the critical pieces of Pair Programming is how well or poorly the personal dynamic plays out. Historically, I haven't been one who can easily convince another to adopt my priorities. This is another thing that I think raw competence can help with: people will listen to someone who seems to know what they're talking about, especially if they have easy confidence, even if that person doesn't actually know what they're doing (until, of course, that person is revealed as a sham). Further, sometimes the people you have to work with really want to go in one direction when you wholeheartedly believe that another route will bear more fruit. Wrestling with this sort of thing can be exhausting, because either you defend your idea and "win", or you realize the other person has the better idea and concede your point. Either way, you've expended a lot of mental energy.

    I'm not saying, mind you, that my partner was particularly difficult to work with. I have had some amazing pairings so far, but today was one of those days where we each had an idea for what needed to happen, and we were pulling in different directions—vectored off from one another just enough that it was a challenge to move forward.

    We got where we needed to be by the end of the day. The game worked, we had a somewhat clean data model, and our logic held up. We were even able to add some extensions—we changed the symbols used from rough ASCII to some nice Unicode that I think was much more readable on-screen. But toward 3:00 or so I began to think we ought to order T-shirts that say "Don't worry about that; we'll refactor later." Were this a production codebase, we'd have accumulated a lot technical debt today. Compare this to most of the projects in the first week: my style was much more comfortable and easy to read, with only a couple places (typically method chains) where I could benefit from some cleanup, and I think that's a direct consequence of having a solid idea of where we needed to be and the route we would have to take to get there in the first thirty minutes of class.

    That is to say, all of our problems can be traced back to an overall bad approach to architecting the solution, specifically the separation of class responsibilities and the mechanism for passing certain objects. Prototyping, or figuring out a full schema earlier on, may have helped protect us from some wild goose chasing, but as Fred Brooks said, when solving a new problem teams should design a throw-away system first, because you're going to throw the first one out anyway. (See also: Annie Lamott's "Shitty First Drafts")

    It's not easy to see your own failings, but looking around some common ones that others demonstrate include a resistance to learning skills that are not core to the "purpose" of a course (the purpose being debatable—I've been at enough colleges to know that what's on the final is a small fraction of what a student needs to learn), stubbornness about one particular approach (kill your darlings!), not being able to listen to others at all, not telling others what you're doing because it's obvious to you, not giving people the benefit of the doubt… to some small extent each of these has manifested in my time here, and I'm on the lookout for those times when I, myself, am guilty of these. Small sins can be hard to see.

    It was a good day, overall. I love the people here, but the difference in energy level between a good day an an average day is really noticeable. Still, every day so far has been far better than any day of work or school until this point.

< prev 21 Jan 2015 to 18 Nov 2014 next >