#hack_reactor

Without a doubt, one of the most impactful things at Hack Reactor has been the teachings from our lectures. Especially at the beginning. This was due largely to our main instructor Marcus. Honestly, his attitude towards teaching and care for the students is one of the main things that sold me on Hack Reactor in the first place. In this post, I'd like to walk you through some of the things I think set Hack Reactor apart in terms of teaching style, culture, expectations of students, etc.

Expectations

From the the start of Hack Reactor it was clear that they expected a lot from us. To get into the program there were two technical interviews and a chat client assignment. After being accepted there was about 50+ hours of pre-work to do before the program. This is honestly starting to be the norm for a lot of intensive coding programs. What's different about Hack Reactor is that when you arrive your first day you realize many of the students are already part way through a CS degree, flew through the prework and that the first two weeks you take a deep dive into data structures and algorithms. If you aren't extremely solid on the fundamentals when you start, you will quickly be buried by the work thrown on to you. They expect a ton out of the students and that is one of the things I like most about being here.

Pair programming

Pair programming is one of the best ways for a beginner to learn how to program and learn how to vocalize code. It's basically when two people sit at a computer with two screens and two keyboards that are attached to the same computer. They work through the code as a team, with one person being the "navigator" and the other person the "driver". The navigator is the person that decides what to do. If the either of the people are like "Ooo I know what to do", rather than take the keyboard and do it, they suggest to navigate so that they can speak the code to someone else and the other person (driver) can practice doing it. The driver is the person that has the keyboard and codes. Each person takes turns swapping between driving and navigating.

My experiences with pairing have been largely positive. It really helps to practice working on problems with someone. Getting stuck isn't as frustrating when you have someone else to work on a problem with you. Generally when you pair, both people have a notion of who knows more about what to do. When this is the case, the 'better' pair is able to practice navigating more and explaining their reasoning. I've frequently had situations where I thought I knew something very well but when it came down to explain it, I realized my understanding was foggier than I initially thought. This can also be one of the challenges of pairing is that when someone has a weaker intuition of what to do, it can lead to both of you constantly jumping into rabbit holes and diving into tangents that don't solve the problem. This is why I've tried to embrace a more inductive way problem solving and debugging. I'll explain what I mean. A deductive way of debugging is where you might run into a bug and then frantically trial/error every possible solution you have in your mind. For small problems this might be enough; however, with bigger problems you can end up spending an hour or two spinning your tires and still not have any idea what the problem is. The inductive way to solving is to go back to the point where you know exactly how the code works and you know it's functioning. You then step through the code one line/block at a time with a debugger and find the point where things aren't behaving as they should. Next, make a hypothesis on what you think is the root cause and a potential fix. Test out the fix and see what happened. Wash, rinse repeat.

The other side of pairing is also helpful but it has drawbacks all the same. When you are the 'weaker' pair it feels better because you fly through the problem easier and you're able to get an explanation from your pair about how they're approaching the problem. The downside is that you don't hit the same roadblocks that you would've alone and that effectively means that you also skip a lot of the learnings that you should've had. For this reason and many others, we're always encouraged to pair with people who have similar abilities to us.

Mentality

Coding can be extremely frustrating. When you're in an environment such as this it's easy to feel discouraged or feel like an idiot because your peers are constantly one step ahead of you. One of the things that's been drilled into our heads is that good software engineering doesn't mean that you know everything. Rather that you are comfortable understanding that you don't know everything and you can move forward quickly. You are also comfortable with just interacting with the interfaces of libraries/frameworks and not having to understand the inner-workings of everything.

Autonomy

When we all started at Hack Reactor, their mandate was to make sure that no student 'grinded' on a problem for more than 5 minutes. Grinding is where you are stuck on a problem and are burning a lot of mental energy to figure it out. Hack Reactor offers tons of resources to make sure that we can get 'unstuck' immediately. However, as we progress as developers their goal is for us to become autonomous. Autonomy in coding is where you are able to unstick yourself through whatever effective means necessary. This might mean talking to a senior engineer, but it likely means debugging, stack overflow or reading the documentation.

Lowest delta

Lowest delta is the idea that rather than code 50+ lines and check in your code, you should do it much more iteratively. This is better both for debugging and for keeping track of working versions of your code. Aiming for the lowest delta means doing the smallest amount of code necessary for a noticeable improvement in the program. Doing as little as possible to improve the app, testing it to make sure it works, then checking it in.

Toy problems

Backbone.js

The last sprint we did this week was building our third app in Backbone.js. Backbone is a library that acts a lot like a lightweight model view controller. I say light because Backbone isn’t as prescriptive as a heavier framework like Rails. It requires you to do all the wiring yourself, but it provides a structure that enables you more than directs you.

Our goal for the app was to build a Blackjack app. We were given a shell of an app to work with that already had about 4 views and 4 models. This was enough to provide us a function to create a shuffled deck and to hand out cards. We then had to make the functionality for hitting, standing, betting, etc. The first day of this project was somewhat frustrating because we were still getting used to Backbone and Coffeescript. It’s quite painful when you grind on a problem for an hour and half when you know that the problem is one line. After getting the basic requirements to work the first day, we broke off the second day to cover more ground. I built out the betting features and my pair built out the CSS styles for the cards. I’m actually pretty happy with our result. Check it out here! Some of my biggest lessons from this project were that I needed to learn how to better communicate my ideas in code and that whenever debugging, it’s essential to use an inductive solving process. This means that you’re starting from a point where you know things are working and you inch your way through the code, learning/testing each piece until you find the root cause. Often in code the shining red light will just be a symptom of the problem that you’re trying to solve. By inductively reasoning through the problem you almost always save a lot of hours of debugging. The opposite is when you get stuck, trial/error every possibility that comes to your mind and end up burning through an hour of debugging and still not having a clue what is wrong.

Another huge benefit of Backbone is all the built in event listener functionality. Models and views are able to 'listen' in on events from each other and can take actions based on those events. In this game, there are many events that fire off based on user behavior (clicking bet, hit, stand) and functions that fire whenever those behaviors are meant, such as the rendering of particular views.

The last piece of functionality I liked was the flow of the models and views. This was my first experience wiring an MVC from scratch and it was really nice to be able to customize where to direct each model and view. I know that other frameworks tend to be more prescriptive in terms of forcing an approach on you but Backbone gives a lot of flexibility there.

Coffeescript

This task wasn’t too hard on it’s own, but in addition we had to do it in a new language (albeit a close one), Coffeescript or CS for short. CS compiles directly to JS. It was made as an answer to a lot of the complaints people have about Javascript. JS can be a confusing language to learn because it has a lot of odd syntax, classes that don’t work intuitively, declared variables/ explicit returns and a bunch of other stuff. Coffeescript takes away a lot of this. It implicitly returns, implies variable declaration, gets rid of a lot of the ugly syntax that JS comes with and takes away the entire .prototype layer. However, despite it making things ‘simpler’, I also found I was making more syntax errors simply because I didn’t know the language. 

Here is the app if you’d like to play around with it. It’s not quite finished but it’s to a point that I’m happy to show it.

PPG Casino - Blackjack

http://bit.ly/12lDWO8

one of the things I've struggled with since its introduction is 'this'. 'this' is Javascript's convention for context. the best way to explain it is to show some examples:

if we open up our console and type:

var shout = function(name){ alert(name); }

then we execute the command with shout('greg'), the browser will execute an alert that says the name greg. but what happens if we were writing the function from within an object. and we wanted to alert that objects name. for example:

var alice = { name: 'alice', shout: function(){ alert(name); } }

if we execute the command alice.shout(), alice's name will not be shouted because when we call alert(name), name doesn't refer to anything. this is where we need the 'this' keyword which sets the context of the variable we're calling to alice. while we are within the scope of the alice object, 'this' will refer to alice. so if we call alert(this.name), this reference alice as the object and it will look for the 'name' property of alice.

now for a more complicated example. how would you write a function that would remember the initial context that it was passed? for example a bind function that when passed an object and a function, it would create a new 'bound' version of the function that would always remember the context it was originally set in. second, how would you write it so that you could write func.bind(obj). here is a crude version of how it could work. first we would set our function and our object. in this case, we'll have it be shout and alice. next we write our binding function using the Function.prototype because we're adding a function that we want propagated to all Function instances. Also remember that in Javascript, functions are also object and have a prototype all the same.

we could write it like this:

Function.prototype.bind = function(obj){ return function(){ this.call(obj); }; }

this way when, we create our new 'bound' function like var boundShout = shout.bind(alice), we should be able to call boundShout() and hear it shout alice's name right? wrong. even though we may have thought 'this' was referring to the function when we created it, all the matters is the context of this at call time. what is this means is that it doesn't matter that in the function we thought 'this' referred to shout. the golden rule of javascript is that it's what is left of the dot at call time that determines the context of 'this'. and when we call boundShout(), what is left of the dot? there is no dot. the context is therefore, 'window' which is the main browser object for the tab that's open. to fix our function, we need to save the old context of this during the construction of the function itself. we can set this to a variable, and instead of referencing 'this' at call time, we can reference the saved context, 'that'. here's the code:

Function.prototype.bind = function(obj){ var that = this; return function(){ that.call(obj); }; }

always remember the golden rule of 'this': 'this' refers to the object to the left of the dot AT CALL TIME of the function.

alert('hello') // this === window