The third week of this phase comes to an end, times feels like it’s flying and the deadline for the project is coming soon, so before heading into this next week and finishing the phase, let’s reflect on how this last week played out.

Last week, ended with our demo to the client, which went all according to plan. We
deliberately kept our goals simple for that first week, since we we were aware that it would be better to start simple and give us plenty of time to truly grasp what we were starting from, that is to say, to understand to the best of our abilities the functions that were developed and deployed by the last batch.

For last week however, we decided to get a bit more ambitious, but at the same time keep some caution. The plan was to tackle some of the biggest challenges presented on the scope of our project, but not to rush us by promising to finish such features by the end of the week. Instead, we proposed to deliver a preview or preliminary version of this feature, both to get a head start on these tasks that needed the most work, and in order to get some early feedback from our client, such that if they had any comments or modifications, we could be able to implement them in time. That was the plan, and I’ll describe later how that turned out, first I’ll describe how the week went down.

Last week I talked about experiencing imposter syndrome, and this week was not much different from the last one. While I would like to believe that from one week to the other, I would magically catch up with my peers and outperform myself, that obviously is not how any of this works. Last week I took on an issue that ended up being a bit more complicated than expected, this week I tried to took some easier tasks in order to get more practice, but at the end it went wrong. What I painfully learned this week is the importance of understanding how a project is connected, how each of its components interact in order to make a cohesive system; without that knowledge even, simple tasks become incredibly difficult, since moving one thing here breaks 10 others somewhere else. Progress for me was slow, but at least progress has been made.

While I struggled, my team did way better than me, and we were able to get everything ready for today’s second demo. Everything is running fine until now, some details must be examined to ensure we deliver the best experience possible for the client, but so far everything seems to be running more or less according to plan.

On regards to the month’s lectures, this week I learned about the optimism bias, which refers to our tendency to overestimate our chances when it comes to positive outcomes, and underestimating those possibilities for bad ones. This bias seems to be something ingrained on our brain, an evolutionary quirk that came about since having a positive outlook towards life seems to be more advantageous than having a realistic or pessimistic one. Having a positive outlook can be an incredible tool, however we should handle it with a grain of salt, since it could lead to overconfidence and steer us to a dangerous path of risky behavior. Another lecture I saw this week was a case study of the current state of medicine, which explained how the medical field has evolved in the last century from a craft where a single person could handle any situation and was required to be autonomous (the cowboy approach); to a field with highly specialized individuals in a highly complicated field, where there Is no way a single person can manage all of its complexity, and therefore a new approach is needed, one where the system rather than the individual takes the lead (pit crew approach). While very interesting by itself, we are not doctors, but the main point of this video can actually be extrapolated to any discipline in our current day and age, since most of the industries have becomes extremely complicated and interconnected. The pit crew approach can be used in any field with highly specialized individuals, where rather than more training or better tools, an effective system of communication and quality control is met.

Lastly, this week I continued reading the You don’t know JS, continuing with the second book in the series, which focuses on closures and scope. My main takeaways from this week are:

  • Javascript’s 3 main players: Engine, Compiler and Scope.
  • There are 2 types of assignments, LHS and RHS (left hand side and right-hand side), where the former tries to find the variable container, and the latter looks up its value. A good way of thinking about it is “Who’s the target of the assignment (LHS)?” and “Who’s the source of the assignment (RHS)?”.
  • Just like with eval, another instruction we can use to mess with the lexical scope is with. While originally intended to provide a shorthand way of assigning values to an object, the way it is implemented makes it prone to leak to the global scope. This function is deprecated, and the simple fact of having it on your code (even when correctly implemented) messes up the performance of your application.
  • The way hoisting works: since the compiler first declares functions to define the scope, it isn’t as if the variable declarations are put on top, but rather that the declaration of the variable’s names and place is the first action performed, so any use of said value when the code runs can rely that at the very least, the variable’s place has been reserved.

Sketch_note 1