< prev 16 Nov 2014 to 16 Nov 2014 next >

Posts tagged 'tools'

  • What's this about?

    I'm using this tumblr to keep a couple people up-to-date on my doings and not only for assignments, so I thought I'd offer an overview of what the program's about.

    It is, of course, twelve weeks long. The first nine weeks are mainly curriculum, followed by three weeks of project development—looking at what the previous cycle is doing, this consists of cloning the functionality of another public website as an proof of skills. I don't think most people choose to make a novel project (it's easier to solve a solved problem), but I don't know whether it's banned per se.

    As for the "curriculum", it consists of a couple languages in a sequence that ramps up in relevance to web design. So, to start, we're using Ruby to script basic stuff—algorithms, data structures, the fundamentals of programmatic thinking, that sort of thing—and then add in other elements, like JavaScript, SQL databases, CSS for visual design, and so forth. I haven't looked at the elements of the curriculum for a bit because I'm trying to stay focused on the here and now for the time being, but it's basically web development from end to end, from core scripting to design.

    Of course, one part of the program is blogging your reflections on a public tumblr. My alumnus friend tells me that the only people who will be interested in most of this will be fellow students, but I try to cover enough other topics that maybe others will want to read about my time in aA.

    Central to the instruction methodology is a working strategy called Pair Programming. How this works is a single computer is hooked to two monitors, and one person controls the keyboard and mouse, while the other talks about their thought process and, almost but not quite, tells the other person word-by-word how to get through the problem.

    In practice what ends up happening is one of a couple things. First and most ideal, the pair is matched well, at which point you can easily forget who's actually in charge at any given moment—it feels like the executive portion of your brain is the other person, and you become the mechanical/error checking portion, or vice-versa.

    Second, there's a close disparity, or a symmetrical disparity—A knows something B doesn't, and maybe B knows things A doesn't. My pet peeve is people doing motion commands multiple times, so I am constantly teaching my partners motion commands (delete line is ctrl-shift-K, select line is cmd-L, etc.). I don't restrict myself to this sort of thing—I've been spotting a lot of errors and edge cases while driving, which I don't do as much when navigating because I'm thinking of the overall strategy. It's sort of like the source of the analogy—the navigator in a car doesn't tell the driver how to pass or avoid an accident, but s/he does make damned sure the driver doesn't pass their exit.

    My perennial weakness is syntax specifics; I don't bother spending a lot of brainpower memorizing the syntax of every command when the reference material is right there. What I have spent time on, by contrast, is understanding what the elements of the function signatures in the documentation are, so I can quickly parse and interpret what sorts of things a function is capable of, and what sorts of things it returns. I'd like to think I'm helping others learn how to do these things with greater facility.

    Third and most rarely, one person is completely clueless and is basically told by the driver what to tell them ("okay, so how are we going to solve this problem? What search algorithm should we use?"), and then when they're the driver, they're simply a glorified typist. I think this is why Pair Programming often gets a bad rap—in organizations with programmers of vastly different skill levels, you won't always have two people who can pair well.

    One of the advantages that you'll see regardless is that, as long as one person isn't a complete pushover, the pair will produce cleaner, more readable code, and each person will come away knowing more than when they started, either about programming and problem solving, or about communication and education.

    The office, on Cooper Square, is relatively compact and a bit on the old side. It's not all glitz and glamour; it's functional, in a building that could really benefit from a bit of TLC from a motivated DIYer. The local shopping options, especially for food, are amazing—it's going to be hard not burning through my savings by going out to eat every day, especially because some of the best conversations happen at lunch when everyone has a chance to relax—and it's nice and central to a lot of people and train lines.

    We only use the school's computers, not our own. I guess previous cycles had mechanisms for students to bring their own computers, but there are logistical problems with that, especially when it comes to supporting non-default install environments and version conflicts. Further, we all use the same editor to work—Atom, by the same people who make the git version control system (ed: this isn't true; it's made by the github people)—which is a good editor, but not great, out of the box. One advantage to learning Atom is that, in time, you can add plugins to do almost anything any other editor does, but it can be quite frustrating not having some of the more clever IDE shortcuts available by default (TextMate's "Command-enter autocompletes a function signature" is one I miss almost daily.)

    One thing I'm noticing is that if you learn Unix shortcuts, specifically readline mode's motion and deletion commands, and the shortcuts for a single editor, most of the other editors out there will support the same shortcuts. So really, the learning curve to switching to Sublime or TextMate after using Atom should be quite low. Atom does file browsing better than TextMate, so even though I bought the latter, I am considering just sticking with Atom. (If you don't understand, navigating the file hierarchy of a big project can be quite a pain in the ass with bad tools.)

    Their current stats are 98% of grads are hired within a certain timeframe for a median salary of $84,000 (in NYC). This is promising, because I run out of money mid-March :)

< prev 16 Nov 2014 to 16 Nov 2014 next >