Challenges.

We covered algorithms yesterday, as it applied to the n-queens problem. (For the uninitiated, it asks how many ways can n number of queens be placed on a chess board of n x n size.) 

I've done the problem before in CS106B, the C++ class. Even with familiarity, and partnered with someone with a CS degree, it took us a solid four hours to implement the solution. I believe we solved it faster than anyone else, but it was disappointing how long it took. Even with the answer more-or-less understood, we ran into classic errors in logic. We were quick about dissing them about, but... Dang, the brain is bad at programming. 

Today we worked on parallelizing the problem. (That means splitting the problem into subcomponents and running them on separate threads. (In fact, this is not what actually happens with JavaScript; it only simulates the behavior.)) We successfully grasped the implementation of web workers over the morning session.

While implementing the web workers to solve the n-queens problem, however, we ran into a roadblock. Web workers have exceedingly limited access to the rest of the program. We knew this, but we didn't foresee the logistical implications until we were about to implement the solution. Then we realized that we were stuck. After some unsuccessful rabbit-hole exploring to find a workaround, we assessed our options. 

We could proceed to implementing a bit-wise solution (a super efficient and clever solution, but also challenging to understand), or we could refactor our entire code to work in the web workers. Both seemed like exercises that would add little value to our learning. So, we took a break, then shifted gears to work on more common yet challenging data structures.

The wind had already been sucked from our sails, however. It was hard to get motivated. We were so set on solving a problem. I'm proud of our ability to step back and assess the value of different paths, but unfortunately we couldn't fully commit to the new course of action. We both wanted the original problem solved, which we had been building up toward for the past day and a half. (No wonder people have a hard time shifted gears when design requirements change.) In the end, we made minimal progress and called it an early night. 

Well, more like we didn't call it a late night. I still left around 9pm. Laurie Voss, the CTO of npm (a heavyweight in the industry, a popular code package manager for JavaScript) gave a presentation on "all the stuff everyone knows but you." It was a grab-bag review of grips and advice from senior developers, and what they wish the juniors could do. He never actually explained anything (which he disclaimed at the start of the lecture). It was essentially a list of things we should go learn about and understand. Sometimes he would capture the high level idea so we'd have some context, but the implementation was never covered.

Some people didn't like this scattered style, but I loved it. Also, he had quite a lot of jokes, and his slides were excellent visual aids. I especially like the premise of the presentation: trying to capture all the things that people assume you know, but never teach you. 

And again, advantages of Hack Reactor shine through. The evening presentations have been some of the most valuable material I've encountered. From building a web app from scratch to see how the different frameworks interact, to delving into Unix/Linux, to the most recent presentation, I have consistently learned so much. In addition to material, I am constantly driven forward. Left to my own devices, I would certainly get stuck on the topic of algorithms. Instead, I move on to learn about D3, a handy data-visualization package.