Week 1, Day 3 : First Impressions

So it's week 1 of the Hack Reactor course proper.  My class is the 5th Remote Beta class (all instruction conducted online), or HRR5.  I guess now's the time to share some first impressions.

Before the course

They get you off to a pretty good start with 3 weeks worth of precourse work, which is good for both confidence building and actually teaching you stuff.  Some interesting assignments included building a "Twitter clone" and a bunch of functions using shudder recursion.  I still hate and fear recursion at this point, I hope it wears off sometime in the course of the class.

Aside from a few moments of anger and confusion at recursion, the precourse was surprisingly fun.  I never thought programming was very enjoyable before, so I always avoided a career in it.  Looking back, I think it was because I was mostly learning C/C++ (not my cup of tea) and the projects were very abstract, such that the results were weird theoretical things I couldn't care less about.

Being able to make a "Twitter clone," or even just a function that converts some data into an important string format everybody uses, makes a lot more sense.  And being able to do it in a more intuitive language (Javascript) helps a hell of a lot too.

So precourse was  pretty great, I finished it feeling like I'd made a pretty good decision and I hadn't just thrown thousands of dollars down a black hole.

Pair programming

All exercises in the structured part of the curriculum (the first 6 weeks) are done through "pair programming" with a partner, which is really weird for me.  Programming has always been a solo effort for me, where you can fail in the privacy of your own humiliation and only emerge to proudly display your product when it is complete and all the evidence of failure has been destroyed.

Pair programming kind of ruins that in that every dumb guess and wild goose chase is something that your partner not only sees but has to follow you on.  But it goes both ways, you get to see their mistakes too, so I guess nobody's really going to be judging anybody too hard.

Apparently pair programming is really common in the world of coding and even though it takes a little bit longer than working solo, it leads to fewer time-consuming mistakes.  Plus, it teaches you to play well with others, which is apparently important when you're working for other people.

I've had two partners so far, they were both pretty cool I guess.  They definitely caught some bugs and problems a lot faster than I would have (and vice versa I think).  I can see the benefits but it's still probably going to take some time to get used to.

Material so far

Most of the actual technical stuff we've been learning has been review of things we already learned in precourse.  I figure this is so we can focus on getting used to the structure of the class, including weird new things like pair programming, as well as iron out all the technical difficulties.  Of which there are many, as you would expect for an online class.

We're using a bunch of different software - Zoom for large group lectures and Q&A, Vimeo in a Chrome frame for video lectures, Google Hangouts for pairs and small groups, Floobits for typing code together, HipChat for text communication throughout the day, GitHub for keeping our code somewhere, Google Moderator for posting questions about lectures, and who knows what else to come, plus everyone's got their own computers and OS's.

I would be suspicious if something _didn't _go wrong.  I think it's actually been pretty smooth so far, considering.

Non-technical material

Most of the non-tech stuff we've learned is about course structure and what to do if we need help, how we should do each type of scheduled event in the curriculum (pairing, Q&A, what to expect and not expect from the staff and the course), as well as some general lessons about coding, attitudes toward coding, and how to succeed.

One thing we learned today was something called "the debugger's question," which is the question you are supposed to ask yourself when you hit a bug in the code, which is guaranteed to lead to solving it.  It was not, as I had always thought, "What?  Seriously?" which is what I always ask myself whenever my code errors out.  Strangely, this line of questioning had never yielded a successful debugging experience.

The question you are supposed to ask, as it turns out, is more like "What justified my expectation that [insert expectation here]?"  Like if you were expecting a variable to equal 5, you would ask what justified your expectation that the variable would equal 5.  And follow your expectations backwards until you found a mistaken assumption.

I still feel like asking angry questions at the computer is more intuitive but I guess that probably works better.