Mastering Ember from the Perspective of a N00b
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Kerndt, Madison
Often times the last person to learn a topic is the best person to teach it. Working within a framework that rapidly changes, we consistently find ourselves in the position of the learner. With fresh eyes, I will reveal common bumps along the path to mastering Ember. Geared towards experts and beginners alike, we will map concepts from a simple CRUD application to relatable mental models in order to demystify the Ember magic. On-boarding new developers and learning new concepts is essential to continuing the growth of the Ember community. Join me to level up!
 I'm here to present how to master Ember from the perspective of a noob. And I'm going to start with a confession. I am a noob. And even more shocking, so are you. You may be feeling slightly indignant about that statement, thinking, I didn't become an expert in my craft just to be called a noob. Or you might even be feeling slightly offended. Who is this woman? Honestly, it's kind of arrogant. And it's just not true. And you may be hit with the feelings of genuine surprise and curiosity. My name is Madison Current. And I have a disposition as a chronic learner. I work at Techstars. I work at Techstars with some of the hottest early stage startups nationwide. And we, the hottest early stage startups nationwide, and we are constantly learning. The growth mindset is essential for continuing improvement and innovation, especially for developers because our knowledge has a much shorter half-life than the knowledge acquired by experts in other professions. Discovered and defined by Carol Dweck, the growth mindset is a belief that ability can be developed through dedication and hard work. This view creates a love of learning and a resilience that is essential for great accomplishment. Dorothy D. Billington, the author of Life as an Attitude, said, we either continue to learn throughout our lives or we allow our skills and our knowledge to quickly slide into obsolescence. You may remember the cartoon from yesterday's keynote talk, and I am here to ensure that you do not slip into obsolescence. There is a way that you can rearrange your thinking that will help you become a better learner and a better programmer. Here's how. First, we'll take a look at some theory and experiments that highlight keys to learning effectively. Then, I'm going to show you, then I'm going to look at a story, my new story, and show you these strategies in action. Strategies such as the zone of proximal development and scoping a problem, pattern matching and building a mental model, and metaphor, and how they can be used by you to learn more effectively. And learn some of the concepts that have been presented here and help you stay competitive as a developer. So let's start with the neuroscience lesson. I'll start with the drafus model. This describes how our abilities, attitudes, capabilities, and perspectives change according to skill level. Now this is scope to be a very specific skill. So for an example, you may be an expert at Ember routing, but not an expert at Ember at large. This is why it's so important to be continually learning new concepts, especially as a developer. The drafus model demonstrates five distinct ability levels. The most notable shift in skill level is the difference between proficient and expert level skills. Now, the reason why this is so important is because it's a shift in the way we think. Andy Hunt in programmatic thinking and learning summarizes it well. When he says, you don't just know more or gain skill, instead you experience fundamental differences in how you perceive the world, how you approach problem solving, and the mental models you form and use. A good way to think about this difference is that a proficient level developer will see the details of a single tree while an expert will see the entire forest and see the system of that entire forest. So what's at the root of this? Pun intended. Oops. Intuition. There are many scientists who have, sorry, intuition. And intuition is the ability to understand something without the need for conscious reasoning. And this differentiates expert versus proficient level developers and the skill levels and other applications. Now there have been scientists who have studied this at length and contributed to the theory that meaning and intuition are the core to effective learning and problem solving. I'm going to start with Adrian DeGroote. Adrian DeGroote was the first psychologist to carry out extensive experiments in problem solving. His subjects ranged from quite ordinary players to the strongest expert in the world. His topic? Chess. What he realized was that experts usually chose the strongest move while ordinary players often chose weaker moves. His question? Why were the experts able to do this? Assuming that wherein lay their chess skill. So to find out, he repeated an extended experiment that had been done in the USSR where he showed a chess board that was from a real chess game to players for about two to ten seconds. And asked them to place those pieces and remember where they were initially and replace them on the board afterwards. Now again, it's important to remember that these are from real chess games. That'll come into play in a minute. His results were pretty dramatic. What he found was that from expert level to novice, that experts could replace with 93% accuracy 25 pieces. Whereas amateurs only 14 and novices only eight. Now Hubert A. Simon and William G. Chase extended and repeated this experiment. Now the way that they extended it is that they chose randomly placed pieces on that chess board and did the same. So they showed it to a variety of skill levels for two to ten seconds. Now their results were very different. No matter what the skill level, these players could only accurately place three to four pieces back on that chess board. Theresa Marschik and her TED Talk Don't Believe Everything You Think summarizes it perfectly. In order to retain information, we have to organize it in a way that is meaningful. We have to make connections to it. Connect it to our experiences. Coming up with our own examples or thinking about how separate subject matters relate to one another or to what else we know. This is how we remember it. And this becomes our intuition. Okay. Last theory, the zone of proximal development. The zone of proximal development is defined as a difference between what a learner can do without help and what he or she can do with help. So, now that you guys have a good understanding of some of the neuroscience behind problem solving and found that it's rooted in intuition and meaning, we're going to extend your zone of proximal development. And if you're willing, we'll dive into my beginner story and I will show you how I rearranged my thinking in order to become a better learner and a better programmer. I can assure you that the story is not void of struggle. Actually it revolves directly around it. Ten months ago, I was truly a noob. Just to give you an example, I'm going to tell you a story. I was essentially floating on the surface of the ocean, not even slightly aware of the death that lay beneath me. I started Turing School for Front-end Engineering and about a week in, during those couple days, I found out what a terminal was. So at that point, I felt like I had just figured out a secret to the world. I remember calling my dad and channeling all of my excitement into the question, do you know that there's this thing called a terminal? His response, duh, you didn't know that? That was my face. I was quite disappointed and needless to say, I did not impress him. I was truly a noob at programming. So this begins my story with Ember. Now I'm going to tell you a story that centers around the zone of proximal development and I'll explain that concept a little bit more in depth. This story is not a story of an imposter syndrome. The story is a story of being an imposter. I was walking through the doors of my first Ember meetup and the thoughts that were going through my head were not as excited as you might think. Honestly, being somewhat of an introvert and a noob at the same time, I was calculating to see if anybody would notice if I literally turned around and sprinted away. But the odds were not in my favor. So I did the opposite. I leaned in. I sat next to the smartest person I could find and I asked him a million questions. Seriously, imagine coding with a two-year-old looking over your shoulder thinking, why this is not working? How does this work? What is this doing? Why did you put that dash there? I don't understand. That's where I was at in my developmental stage for programming. You know, he was so generous with his time and I regret to say that a lot of what he taught me, although it made logical sense, just didn't stick. Now four months later, I can tell you why. At that point in four months later, I had learned vanilla JavaScript. I had practiced with object-oriented programming and I had built a React Redux app before I looked back and revisited Ember. Now a close friend of Turin had come, made a new video you may know, Brandon Hayes, and drew this diagram for me. Although it may look like a chicken scratch, it made a lot of sense and for me, explained how Ember worked. This is a classic story of it's not you, it's me. In the first example, you can see that there was hours of time poured in to explain a complex topic, but I was not there in my developmental stage. A couple months later, I was. My zone of proximal development had expanded to be, to overlap with Ember, so it was much easier for me to grasp. So again, a quick refresher of the zone of proximal development. It is the difference between what a learner can do without help and what he or she can do with help. Like I said, my zone of proximal development increased over time enough that I could learn Ember without as much effort. Dorothy D. Billington, who I mentioned before, explains this well through the idea of optimal pacing. She says, optimal pacing is challenging people just beyond their present ability level. So what this was is that I was not connecting these concepts to meaning or intuition. So when you're choosing a new topic to learn and take on, something that maybe you've learned here, make sure that it's inside of your zone of proximal development. This is also really important when you're teaching somebody else to recognize where theirs is. Okay. Next new story. You ready for another failure? This one revolves around pattern matching and mental models. So I was building my first Ember application and I had been super excited after knowing many people from the community and hearing awesome things from my instructors. I had all the appropriate packages installed and I wrote Ember new wellness challenge in order to create a wellness app because I'm from Boulder and can never have too many wellness apps, right? This is what I got. It was quite overwhelming and had really no idea what to do. So I hit the docs. I listened to countless podcasts and I asked upwards of a billion questions. And as a method that most people recommend, I hit my head against the wall more times than I can count. The results were not pretty. That's spaghetti. That's my code. But after trial and error, patterns emerged. Let me show you one that was super notable and helped form my understanding of how Ember works. I started with Ember generate route dashboard which created a route inside of my router. It created a dashboard file inside of my routes folder and also created a dashboard file inside of my template folder. Now there's a pattern here but I didn't recognize that when I was first learning. Everything is equally nested. This may seem simple as an expert but as a beginner, this is really confusing. So when I started, I did something a little bit more like this. Now this code doesn't actually run because the patterns don't match. Should look something a little bit more like this. But the dashboard is nested inside of the home route. As you can see, there is a clear pattern between the ways that these files are nested. And coming from a background in React, I thought you had to explicitly define where the files were coming in from. But Ember does that magic for you. That was unclear to me when I first started. What I found out is that file structure matters. This is an example of pattern matching. Pattern matching is to correlate models or designs to use as a guide. So this draws directly in to what my mental model looks like. My mental model is actually a checklist. And this is the way that I implement new features when I'm coding an Ember. I run through the mental checklist to make sure that I've not missed anything. Now this mental checklist can change slightly, obviously, based on the type of feature that I'm adding. But for me, it's just this groundwork to then be able to build off of in order to understand some of the complex topics in Ember more deeply. Let me show you an example of a feature that's implemented using this checklist. First, we're going to start with our router. Now our files aren't nested anymore. And as you can see, we added a new route dashboard. Next, we're calling in our route. This is where we're calling in our data, all of the tasks, and we're connecting it to our model. Next, we're defining our data schema. Here each task has a student name, a date associated, and whatever type of task, whether that was done or not on that day. Then I'm going to my parent template. Here you can see that I'm rendering a child component. And as is important, and I'll tell you in a moment, I'm including the helper outlet. Last is my component. Now this looks a little bit messy, but what I'm using is the each helper to render each of my tasks in a list form. This was my mental model. A mental model is an explanation of someone's thought process about how something works in the real world. Now mental models may not look the same for everybody, but for me, this is how I understood Ember when I was first learning, and I had built this model through pattern matching. So every time I'm adding a new feature, I use the same mental model with slight variations, and I use pattern matching from the types of files, and use them to add that feature. Okay. Next story, this one's around metaphor. And like any good text story, the story begins in a basement. I was coding my third Ember application, and this was not any application or any old day. This was for my final assessment, and the stakes were high. But I was ready, and I was cruising. I had already implemented three-fourths of the requirements, had set up my router, had persistent data, and had been abiding by TDD the entire time. Now I was adding an update feature to my list items, and I had all of the files set. So I ran it and nothing. Crap. Okay. Positive attitude. I tried, and I tried again. Two hours later, the feature was still not working. Three candy bar wrappers, a Red Bull can, and my self-esteem were all in the trash. Along with my hopes of becoming a real developer. After beating my head against the wall, I quickly copied over all of the relevant files into Slack for my instructor and begged and pleaded for his help. Before I could even copy over the last file, his message came across the wire. Did you include the helper outlet? No. If you don't know what the outlet helper does, here's a quick explanation. The outlet helper lets you specify where a child route will render inside of your template. So as you can see through my checklist and mental model, this is the same feature that we're adding. And at the bottom, there's the outlet. So as you can see, the template acts as literally a plug or an outlet that allows other pieces to plug into it. So this is opened, other child templates or other child components. And I was rendering my component inside of that plug. So taking an observant perspective on the story, this is a clear example of the use of metaphor embedded into Ember to explain a complex topic. Metaphor comes from the Greek word meaning to transfer. And metaphor is imprinted into Ember's framework and provides implicit, well understood, real world examples from which we can transfer of terms to tangible objects. Metaphor means transferring the properties of one object to another in a way that is not literally possible. And metaphorical thinking is fundamental to programming. Clear metaphor is make it easier to learn, reason about, and extend code. Although all metaphors break down eventually, the idea is that a sufficiently rich metaphor can help guide the design and answer questions along the path to development. At this point, we've covered a neuroscience lesson that focuses on meaning and intuition. Then I've shown you a couple of effective learning strategies that worked for me that could also work for you to help build up that intuition when you were learning new concepts or and teaching some of the concepts that you're learning here. Continuous growth is essential for developers at all skill levels. Always remember to think like a beginner. There will always be new technologies to be to integrate, new decisions to be made, and new solutions to be found. There is a way that you can rearrange your thinking that sharpens your intuition so that you can become a better learner, a better programmer, and a better developer. Concepts such as functioning within your zone, a proximal development, recognizing patterns to build a mental model, and relating complex topics to metaphor are core learning techniques to build up your intuition. These tools will ultimately differentiate expert versus proficient level developers. Learning in our profession is a core element of success. These skills can be used to better understand and learn the features that you've learned here at Ember and help you become a better programmer and avoid obsolescence. Thank you.
 I'm here to present how to master Ember from the perspective of a noob.  And I'm going to start with a confession.  I am a noob.  And even more shocking, so are you.  You may be feeling slightly indignant about that statement, thinking, I didn't become  an expert in my craft just to be called a noob.  Or you might even be feeling slightly offended.  Who is this woman?  Honestly, it's kind of arrogant.  And it's just not true.  And you may be hit with the feelings of genuine surprise and curiosity.  My name is Madison Current.  And I have a disposition as a chronic learner.  I work at Techstars.  I work at Techstars with some of the hottest early stage startups nationwide.  And we, the hottest early stage startups nationwide, and we are constantly learning.  The growth mindset is essential for continuing improvement and innovation, especially for  developers because our knowledge has a much shorter half-life than the knowledge acquired  by experts in other professions.  Discovered and defined by Carol Dweck, the growth mindset is a belief that ability can  be developed through dedication and hard work.  This view creates a love of learning and a resilience that is essential for great accomplishment.  Dorothy D. Billington, the author of Life as an Attitude, said, we either continue to  learn throughout our lives or we allow our skills and our knowledge to quickly slide  into obsolescence.  You may remember the cartoon from yesterday's keynote talk, and I am here to ensure that  you do not slip into obsolescence.  There is a way that you can rearrange your thinking that will help you become a better  learner and a better programmer.  Here's how.  First, we'll take a look at some theory and experiments that highlight keys to learning  effectively.  Then, I'm going to show you, then I'm going to look at a story, my new story, and show  you these strategies in action.  Strategies such as the zone of proximal development and scoping a problem, pattern matching and  building a mental model, and metaphor, and how they can be used by you to learn more  effectively.  And learn some of the concepts that have been presented here and help you stay competitive  as a developer.  So let's start with the neuroscience lesson.  I'll start with the drafus model.  This describes how our abilities, attitudes, capabilities, and perspectives change according  to skill level.  Now this is scope to be a very specific skill.  So for an example, you may be an expert at Ember routing, but not an expert at Ember  at large.  This is why it's so important to be continually learning new concepts, especially as a developer.  The drafus model demonstrates five distinct ability levels.  The most notable shift in skill level is the difference between proficient and expert level  skills.  Now, the reason why this is so important is because it's a shift in the way we think.  Andy Hunt in programmatic thinking and learning summarizes it well.  When he says, you don't just know more or gain skill, instead you experience fundamental  differences in how you perceive the world, how you approach problem solving, and the  mental models you form and use.  A good way to think about this difference is that a proficient level developer will see  the details of a single tree while an expert will see the entire forest and see the system  of that entire forest.  So what's at the root of this?  Pun intended.  Oops.  Intuition.  There are many scientists who have, sorry, intuition.  And intuition is the ability to understand something without the need for conscious reasoning.  And this differentiates expert versus proficient level developers and the skill levels and  other applications.  Now there have been scientists who have studied this at length and contributed to the theory  that meaning and intuition are the core to effective learning and problem solving.  I'm going to start with Adrian DeGroote.  Adrian DeGroote was the first psychologist to carry out extensive experiments in problem  solving.  His subjects ranged from quite ordinary players to the strongest expert in the world.  His topic?  Chess.  What he realized was that experts usually chose the strongest move while ordinary players  often chose weaker moves.  His question?  Why were the experts able to do this?  Assuming that wherein lay their chess skill.  So to find out, he repeated an extended experiment that had been done in the USSR where he showed  a chess board that was from a real chess game to players for about two to ten seconds.  And asked them to place those pieces and remember where they were initially and replace them  on the board afterwards.  Now again, it's important to remember that these are from real chess games.  That'll come into play in a minute.  His results were pretty dramatic.  What he found was that from expert level to novice, that experts could replace with 93%  accuracy 25 pieces.  Whereas amateurs only 14 and novices only eight.  Now Hubert A. Simon and William G. Chase extended and repeated this experiment.  Now the way that they extended it is that they chose randomly placed pieces on that  chess board and did the same.  So they showed it to a variety of skill levels for two to ten seconds.  Now their results were very different.  No matter what the skill level, these players could only accurately place three to four  pieces back on that chess board.  Theresa Marschik and her TED Talk Don't Believe Everything You Think summarizes it perfectly.  In order to retain information, we have to organize it in a way that is meaningful.  We have to make connections to it.  Connect it to our experiences.  Coming up with our own examples or thinking about how separate subject matters relate  to one another or to what else we know.  This is how we remember it.  And this becomes our intuition.  Okay.  Last theory, the zone of proximal development.  The zone of proximal development is defined as a difference between what a learner can  do without help and what he or she can do with help.  So, now that you guys have a good understanding of some of the neuroscience behind problem  solving and found that it's rooted in intuition and meaning, we're going to extend your zone  of proximal development.  And if you're willing, we'll dive into my beginner story and I will show you how I  rearranged my thinking in order to become a better learner and a better programmer.  I can assure you that the story is not void of struggle.  Actually it revolves directly around it.  Ten months ago, I was truly a noob.  Just to give you an example, I'm going to tell you a story.  I was essentially floating on the surface of the ocean, not even slightly aware of the  death that lay beneath me.  I started Turing School for Front-end Engineering and about a week in, during those couple days,  I found out what a terminal was.  So at that point, I felt like I had just figured out a secret to the world.  I remember calling my dad and channeling all of my excitement into the question, do you  know that there's this thing called a terminal?  His response, duh, you didn't know that?  That was my face.  I was quite disappointed and needless to say, I did not impress him.  I was truly a noob at programming.  So this begins my story with Ember.  Now I'm going to tell you a story that centers around the zone of proximal development and  I'll explain that concept a little bit more in depth.  This story is not a story of an imposter syndrome.  The story is a story of being an imposter.  I was walking through the doors of my first Ember meetup and the thoughts that were going  through my head were not as excited as you might think.  Honestly, being somewhat of an introvert and a noob at the same time, I was calculating  to see if anybody would notice if I literally turned around and sprinted away.  But the odds were not in my favor.  So I did the opposite.  I leaned in.  I sat next to the smartest person I could find and I asked him a million questions.  Seriously, imagine coding with a two-year-old looking over your shoulder thinking, why this  is not working?  How does this work?  What is this doing?  Why did you put that dash there?  I don't understand.  That's where I was at in my developmental stage for programming.  You know, he was so generous with his time and I regret to say that a lot of what he  taught me, although it made logical sense, just didn't stick.  Now four months later, I can tell you why.  At that point in four months later, I had learned vanilla JavaScript.  I had practiced with object-oriented programming and I had built a React Redux app before I  looked back and revisited Ember.  Now a close friend of Turin had come, made a new video you may know, Brandon Hayes, and  drew this diagram for me.  Although it may look like a chicken scratch, it made a lot of sense and for me, explained  how Ember worked.  This is a classic story of it's not you, it's me.  In the first example, you can see that there was hours of time poured in to explain a complex  topic, but I was not there in my developmental stage.  A couple months later, I was.  My zone of proximal development had expanded to be, to overlap with Ember, so it was much  easier for me to grasp.  So again, a quick refresher of the zone of proximal development.  It is the difference between what a learner can do without help and what he or she can  do with help.  Like I said, my zone of proximal development increased over time enough that I could learn  Ember without as much effort.  Dorothy D. Billington, who I mentioned before, explains this well through the idea of optimal  pacing.  She says, optimal pacing is challenging people just beyond their present ability level.  So what this was is that I was not connecting these concepts to meaning or intuition.  So when you're choosing a new topic to learn and take on, something that maybe you've learned  here, make sure that it's inside of your zone of proximal development.  This is also really important when you're teaching somebody else to recognize where  theirs is.  Okay.  Next new story.  You ready for another failure?  This one revolves around pattern matching and mental models.  So I was building my first Ember application and I had been super excited after knowing  many people from the community and hearing awesome things from my instructors.  I had all the appropriate packages installed and I wrote Ember new wellness challenge  in order to create a wellness app because I'm from Boulder and can never have too many  wellness apps, right?  This is what I got.  It was quite overwhelming and had really no idea what to do.  So I hit the docs.  I listened to countless podcasts and I asked upwards of a billion questions.  And as a method that most people recommend, I hit my head against the wall more times  than I can count.  The results were not pretty.  That's spaghetti.  That's my code.  But after trial and error, patterns emerged.  Let me show you one that was super notable and helped form my understanding of how Ember  works.  I started with Ember generate route dashboard which created a route inside of my router.  It created a dashboard file inside of my routes folder and also created a dashboard file inside  of my template folder.  Now there's a pattern here but I didn't recognize that when I was first learning.  Everything is equally nested.  This may seem simple as an expert but as a beginner, this is really confusing.  So when I started, I did something a little bit more like this.  Now this code doesn't actually run because the patterns don't match.  Should look something a little bit more like this.  But the dashboard is nested inside of the home route.  As you can see, there is a clear pattern between the ways that these files are nested.  And coming from a background in React, I thought you had to explicitly define where the files  were coming in from.  But Ember does that magic for you.  That was unclear to me when I first started.  What I found out is that file structure matters.  This is an example of pattern matching.  Pattern matching is to correlate models or designs to use as a guide.  So this draws directly in to what my mental model looks like.  My mental model is actually a checklist.  And this is the way that I implement new features when I'm coding an Ember.  I run through the mental checklist to make sure that I've not missed anything.  Now this mental checklist can change slightly, obviously, based on the type of feature that  I'm adding.  But for me, it's just this groundwork to then be able to build off of in order to understand  some of the complex topics in Ember more deeply.  Let me show you an example of a feature that's implemented using this checklist.  First, we're going to start with our router.  Now our files aren't nested anymore.  And as you can see, we added a new route dashboard.  Next, we're calling in our route.  This is where we're calling in our data, all of the tasks, and we're connecting it to our  model.  Next, we're defining our data schema.  Here each task has a student name, a date associated, and whatever type of task, whether  that was done or not on that day.  Then I'm going to my parent template.  Here you can see that I'm rendering a child component.  And as is important, and I'll tell you in a moment, I'm including the helper outlet.  Last is my component.  Now this looks a little bit messy, but what I'm using is the each helper to render each  of my tasks in a list form.  This was my mental model.  A mental model is an explanation of someone's thought process about how something works  in the real world.  Now mental models may not look the same for everybody, but for me, this is how I understood  Ember when I was first learning, and I had built this model through pattern matching.  So every time I'm adding a new feature, I use the same mental model with slight variations,  and I use pattern matching from the types of files, and use them to add that feature.  Okay.  Next story, this one's around metaphor.  And like any good text story, the story begins in a basement.  I was coding my third Ember application, and this was not any application or any old day.  This was for my final assessment, and the stakes were high.  But I was ready, and I was cruising.  I had already implemented three-fourths of the requirements, had set up my router, had  persistent data, and had been abiding by TDD the entire time.  Now I was adding an update feature to my list items, and I had all of the files set.  So I ran it and nothing.  Crap.  Okay.  Positive attitude.  I tried, and I tried again.  Two hours later, the feature was still not working.  Three candy bar wrappers, a Red Bull can, and my self-esteem were all in the trash.  Along with my hopes of becoming a real developer.  After beating my head against the wall, I quickly copied over all of the relevant files  into Slack for my instructor and begged and pleaded for his help.  Before I could even copy over the last file, his message came across the wire.  Did you include the helper outlet?  No.  If you don't know what the outlet helper does, here's a quick explanation.  The outlet helper lets you specify where a child route will render inside of your template.  So as you can see through my checklist and mental model, this is the same feature that  we're adding.  And at the bottom, there's the outlet.  So as you can see, the template acts as literally a plug or an outlet that allows other pieces  to plug into it.  So this is opened, other child templates or other child components.  And I was rendering my component inside of that plug.  So taking an observant perspective on the story, this is a clear example of the use  of metaphor embedded into Ember to explain a complex topic.  Metaphor comes from the Greek word meaning to transfer.  And metaphor is imprinted into Ember's framework and provides implicit, well understood, real  world examples from which we can transfer of terms to tangible objects.  Metaphor means transferring the properties of one object to another in a way that is  not literally possible.  And metaphorical thinking is fundamental to programming.  Clear metaphor is make it easier to learn, reason about, and extend code.  Although all metaphors break down eventually, the idea is that a sufficiently rich metaphor  can help guide the design and answer questions along the path to development.  At this point, we've covered a neuroscience lesson that focuses on meaning and intuition.  Then I've shown you a couple of effective learning strategies that worked for me that  could also work for you to help build up that intuition when you were learning new concepts  or and teaching some of the concepts that you're learning here.  Continuous growth is essential for developers at all skill levels.  Always remember to think like a beginner.  There will always be new technologies to be to integrate, new decisions to be made, and  new solutions to be found.  There is a way that you can rearrange your thinking that sharpens your intuition so  that you can become a better learner, a better programmer, and a better developer.  Concepts such as functioning within your zone, a proximal development, recognizing patterns  to build a mental model, and relating complex topics to metaphor are core learning techniques  to build up your intuition.  These tools will ultimately differentiate expert versus proficient level developers.  Learning in our profession is a core element of success.  These skills can be used to better understand and learn the features that you've learned  here at Ember and help you become a better programmer and avoid obsolescence.  Thank you.
Mastering_Ember_from_the_Perspective_of_a_N00b_0_515.png Mastering_Ember_from_the_Perspective_of_a_N00b_516_1907.png Mastering_Ember_from_the_Perspective_of_a_N00b_1908_1979.png Mastering_Ember_from_the_Perspective_of_a_N00b_1980_2975.png Mastering_Ember_from_the_Perspective_of_a_N00b_2976_9983.png Mastering_Ember_from_the_Perspective_of_a_N00b_9984_10463.png Mastering_Ember_from_the_Perspective_of_a_N00b_10464_10979.png Mastering_Ember_from_the_Perspective_of_a_N00b_10980_12515.png Mastering_Ember_from_the_Perspective_of_a_N00b_12516_13619.png Mastering_Ember_from_the_Perspective_of_a_N00b_13620_14207.png Mastering_Ember_from_the_Perspective_of_a_N00b_14208_14843.png Mastering_Ember_from_the_Perspective_of_a_N00b_14844_15215.png Mastering_Ember_from_the_Perspective_of_a_N00b_15216_16319.png Mastering_Ember_from_the_Perspective_of_a_N00b_16320_16487.png Mastering_Ember_from_the_Perspective_of_a_N00b_16488_17963.png Mastering_Ember_from_the_Perspective_of_a_N00b_17964_19007.png Mastering_Ember_from_the_Perspective_of_a_N00b_19008_19079.png Mastering_Ember_from_the_Perspective_of_a_N00b_19080_20699.png Mastering_Ember_from_the_Perspective_of_a_N00b_20700_22343.png Mastering_Ember_from_the_Perspective_of_a_N00b_22344_28067.png Mastering_Ember_from_the_Perspective_of_a_N00b_28068_28439.png Mastering_Ember_from_the_Perspective_of_a_N00b_28440_28691.png Mastering_Ember_from_the_Perspective_of_a_N00b_28692_29099.png Mastering_Ember_from_the_Perspective_of_a_N00b_29100_29579.png Mastering_Ember_from_the_Perspective_of_a_N00b_29580_30935.png Mastering_Ember_from_the_Perspective_of_a_N00b_30936_34439.png Mastering_Ember_from_the_Perspective_of_a_N00b_34440_35831.png Mastering_Ember_from_the_Perspective_of_a_N00b_35832_36251.png Mastering_Ember_from_the_Perspective_of_a_N00b_36252_36491.png Mastering_Ember_from_the_Perspective_of_a_N00b_36492_36647.png Mastering_Ember_from_the_Perspective_of_a_N00b_36648_36673.png