Project: Book vs. Movie

James and I have been looking to build something together and learn to collaborate better as programmers. James came up with a great idea: people often wonder which is better the book or the movie? So, we built a small app to find out.

Book vs. Movie queries the Goodreads API and the IMDB API to fetch movie metadata and rating, and displays them to the user, highlighting the winner.

We built the app with Node and Express, with some jQuery on the front end, sitting side by side at Think Coffee near NUY. This wasn’t our first collaboration, but it was the first time I’ve ever really pair programmed with anyone – we took turns writing code, both of us focused on the code in front of us. We both learned to work with a few different APIs and parse XML to JSON, but more importantly, I picked up a whole bunch of small techniques and tips on how we set up and build projects. James likes to use as few libraries/packages/external tools as possible, so we were both a bit out of our comfort zone – he was trying to thoroughly understand how the NPM packages and libraries that I picked up on the fly, and I was trying to use as few tools as possible, and really get what’s happening under the hood.

It was great to watch James work on the front end as well – something I’m not great at or feel as comfortable with. I learned about CSS animations, and picked up a few neat tricks

The main issue we ran into – that we chose to bypass for the sake of building faster – is that movie/book pairs often have different titles. A great next step would be giving the users an opportunity to tell us what movie pairings are correct – and then displaying these pairings first in future searches.

The end result is a finished – albeit simple – website, and a desire to build more. In the end, we hooked up the app to a Mongo DB to track incoming searches, and let it out into the big wide world. It feels good to build for people.


Recurse Center, not.

So, after an excited two weeks applying, I got rejected from the Recurse Center after my initial Skype interview (on stage 2/3). This is a bummer – I had gotten really excited about the idea, and thought it would have been a great fit. Getting rejected sucks, and I’m not going to try and turn this into some sort of a “this is meant to be” or “everything is just great” post – but I do want to reflect on the experience honestly.

One of my big worries is that this would have the perfect time for me to attend Recurse – it would have been a great environment in which to grow as a developer and soak up the skills I want to and need to learn. My path now is harder – I’ll continue learning and building on my own , and if I’m still free in three-four months (and can afford to be free for *another* 3-4 months), I’ll apply again. I’m worried that once I get a job, it’ll be a lot harder to find 3 months to attend.

Anyway, all in all, the application experience was smooth and a few good things that came out of it:

  1. Having a hard deadline pushed me to finish my personal website (which I had already been working on) and I wrote out a whole new small project for the application.
  2. I approached all the questions genuinely, and the application gave me a good structure in which to evaluate my programming abilities and my plans. For example, I got to plan out what I’d focus on learning in the next 3 months, and I thought about the kind of engineer I’d want to be in a few years.
  3. The overall process – the application, the website, the interviewer, the speed with which they responded – was fantastic.
  4. I made it through the first round, which is the first time someone objective (not a friend or co-worker or mentor) looked at my code, and gave it a pass.
  5. think I have an idea why I didn’t pass onto the final round. Of course, RC doesn’t offer feedback, so this is a guess – but I think it came down to my communication ability, particularly around the things I learn (I tried, poorly, to explain the JS event loop). This is frustrating, because I was involved in interviewing lots of people at Codecademy, and watched candidates flounder and ramble, and I knew this was a weakness of mine – and I still fell into the trap of doing it. I also didn’t have the most defined plan for what I wanted to learn, but I’m not sure if this held me back (I was given the advice of not proposing a project that’s too specific). So, while it’s frustrating to think about how I could have done better, at least I have an idea where I underperformed – and can focus on fixing it next time.
  6. If I do choose to reapply, there are a few people that have gotten in on their second try, and had a great experience.

Finally, and I think most importantly, I loved every hour I coded. While getting rejected stings, I jumped right back into my next project  the next day (more on that soon!). If I let this deter me, it was never the right move to begin with. So – onto my next project!



This is trouble

I’ve run into a bit of JS this trouble. Take a look a this dog object:

var dogs = [];

function Dog(name){ = name;

  this.bark = function(){
    console.log("Woof! My name is" +;
  this.friends = function(){
      console.log("My name is " + + " and I'm friends with " +;

ruffy = new Dog("ruffy");
rex = new Dog("rex");
spot = new Dog("spot");

dogs.push(ruffy, rex, spot);


When I run ruffy.bark(), I get Woof! My name is ruffy So, then, what would you expect the the result of ruffy.friends() to be? Here’s what I’m getting:

My name is undefined and I'm friends with ruffy
My name is undefined and I'm friends with rex
My name is undefined and I'm friends with spot

This was strange, because I figured this would refer to the object – after all, the same technique works for getting the dog’s name!

After a bit of console.log-ging, I’ve found that in bark() this refers to the Dog object, but within the forEach loop, this refers to the global variable. I’ve found a few fixes:

  1. use a for loop instead of a forEach loop
  2. use the ES6 for of loop
  3. create a variable to store this outside of the forEach  loop.
this.friends = function(){
  var self = this;                 // self == this, the object instance calling the method
    console.log("My name is " + + " and I'm friends with " +;


Recurse Center Application

After working on it for close to two weeks, I just submitted my application to the Recurse Center. We hired a few people from RC at Codecademy, so it has been on my radar for some time. However, Esther recently pointed me there again, and after reviewing the website, I was absolutely hooked. It looks like the ideal experience at this specific point in my life – when I have the time and a strong desire to learn as much as I can about programming. I’ve also had some great experiences in self-driven environments like this, both at Explorchestra and back in Interlochen.

Either way, though, I’m going to focus on learning and improving as a programmer – I’m having a blast working on this stuff full-time.

In other news, I’ve finished and deployed my new two projects alongside the application. I’m happy to present my redesigned website,, as well as a small battle simulator I built as a part of QRL, a game I’m working on.

Cloning an array of objects in JS

I just spent a few frustrating hours trying to debug some code I had written to simulate a battle between groups of units. My script works as following:

  1. Create an array of unit objects based on user inputs, where each unit has a player id, HP, strength, speed, and other typical game parameters. This is our template array for the simulation
  2. By iterating trough this template array of units, create three more arrays:
    • an array with all units added based on their speed count (so that faster units are more frequent and likely to be selected)
    • a filtered array for just Player 1 units
    • a filtered array for just Player 2 units
  3. Run a number of battle simulations with arrays from Step 2. After each simulation, where units attack and change each other’s stats (namely HP), clear my three arrays, and create new ones with fresh unit stats from the template Array defined in Step 1.

The issue I ran into was that my units seemed to carry over their stats from previous simulation runs, even though I wiped the 3 arrays used in my simulation clean, and referenced my master array to clone units. If the error here seems abundantly clear, then you’ve already learned the lesson I just did. I cloned my units as following:

var masterArray = [
    name: "joe",
    hp: 10
    name: "lena",
    hp: 12

var tempArray = [];

for (var i = 0; i masterArray.length; i++) {
    tempArray.push(masterArray[i]);                  // !!!

The issue, I found, is that I wasn’t copying the object – only an object reference. Therefore, when I made changes to my tempArray[0].hp, for example, it would also affect masterArray[0]. Both objects referred to the same location in memory, so I wasn’t cloning the actual object – I was referring to the same object in both arrays.

The answer, I learned, is “deep cloning“. Though this feels a little like cheating, the following solution (one of many!) worked:

newObject = JSON.parse(JSON.stringify(oldObject)); 

We’re converting the object to text, and then parsing it into a new object – no longer referencing the same memory location as the initial object.

I’ve heard about reference vs. primitive variables, but now I’m getting a taste for them.

Step Away

It’s amazing how many technical problems resolve themselves when I step away from the code after working on it for a while. Challenges that suck me in and that seem needlessly complex suddenly become simple when the brain has time to work on them for a little while.

The Right Problem

You’re working on the wrong problem.

I’ve noticed that it’s easier for me to dig into experimenting with code until I get it right than to force myself to think through the best solution for a hard problem. For my current project, a text-based multiplayer game, I’ve created a Trello board to project-manage myself, and prioritized all the tasks – all the problems to solve and components to build.

I’ve noticed that when I butt up against a hard problem, I procrastinate by solving easier, much less important features. For example, a hard problem for my game is how two groups of units enter and resolve combat. Before can tackle the code, I need to think through and decide on the best solution. This is hard and uncomfortable – but it’s also the crux of the whole project, and the reason people would play this game.

Instead of sitting there and patiently thinking through the best solutions, I think for three minutes, and then turn for a distraction. However, I’m too motivated to slack off on Facebook, so I start building something totally non-essential, like a setInterval countdown system – a small UX improvement – which gives me that kick of satisfaction. In the grand scheme of things, it’s a poor decision.

So, I have to consciously stop myself and say: “Max, you’re working on the wrong thing. You should be working on the crucial feature, not the easy, fun one.”

“Also, now you’re avoiding work altogether by writing a blog post. Come on!”

The “Almost-There” Step

One of my favorite stages in learning to code is when you know what the right answer is, know exactly what to type, but don’t understand why. Your mind is close to making sense of a concept, but hasn’t gotten there yet. I call this the “almost-there” step. It’s unsettling and frustrating.

Inevitably, if you persist, the topic clicks into place, and then you fully understand it.

I’m in exactly such a place now with Node routes. A route accepts a function(request, response) as a parameter. I understand that the request is whatever the user is asking for, and the response is what we’re returning – and the response parameter seems to be able to return statuses, redirect, etc. But, on the whole, I still don’t fully get what’s happening here.

Hello world!

It’s 2017, and I’m  charging ahead with my programming journey. I’m not a total beginner – I built a website with a few projects (all Rails on the back-end) and I lead a team of programming teachers over at Codecademy. However, I’m definitely not an engineer, and I have so much to learn before I feel like I can prototype, build, and manage products effectively.

After working with Rails on the back end and the basic HTML/CSS/Bootstrap/JS/jQuery front end, I want to really dive into the exciting world of JavaScript. I just started learning Node.js and Express, and from there, aim to either settle into Express, or continue onto Meteor, as well as React.  I’m also working with my great friend James Mayr, whose back-end background is in PHP. So, a JS back-end should be unifying for both of us, especially if we want to continue to work together (and we do.)

Rails was a wonderful experience, and on my own, I’d probably continue to dive deeper into it. Learning Rails was tough, and it didn’t help that everyone said it should be easy. Ruby wasn’t difficult to wrap my head around – however, understanding Git, ERB, how HTML requests work, what application architecture is, MVC, REST structure, basics of SQL for my database – all of that was overwhelming. Over time, I’ve understood many of these concepts, er, kind of. I hope these skills help me in my JS journey.  The danger of Rails has always been how much you can build without really understanding what’s going on underneath. I’m hoping to correct this the second time around, and really understand what’s happening  in my Node/Express apps.

My goal is to become a PM, and envisioning, planning, and building products is what drives me at the core. However, I find programming fascinating, calming, and endlessly enjoyable. So, I’m really excited to kick up my skillset to the next level.