I’m enjoying the work that Kyle Simpson has done on understanding how the compiler (yes, he says JavaScript is a compiled language not an interpreted one) declares and hoists functions and values. A cool thing about it is that functions do not hoist in a stacked way, they hoist in a mutual way and he has an awesome example to prove it. “As always this is more for my sanity than yours”.

I have a huge goal of understanding JavaScript better. Digging deep into it is really helping my confidence and understanding of larger concepts. “Every thing below is my interpretation and you should do your own research”.

First there is a difference between function declarations (statements) and function expressions.

function b(){}   //function DECLARATION(statement)

var a = function(){}   //the left is a variable DECLARATION, the right is a function EXPRESSION

The code below is a great example the start with. Hoisting is really something we made up to explain a complex feature that the Engine executes. But, at the running of this code the engine will run all the way through the code identifying all DECLARATIONS and assign them positions in memory then, during execution the engine will run through the code line by line assigning values.

Screen Shot 2016-05-25 at 2.41.20 PM

So the above code basically (how we see it) runs like below:

Screen Shot 2016-05-25 at 2.46.57 PM

“Var a” and “var b” are both declared and set with a value of undefined (yes it’s a value). Then the code will run line by line. Above you can see that “a” is set to “b” while “b = undefined”, then “b” is set to “2”, “a” when logged is still “undefined”.

Now, function declarations (some call them statements) are hoisted ABOVE variables when declared and function expressions are not hoisted. Simpson talks about the LEFT of EQUALS is Declared at compile and the RIGHT is Assigned at execution.

Screen Shot 2016-05-25 at 4.07.43 PM

Above code basically hoists (how we see it) like the code below.

Screen Shot 2016-05-25 at 4.10.03 PM

From what we know about how variables hoist we would think that functions would hoist in the same manner. A function declaration (statement) hoisted below the above function declaration (statement) should not be able to be called.

Screen Shot 2016-05-25 at 4.19.16 PM

Simpson argues that if this language was a truly interpreted language that read line for line then the above would not work. Functions declarations (statements) are actually hoisted at a “MUTUAL LEVEL”.

Screen Shot 2016-05-25 at 4.22.40 PM

He proves this with a Computer Science concept called Mutual Recursion, where multiple functions are calling each other. PS. sorry if you read the link and now your brain hurts!

Here is his example (the code works fine):

Screen Shot 2016-05-25 at 4.26.53 PM

The answer should be 39. I worked the problem out free hand below.

Screen Shot 2016-05-25 at 4.46.32 PM

a() is checking for completion (foo > 20) and returns a call to b() while adding +2 to foo.

b() is returning a call to c() and adding + 1 to a stack that will grow due to closure

c() is calling a() and passing foo * 2

after 3 rounds a checks that foo(36) > 20 and returns foo which in turn will grab the b stack (3) “that b stack is sitting in memory I think due to closure, I need to do more research”

a(36) + b(3) = 39


*Side note: this might also explain why primitive variables passing to other variables are copies. eg “a = 5;”, “b = a”, “a = 1”, “log b & log a”, “a=1”, “b = 5”. Where as “function a () {return ‘car’}”, “var b = a;”– these are pointing at the same function, so if function a is changed then function b is changed. I need to do more digging.

Kyle talks about this compiler in much more detail, talking about how the compiler looks at Left Hand Statements vs Right Hand Statements among other concepts. It’s really good stuff and he has a course on Plural Sight which goes into a lot of depth.


Journal of an Apprentice Developer

After connecting with a company here in Atlanta I was sent a set of corporate principles and resources. This was so that I could better understand who they are and what they represent. The resources are great focusing on two great works Clean Coders and Apprentice Patterns.

Inside of Apprentice Patterns was a gold mine if you are interested in learning about the life of a new developer. In chapter 2 (or 3?) there is a link to an old blog by a developer named Jake Scruggs where he details his experience in his first position (YOU CAN FIND IT HERE) at Object Mentor. I realize I am supposed to be reading the other two pieces of work but this is intriguing to dig into.

On a side note I had seen a excerpt from Apprentice Patterns in a tweet from Toby Ho who is a teacher for Digital Crafts and had already placed it on my reading list. I’ve read Clean Code and I am sure Clean Coders will be great.


Journal of an Apprentice Developer

I’m In An Abusive Relationship: With Code Wars

Code Wars: “Hey Ryan, come here take this challenge…… you know you want to”.

Me: “You ruined my life! I hate you! But, okay, one more time.”

I am in an abusive relationship, with Code Wars. Don’t get me wrong, I love it. But, as a younger developer it can be exhilarating or depressing experience. If you don’t know Code Wars is a website that allows people to tackle different coding challenges. I right now am a Level 5 hopefully soon to be a Level 4 (Level 1 is the best).

Some of the challenges are how might I say this? “Quite absurd” Here is an example:

Screen Shot 2016-05-20 at 12.02.52 AM

The amount of things I need to google in the picture above are astounding!

Though, completing these challenges is exhilarating, as a young programmer these can also be a bit confidence rabbit hole (imposter syndrome, no doubt), particularly when you have spent HOURS on a solution and compare it to others.

(node the code above, just an example)

Me: “4 hours, 37 lines of code”

Arsky8867: “2 lines of code, using .map() .filter() a ternary operator and a regular expression!”

Screen Shot 2016-05-20 at 12.12.28 AM

Seriously? What is this? This is voodoo?….. and I admire it.

“Unreadable code = bad code” yes, I’ve heard the pitch but as a newer coder and after taking hours of time I find this both frustrating and exciting.

I want more! More pain, please!

Ergo….. I am in an abusive relationship…. with Code Wars.


I’m In An Abusive Relationship: With Code Wars

Teach It So That You Understand It

It’s hard to understand new concepts let alone create with them. As a new developer there is always the feeling of drowning in information. I’ve been working on gaining a better understanding of concepts by teaching them to others.

Blooms Taxonomy tries to explain the different levels of comprehension that we have when dealing with a concept. It works really well when you think about developers, the best are working in open source creating, evaluating and analyzing.


Taking your understanding of a concept and teaching others is a great way of moving up this pyramid:

  1. Can you identify, recognize and explain this to others?
  2. Can you apply and demonstrate?
  3. Can you compare and contrast (callbacks vs promises?).

This is why Paired Coding and effective Mentorships work so well. It’s people working on this practice. Sometimes we find out we can CREATE but cannot EXPLAIN. When this happens we need to realize our gaps and work on them (I have plenty more gaps on the top of this pyramid).


Recently I have been jumping on Free Code Camps Gitter and offering to host Google Hangout lessons on concepts I am working on. The other night I showed people how to set up their first Nodejs server so they could work in a local environment. This week I am going to jump on and talk about “call backs” or maybe explain the “execution stack”. This isn’t about me being an expert, it’s about me demonstrating an understanding of concepts that will allow me to challenge myself through application and analysis.

This can help all of us (newer, new and old) developers by making us work through these phases of Blooms Taxonomy for true mastery.

Teach It So That You Understand It

Great Resources For Learning JavaScript

As a former teacher and coach and someone who is probably about 1500 hours back into development (lets not count college) I have a certain way of learning things. I need to really understand what is going on not just at the syntax level but the processes behind it if I am going to feel comfortable with it. Here are 3 resources that will change the way you look at JavaScript:

JavaScript Understanding the Weird Parts by Anthony Alicea

1000 hours in I had no clue what the “Execution Stack” was or how a “Closure” really worked. This changed the way I thought about code by making me think about how the engine worked. It’s $30 on Udemy and worth it.

You Don’t Know JS by Kyle Simpson

After digging through Anthony’s work I jumped into Kyle’s 6 (yes I said 6) books on JavaScript. One day I will meet Kyle, he will not know me but, I may just hug him (or buy him a beer). You could buy these or you could realize he is a walking saint and visit the GitHub page to access all of them.

All IT Ebooks

This one may be the best and worst resource you ever use. It’s hundreds upon hundreds of dev ebooks. Where do you even start?

Great Resources For Learning JavaScript