DEV Community

Cover image for The Rising Coder - Week 2/13 (Fundamentals Week 1/3)
Christopher Lam
Christopher Lam

Posted on

The Rising Coder - Week 2/13 (Fundamentals Week 1/3)

Hey, hi and hello! Thank you for coming to read this week's blog post on my coding journey: The Rising Coder with the Northcoders coding bootcamp!

Feel free to drop me a follow on Twitter, LinkedIn and GitHub!

So, how was my second week?

If I could summarise this entire week, it would be "Absolutely bonkers". The first introduction week helped us become familiar with the setup of a development environment, a recap of the basics of JavaScript (Primitive/Non-Primitive Data Types & methods etc), modules/exports for access to the testing libraries in the future and such.

However, going straight into the start of the week we were introduced to a plethora of abstract concepts and practices which ended with the topic of JavaScript Closures, and I'm so relieved that I managed to get my head around the topics that were covered this week, it was a huge step up from the previous week!

What exactly was covered this week?

Jumping straight into the contents of what we had covered this week, we touched on the following topics:

  • Pair Programming & Test Driven Development (TDD)
  • The differences between "Primitive" and "Non-Primitive" Data Types with the main topic of mutability vs immutability & value vs reference.
  • JavaScript Closures

Pair Programming - So, what is this mysterious practice?

Pair Programming is an agile software development method that operates on the idea that two heads are better than one. Pair Programming is traditionally broken down into two main roles of:

  • Navigator - The navigator does not touch the code but is responsible for navigating the driver as to how to get to the desired outcome of whatever problem they are trying to solve. This does not mean they provide every method (and the reverse never provide any ideas), but they ensure that the pair are implementing best code practices of clean code & test driven development, and are staying on-course.

  • Driver - The driver is responsible for listening to their navigator and implementing code that suits the problem they are trying to tackle with their pair.

Over the course of the bootcamp we will be pairing up with another student in our cohort to complete "Sprints" (Work that is done within a short time period), and as such we were given the following tips:

  • Be accommodating + kind to yourselves and your pair.
  • Be flexible with the "rules" of pair programming - Do not be bound into only those two roles and don't be afraid of trying something new that works for you and your pair.
  • Respect each other's boundaries.

The second tip was the most important to me because going into pair programming with the limited mindset of "Only these two roles" will make us both inflexible and unable to explore options that would work for me and my pair.

Test-Driven-Development (TDD)

Test-Driven-Development otherwise often known by its abbreviation of TDD is a common buzzword that you will hear being used by many people within the tech industry. So, what is it exactly?

Test-Driven-Development is a development technique where you build up tests that are designed to fail at first and then build your solution for these tests.

But, why use TDD?

Firstly, is that TDD allows you to have proper proof that the code that you have written is doing exactly as it is intended to do without any weird unintended side-effects.

Secondly, TDD revolves around writing minimal amounts of code to pass each test before refactoring.

If you think about future codebases having tens-and-thousands of lines of code in multiple files, then having tests for each individual unit of code will make both your life and your future colleagues' lives easier because you are able to show each other "Hey this piece of code does this and is shown in its tests."

Rather than writing new lines of code and breaking existing code, and having no tests would make it immeasurably difficult to identify what was going wrong with the code.

Primitive vs Non-Primitive Data Types & Value vs Reference

The concept of "Primitive" vs "Non-Primitive" data types is probably the most crucial concept that myself and my fellow cohort students had to learn about.

Primitive Data Types in JavaScript are: Number, String, Boolean, Undefined, Null and Symbol.

Non-Primitive Data Types in JavaScript are: Objects/Arrays

We first learned that primitive data types are what we call "Immutable". This means that we are not able to directly change the state of that variable once it has been created.

For example, consider the example below:

let exampleWord = "hello";
exampleWord.length = 7;

console.log(exampleWord) //Returns the length of exampleWord to 5;
Enter fullscreen mode Exit fullscreen mode

You are not able to directly change the state of a primitive data type even if you access its properties such as length.

"Non-Primitive Data Types" such as Objects and Arrays whose properties we are able to "mutate" a.k.a. change the properties within these non-primitive data types.

For example:

const arr = [1,2,3];
console.log(arr) // logs an array of [1,2,3]
consle.log(arr) // logs an array of [1,2,3,4]
Enter fullscreen mode Exit fullscreen mode

The array above is able to have its properties modified/mutated.

Through understanding primitive data types are immutable and vice-versa for non-primitive data types. We are introduced to the idea of "Value vs Reference."

Primitive Data Types such as Number/Boolean/String are referred to by their value when being compared with other variables. Whilst non-primitive data types such as Objects and Arrays are compared to each other by their "References" in memory.

This means that Arrays/Objects at the moment of initialisation are assigned their own space in memory and are referred to by pointing towards that space in memory in which they occupy.


That leaves me with the final topic that we covered at the end of this week, which was the concept of Javascript's "Closure", and thank the lord that it's the weekend after going through this concept!

Closure in JavaScript refers to a function having access to variables that are defined within its lexical scope (parent function's scope) or in simple terms, its outer environment.

Consider this example:

function helloWorld() {
  const greeting = "hello";

  function finalGreeting() {
    return greeting +  " world!";

  return finalGreeting();
Enter fullscreen mode Exit fullscreen mode

So, what exactly is going on here? First we have a function called finalGreeting() that returns greeting + " world!" But, for those who are keen eyed, within the finalGreeting() function, there is no variable that is created called greeting. So how does it work?

This is because of "Closure". As this function called finalGreeting is living within the function helloWorld, it is able to get access to outside variables living in its lexical scope/parent function scope and utilise them if they are not previously defined inside its own function.

The Tricky Part: COVEs

Probably the most difficult one to understand was the idea of "COVEs" or "Closed Variable Environments" in JavaScript. But, simply but is that JavaScript has a "Garbage Collector" that removes any unused variables once the thread of execution has concluded and all of the code has run.

The concept of a COVE is that variables that are still being referenced by other functions inside will make it so that those variables are stored inside the COVE and are not deleted but are still accessible.

How I remembered it: Recycle Bin Analogy

In order to remember about the COVE, I compare it to the Windows Recycle Bin. Even when files are deleted on your Windows PC, they are still somewhat accessible because they are only moved into the Recycle Bin where you can restore them. So unless you remove them yourself permanently, they will always be stored away in their own reference in memory.

Sound confusing? It most definitely was to me! But, we survived and managed to make it through this week too.

A really huge shout out to the Northcoders Mentors, my fellow cohort members for always being supportive of each other, and to my two partners this week, you guys absolutely rock!

Thoughts Going Forward

Honestly, a really great first week on the Fundamentals part of the bootcamp. Didn't complete the most amount of challenges (Katas), but I did internalise a lot of the material which I can argue is just as important! For now, I will be looking ahead and reading up on a few difficult concepts such as: Recursion and OOP!

And as always, if you have made it this far, thank you very much for reading and I hope to see you next week!


Feel free to give me a follow on any of my socials down below!

Top comments (0)