050: Learning to Program with Kyle Simpson

Kyle Simpson: @getify | Blog | GitHub | getify@gmail.com

Show Notes:

• 04:19 - Styles for Learning as a Newcomer
• 08:41 - The Structure of the Journey

“If you’re waiting until you’re already an expert on a thing to share it with somebody else, you’ve waited far too long because we missed out on the most important part which was the journey.”

• 12:52 - Understanding a Problem vs Solving One

"I want to inspire people to be uncommonly curious."

• 29:02 - How do you know when to stop?
• 35:02 - Knowing Math and Learning Programming
• 43:40 - The Importance of Mentorship

Resources:

• LABjs
• The JavaScript Austin Meetup
• Pedagogy
• Saron Yitbarek (CodeNewbie): I don’t belong in tech: Trying to find my place in the place I love, and constantly failing
• Dr. Seuss' The Sneetches (Star-Bellies Reference)
• Big O Notation
• You Don't Know JS: A Book Series
• Functional Light JavaScript
• Kyle's Frontend Masters Training Videos

Transcript:

CHARLES: Hey, everybody and welcome to the Frontside Podcast episode 50. I'm your host, Charles Lowell. With me, also from the Frontside, is Stephanie Riera. And with us today is a very special guest, Kyle Simpson, a fellow Austinite. We're going to talk about education and teaching JavaScript.

You hear this name everywhere you go. I remember when I first moved to Austin, back in 2009, I moved back to Austin, I went to my very first JavaScript Meetup and there was this guy sitting there doing some live coding on this crazy thing called LABjs which was just like mind-blowing stuff that was going on that was doing crazy on-the-fly modules floating. And this was like back in 2008/2009, so awhile back. And that was my first experience. And then just moving inside tech circles, he just like popped again and again and that’s just like the story. It seems like Kyle is like ubiquitous.

I was at Clojure Conf last weekend and one of the speakers actually gave a shout-out to Kyle Simpson. So, I don’t know Kyle if you do much Clojure, but you definitely have an impact, an outsized impact in the JavaScript community and outside the JavaScript community at large, all throughout tech.

It's really a pleasure to get to have you on the show. So, welcome Kyle.

KYLE: Thank you so much. It’s a huge honor to be here. I'm glad to be doing this in our home city of Austin. It's fun to actually get a chance to pull again with the Austin community because a lot of my work takes me on the road. I sometimes joke that I know more about JavaScript communities in other cities than in my own since when I'm home, I'm usually with the family. And when I go to meetups, it's usually in other cities. But it's fun to be here.

It's interesting you bring up that JavaScript Meetup, the original Austin JavaScript Meetup. It started in January of 2009. Actually Joe McCann, most people will know that name. He's kind of a rockstar in the Node community and one of the founders of NodeSource. I think he's up in New York City now. But he started the Austin JavaScript Meetup in January. February, I started kind of came on and we ended up kind of tag teaming running that meetup for the next couple of years.

In the early days of that, you're talking about LABjs, I remember that was summer of 2009. The early days of starting up a meetup when you have 5 or 6 attendees on a really good night, mostly consists of about a week before the meetup, "Oh, we don’t have a speaker. One of the two of us has to figure out something to speak about." So, I would often kind of take on that task and I would say, "Okay, what's something I'm interested in," or, "What's a library I could write that I could talk about something when I was coding?"

CHARLES: So that actually born out of the need to actually present something at the Austin JavaScript Meetup?

KYLE: Yes, actually LABjs, it was something at work at that time that I was trying to solve but I wasn’t really making a library out of it. It was just some code that I was toodling around with. I was like, "Wow, crap! It's 3 days before the meetup. I better come up with something to talk about."

So I wrote the very first version of LABjs to present at that meetup and I got a bunch of good feedback from people that were looking at it and saying, "Oh, that’s cool." So I kind of ran with it. That’s literally my first kind of major open source project. Most people probably originally heard of me if they’ve been around the tech world for a while, they originally heard of me because of that one.

CHARLES: Wow! I had no idea I was there.

KYLE: You were there for the origination. I was the unveiling to the world of LABjs.

CHARLES: It's like the Woodstock of JavaScript.

KYLE: Those were some early days of meetup stuff. You're like pick up a pizza and a couple of beers from the store on the way to the meetup and there wasn’t a lot of organization but we had a lot of fun. Now, the Austin JavaScript Meetup 6 or 7 years later is, it rocks! There's 50 or 60 people every single month that attend. There's been several change-overs of leadership over that couple of years but it's still fun to think about kind of helping Joe get that off the ground way back in 2009.

CHARLES: Yeah, that was fantastic. You’ve been in it a long time and that actually kind of brings me to one of the things that I'm curious about is you’ve been doing this for a long time. You’ve been writing JavaScript for a long time and yet you're very much connected to the Day 1 learners and the people who were coming in just kind of from at the very bottom floor. And one of the things that I find in my interactions with the people who are starting out or people who are beginning is that it can be very difficult to know what's appropriate to teach a style that’s effective or teaching them because you don’t have that empathy of you're so far removed from the experience, that struggle and that challenge of really clawing your way into programming. And yet that doesn’t seem to be an issue for you or maybe it is. I'm just curious, one, do you perceive that as something that you have to deal with and how do you do it?

KYLE: I would say that part of the way that I'm able to keep a pulse or a finger on what it’s like to first start learning something comes from my own learning style which is that I, to learn a thing, I can't follow tutorials. As a matter of fact, every time somebody comes up with a new major awesome tool or framework and they put out this great tutorial and everybody raves about it, I secretly have that huge flare up of impostor syndrome because I know that I will feel really dumb if I try to go through a tutorial and learn it in that fashion. That’s just not how I learn stuff. The way I learn stuff is very, very slow and methodical. It generally is taking a thing apart and trying to figure out what each of the different pieces is doing, understanding at that deeper level, and then reassembling the pieces.

The reason I mentioned that is because I like to describe my process of teaching and I really think this generalizes to people beyond me that it's my process. I think that my process for teaching is just to have a narrative journey and that it's all about a process. It's not about a single event because I don’t think that learning is transactional or I don’t think it should be. I think learning should be a process.

And so, for me, that process starts with an initial thing that I'm looking at. I get an idea of what it’s about, the problem domain that it's in. I probably develop an instant sense of 'ooh, I don’t really like that' or 'ooh, that’s kind of interesting'. But if I'm going to learn a thing, it's not going to come through a tutorial. It's not going to come through reading a Read Me and being like, "Okay, I'm good to go," and I can sort of copy and pasting. For me, it's going to take, in some cases, reinventing parts of it as I put those pieces back together so I can really understand the choices that were made. I do a lot of reading of somebody else's source code.

As an example of this ongoing journey that I'm learning, I was recently at a conference and I heard a discussion of Redux. And of course, Redux is something that tens of millions of people, I mean everybody seems to be an expert on this stuff and I don’t know Redux. I don’t know React. I don’t spend a lot of time at that layer of the stack. But I was listening to a talk and I was thinking, "Well, that sounds interestingly similar to the stuff that I was playing around with back in 2010." It's kind of event oriented and single source of truth for the model and stuff like that. "That’s cool. I should go and learn that more." So, that’s on my pretty near future to-do list to kind of learn stuff. And there's a really good chance that that process, that journey that I go on to learn about Redux is going to spin off at least some sort of code that I play around with, whether that’s using Redux or writing something kind of like Redux to show off how I've been thinking about the idea. And then I’ll probably write about it. I know for sure that I'm going to be mentioning it in one of the chapters of my current book on functional programming. So, I'll be talking about it, at least a little blurb about how it fits into the overall scheme of things.

And then probably eventually once my journey has gone a little bit further, eventually there'll be some kind of class that I spin up in a module or in one of my classes that I talk about Redux and where that comes from. And that’s not because I've been on the high training. As a matter of fact, it's the opposite. I'm the latest adaptor for most of these things but that is a very long slow methodical process for me to learn something and then turn around and try to teach it to other people.

CHARLES: Is the idea then that you want to kind of share that journey that you’ve taken or try to encourage the next learner to take a similar or different journey? How do you structure that learning once you do decide to package it up?

KYLE: The structure of the journey -- I think that’s an interesting way of articulating the question. What is the structure of the journey? And I would say that the structure of the journey generally, from my perspective, starts from understanding a concept, the why behind the concept, what is the problem I need to solve, and what is motivating solving the problem. And then it moves into the how are we going to do it, what are the possible ways to do that, and that really is the part of that process that you spend most of your time digging into and understanding the deeper level of the thing. So, not just using the library but understanding really how it does it and the choices that it made. And then it moves to the what. And that is inverted from the way most people's learning seems to go about because people learn most typically by, "I find the cool thing because it was in some newsletter that I read about. It seems like it would help on my job project, so I dropped the thing in, put in a couple of the snippets from the Read Me and it's working great, and maybe someday later, I'm going to go back and dig into it a little bit." I'm completely reversed.

So, that’s my structure for learning and I recommend that people, at least from time to time, take a similar path. It doesn’t have to be exactly that way, but take a similar path to breaking down the learning. I'm sure as we go along in this discussion, I'll be able to elaborate on that more. I don’t want to just churn on and on forever. But I really do think it's important for people to dig in deeper.

So my process is that and the way that I teach is to take people on that journey with me. The way that I teach is to say, "This is the journey that I'm going through. This is the stuff that I understand."

For the listeners that aren’t teachers, there's some interesting -- I don’t want to get too much into the weeds about teaching -- but there's something interesting about teaching. There's this fancy word called Pedagogy which is not the thing that you're teaching but the strategy that you want to use to teach it, the narrative that you want to take a person through. And I spend an awful lot, probably more of my time thinking about that than about the topic itself. So, my practice is to use a lot of silly metaphors. Like I'm teaching promises and I talk about future cheeseburgers and stuff for those that have read or heard from me before, they’ll know the future cheeseburger. I use silly stuff like that because this stuff can be really dry and difficulty and I want it to stick in your head. I want the how to stick in your head.

So, I invite other people. That doesn’t mean that you have to take the entire journey that I did to learn a thing, but I really want to inspire people to learn at that level to be uncommonly curious. And I hope that when they see that I've done it and that I'm transparent about how my process works, I hope it inspires other people.

CHARLES: Yeah, and I think wrapped-up in that is tied back to my usual question is because you yourself are in fact you're going through this process, it's very easy then to empathize people who are going through the same process. I really like that.

KYLE: And I think everybody should look at the process of getting up to speed on the thing as an opportunity to go on that journey and to document and share that journey with others. You don’t have to have the word 'teacher' in your job title to be a teacher. I think all engineers should be seeking to go outside of themselves and to explain things, if for no other reason than the purely selfish reason which is you learn it better by re-explaining it to somebody else, but all boats will rise with the tide. And so, I have taken, for years now, the perspective every time I learn a thing, I'm going to turn around and share it with somebody else. It's exactly the same thing that’s interesting and almost ironic that we started our discussion today about that meetup and about LABjs. I was learning a thing and figuring out a thing and I turned around and shared it with other people and it turned out to make an impact. But the impact isn’t the important part. The important part was the journey, it's not the end goals.

I was always tell people, "If you're waiting until you're already an expert on a thing to share it with somebody else, you’ve waited far too long because we missed out on the most important part which was the journey."

STEPHANIE: Kyle, you touched on something that I wanted to ask you about. You talked about the first phase being understanding a problem, and then the second one being how do we fix this. And last week, I believe, CodeNewbie has her own podcast. And she released a post on Medium and it's called 'I Don’t Belong in Tech'. And she talks about how her instinct is to understand the problem versus solving it. It seemed like she feels she is an outcast in the tech community because most people are really excited about solving problems and she doesn’t feel like she is solution-oriented. And I kind of wanted to ask you, is that the case? Do you think the people that excel in programming are people that are just naturally excited about solving problems? And if that’s not the case, then what do you recommend for people that may not think in that fashion, they don’t intuitively feel like solving problems and they feel like they approach it in a different manner? It seems like people have different learning styles.

KYLE: I agree completely that people have different learning styles. And that question you just asked is so rich with so many things to mind. So, I'm excited to dig into that a little bit.

I 100% agree that people have different learning styles and I think that it is why it is important for there to be people in the community who are spending their time and attention thinking about teaching and about improving educational processes. I do not think that curriculum teaches itself.

And I'm somewhat suspect of the movement that we have as an industry towards almost praising or taking it as a badge of honor the label of self-taught. It's almost become its own cult that you're a self-taught person versus somebody who came through it from a more traditional path where a person was carefully thinking about how to present to you and how to teach you whether that was at a university or a tech school or mentorship or any of the others. People that are self-taught often wear that as a badge of honor. It's almost a rite of passage that you got to a level of understanding and experience and expertise because you boot strapped yourself up as opposed to the more top-down approach.

And I am suspect of whether or not that’s healthy for us to suggest to people that there are these two factions. It's kind of like the old Dr. Seuss book of the star bellies and the non-star bellies. I have the star belly because I got my Computer Science degree. And if you know that book and if you don’t know the book, you should go look it up. But what happens in the book is at some point, there's a flip and now the people with stars are the excluded ones and the people without aren’t.

So I don’t think it's healthy for us to promote the idea that we need two entirely different approaches that there's a person who can only be a self-taught and that’s a thing, and then there's a person who gets more formal education. I really think it's important for people to spend time thinking about how stuff should be presented and not just throwing information out there for people to learn themselves.

This is kind of a crazy metaphor. But if you had a one or two year old kid and you wanted them to learn to swim, the developer mindset often says, "Well, just throw them in the deep end and they’ll figure it out." But that isn’t how we actually would teach them to swim. We would be very, very patient, very, very cautious with them. We'll start with the shallow end, there being an adult there and they would guide them through that. And I think there's virtue in having some of your learning even if you're one of those listening that does value the whole self-taught thing or that has worked for you in the past. I think there's also value in people going through a more formalized process. Like I said, there's lots of different channels for that modality. But I think the formalized modality has value to it. And of course, that’s what I spend my time thinking about.

I put out a lot of information - my books and my training videos. There's a lot of that material available for people to self-teach but I really hope that what that does is not encourage people to stay disconnected but rather, to attract people to create relationships around learning because I think relationship-based learning is the most effective modality for leaning. And we've proven that for thousands of years in lots of other parts of society, but we haven’t really taken that to heart in the developer world, and I think we need to more.

You're right, going back to the original question that there are lots of different ways that people learn. I know CodeNewbie. What's interesting about that premise, I share a similar perspective on those that want to learn to solve a problem versus those that want to learn to figure out how to solve problems.

I have a statement that I make which I will preface with I understand that sometimes it can be a little bit off but I hope that listeners will take this from the spirit that I'm trying to give it in. I think that one of the things we can do is begin to think a little bit more about what we're doing even though all of the other structure and process scaffolding around us incentivizes and encourages the opposite.

I think what we see is that the developer-oriented mindset typically is more interested in first solving a problem and maybe later understanding it. Whereas I think the engineering mindset -- for lack of a better label, I'll call it the engineering mindset. That’s my bias because I came up through a more traditional engineering CS degree. But I think the engineering mindset, the one that most people would say is heavily focused on problem solving and that kind of thing. I think the engineering mindset seeks first to understand the problem and maybe later solve it.

If you have developer mindset that wants to solve a problem without really fully understanding it, I think one of the outcroppings of that is the churn that we see in the development community. We see people constantly every two or three years trying to go recreate a whole new stack of things because we're saying, "We need to do this thing differently." And I have seen that cycle four or five times in my career.

And so, I can say with pretty strong certainty right now that somewhere in the world, there is a guy or a girl that is a 16 year old that is working on what is going to eventually replace React. I don’t know what it is, I don’t know who the person is, but I'm pretty sure that we're at some point going to say, "Wow!" And when that shift happens, we're going to come back and think to ourselves, "How could we have ever thought that React was the most amazing thing in the world," and we very quickly forget.

So, one of the outcroppings is that continuing cycle because people are seeking to fix problems as quickly as possible and not everybody takes the time to really think about it. The authors of those tools, they think really deeply about these problems. They think so deeply about them. I am amazed the kinds of thought that goes into creating one of those frameworks or libraries. And I have a lot of deep respect to the Ember community, the React community, the Angular community. Those people spend a lot of time thinking about those problems. But the people that use them, use them as tools to get their job done honestly and earnestly so. But they very rightly focus on what can I get done with React rather than 'can I understand what React is really trying to do and use it to its best ability'. And we incentivize that. We incentivize that by saying that the people that advance at work, the people that become the senior developers at work are more likely the people that shipped more code. They're more likely the people that closed more bugs.

And one path to getting there is you're just a really quick coder or you're one of those mythical unicorn 10x developers. But a lot of people aren’t. I'm certainly not. I am not a fast developer. I'm one of the slower developers. I am very, very careful about what I write. So, I can't survive in that environment where I have to advance because I can write code quickly. Rather for me to survive in those environments, I advance or up my stature, if you will, because I understand the thing deeper than anybody else.

And I think there's places in the workplace for both, so I'm not disparaging those that write a lot of code quickly. But one of the outcroppings of writing code quickly if jumping as quickly as you can to solving a problem, is that you often times find a local maximum. A mathematic theory about -- just visualize a curve kind of like the landscape of hills. If you're climbing a hill as quickly as possible and you get to the very top of the hill, it might not have been the tallest hill that you could have climbed. But you got to the top of the hill really quickly and you got the next promotion, you went on to the next thing. So, I think those value.

Sometimes in your career and some people in the community who want to take a step back and understand a thing deeper, dig into a thing deeper, and I encourage people to have that as part of their toolset, that they would be that uncommon level of curiosity. Take a moment and by a moment I mean a couple of months, maybe a cycle at most of six months, take a step back from the just everyday churn of shipping a feature and fixing a bug and making the button blue, take a step back and say, "What are some of the things that I have been touching or I have been hearing people talk about," and dig into that thing and learn it. And learn it really deeply and really understand it, and maybe reinvent it if you need to. But really deeply get it. And then kind of resurface and look around and say, "All right, let me find the next thing."

And so, I think those cycles are healthy for people. And I think the engineering mindset should be something that each of us strives to adopt at least some in the workplace as opposed to being almost drunk on the idea that the best developers among us are the ones that ship code the quickest.

CHARLES: I think also too there is like if you do take the time and you then make that investment upfront, it engenders a lasting speed. In the same way that if you look at a child taking its first steps which is kind of the initial solution of a problem, it takes intense concentration. And it takes all the muscles or trembling and stuff just to coordinate the balance to take those first steps. But then once the child kind of understands the process fully -- like none of us, at this point in our lives, think about walking. It's just something that we do naturally.

But because the human brain is wired at that point to take whether it's walking or any other kind of motor skills to really understand the motion and rewire the brain optimized for that motion so that it becomes second nature, so that you benefit from that again and again and again. And I feel having spent a long time in the industry seeing the speedups that can actually be gained by doing it slow. In other words, you expand that understanding to fill the room and then the door is only a few millimeters away, if that makes any sense.

KYLE: I think it does. And I think for those that are listening just to address what questions may be popping up in people's heads because as a teacher, you learn to anticipate questions ahead of time.

So I can see, even from our discussion so far, that somebody may be asking, "Okay, you're talking about some really nice theory here, but what about the practicality of it? What are the benefits of the thing? I don’t have time to go learn React but I can get my job done by applying React to my business process." So, I think there are some practical things that we can point to that that come from being that uncommon level of curious, that deeper and slower and more methodical learning.

One of those, I'd like to say -- and people always kind of smirk at me when I say this -- I call them getify's laws. They're just statements that I make. They're statements of my opinion and really the only thing that I'm an expert on is my own opinions and I'm never at a lack for those. It's just an opinion but I believe that you can't hope to solve a problem if you don’t first understand it. Or to put another way the getify's law - if you don’t understand why a piece of code works, you have no hope of understanding why it broke and how to fix it.

So we do a lot of code that works and we don’t know why. I would say probably the majority of code that gets shipped were just sort of only kind of tenuously understand it. And sometimes it's really tenuous. Sometimes it's house of cards development where you build a thing and you're not really quite sure why it works but you put a comment there that says 'don’t touch this' and 'don’t break it' or whatever. And then we back away and hold our breath and hope that it stays in place. That is a way to ship code quickly.

The agile mindset has permeated so deep down that on every line of code we're thinking [inaudible], we're thinking, "Just get the thing working and get the test passing and then we'll worry about whether it's the appropriate way to solve the problem. We'll worry about that later." Many times we don’t get a chance to worry about it later until there's a fire, until something's broken. And that fire could be that bug or that brokenness could be it's not doing what it's supposed to do or more often, that fire is it's doing it but it's impossibly slow, it's impractically slow. And now, we have to go back and think, "We thought we only had five pieces of data to ever work with, but now we have 50,000 and the algorithm completely falls apart. We can't do an [inaudible] scan anymore," or whatever.

So that very narrow myopic short term mentality can be effective for people to get stuff shipped and to advance in their jobs, but it falls apart when things start breaking. If you're talking about a car and you said, "I don’t need to know how a car works, so I can just drive a car." And that’s entirely true. But if we took that to its logical extreme, you could say, "I don’t even need to know that my vehicle runs of gasoline or electricity," or whatever. "I don’t even need to know anything about the liquids that go in that make my car work. I just sit down behind the driver wheel and drive and it works." And that will work until your gas tank runs empty. And then at that point, you have no idea how to fix your problem. So you're going to have do some reading and worse, you're going to be at the mercy of somebody else.

Having an instinct, having a clue about something about what's going on into the hood is pretty important when we go off the happy path and start trying to fix problems, whether that is fixing bugs or improving performance. Those are, I think, some very important practical takeaways that come from some people some of the time being the uncommonly deep learner.

Just for fun, for my son in his school, I've been working on building a game that he's doing as part of his school through this Mathematics competition, I've been building a computerized version of this game. And those that have been following my Twitter have seen some interesting tweets about that. But I've been building an AI, a strategy turn based AI so that you can play against the computer for this thing. Tackling that requires you to kind of really understand or at least be able to fiddle your way through some deeper "CSC" kind of topics. But I got it working and it was too slow. You have to wait for the computer for 20 or 30 seconds for it to figure out its next move and that’s slow. So then I started thinking about how I'm going to optimize this. Do I need an object pulled to pull stuff in and be able to reuse arrays or something? I was at a loss as to how to do that efficiently. I was completely lost. And so, I had to learn that thing. I had to think very carefully methodically.

If I had let some sort of artificial deadline and say, "No, you just got to ship the game," it would have worked but it would have been impractical. And so, taking that time to think about it -- actually, I finally did. It took me days but I finally arrived at a solution for managing, sharing references that actually works from a performance perspective. It is practical now. I think there are practical takeaways. It's not just all the theory behind being a deeper learner.

CHARLES: I've been thinking like where do you know where the stopping point is? Because the world is just packed with knowledge. When I was starting out as a programmer, there were people who just code assembly for fun and assemble their own microprocessors and stuff because that’s what they did when they were coming up. But all of that stuff exists like we're standing on it. We've kind of lived on the level of the city street but beneath that is the subway and beneath that is the power grid and the gas pipes and the hog water pipes and all that stuff. Who knows how much more layers of urban development lie beneath some of these cities that are certainly way more rich than Austin. None of that stuff is present here.

KYLE: I was going to say I didn’t know there was a subway. I wish there was.

CHARLES: Once I realized what the analogy was, I was standing in the Austin streets, I kind of transitioned to New York without telling anybody.

My point is that in the computer world -- let’s just keep it there -- let's say you're working with JavaScript and you're running on top of the browser. Most of modern browsers are written in C that are also using C libraries that are written on native platform tool kits whether it's OSX or Linux or Windows which then are written on top of these operating systems which then are written on top of these compiled assembly language that run on these microprocessors. It's a deep, deep ocean, so to speak. And we spend most of our time skimming around on the surface in our boats.

And so, I guess the question is how do you know when to stop and how do you know when enough is enough? Ultimately, there is a tension between a deadline and the amount of time that you're going to invest in learning. And I think that there are definitely -- I feel very strongly that it's skewed way towards the deadline and that we need to kind of pull that tug of war back in the other direction. So the question is then how far is far enough? Or is it just really until you feel comfortable?

KYLE: I see the world of what we do in computers and in software development as layers of a cake if you want to mix in a whole bunch of different metaphors here. There's lots of layers of abstraction that we create to utilize technology more effectively in our lives. And in a sense, the technological revolution from the 1940's onward has really been a story of adding layer upon layer upon layer upon layer just like a big tall cake of different abstraction because lots of different people need to eat at different layers. They need to get their jobs done, if you will, at different layers. There are people who need to get their job done the assembly language, the deep guts of your computer talking to the 1's and 0's kind of thing.

And then there are people that need to work in the C libraries. And then there are people that need to work in the operating system tool kits. And then there are people that need to work in the browser. And then there are people that need to work in JavaScript. And then there are people that need to work on frameworks. And then there are people that need to work on transpilers that build the frameworks that then get compiled down. So we just keep adding more and more layers because there's more and more people that were opening up the world to, to participate. And not everybody is going to play on the same level.

If your choice is to be a JavaScript developer, if your choice is to be a React developer, if your choice is to be somebody who builds those almost meta tools like the transpilers that go from one language to another, if you're a ClojureScript developer or whatever, my recommendation is that whatever layer of cake you eat out, whatever layer you’ve chosen to make your primary focus, I think you should be striving to become an absolute expert at that layer. And that is not a transactional thing when you just go watch the right video or read the right book and then you check it off. That will be, in most respects, a lifelong process. But I think you should strive to be as much of an expert at that layer as you can.

But to become an expert at that layer, one of the most important things is to begin to have an understanding, a level of competency at the layer below it. So if you're a React developer, having a layer of JavaScript below it means that you want to have some pretty good core competency in the JavaScript language. In a sense, that’s what my job is dedicated to doing is assisting people at playing at these higher levels at the frameworks and tools levels by understanding JavaScript more deeply. But if you're a core JavaScript developer and that’s all you do, you should have some competency at the layer below that which we might say would be the browser API level or maybe the C level and understanding something about how memory is going to get managed to let you have some intuition about that.

And so, the further you go down in the stack, you start to see that diminish but it never gets to zero. I don’t think there should be any engineer out there that aspires to have absolutely no knowledge whatsoever of what a processor is or what 1's and 0's are or any of that. But that might not be your everyday task. If that’s 4 layers removed and you have a lot less understanding of that layer, to be effective in your job, you should be an expert at your layer and be seeking to have a core competency level of understanding at the layer below that.

I think that’s how you start to answer, Charles, your question of how do you figure out where to stop is at this point in your career -- because many people will dance around and eat at different layers of the cake as they go. But whatever point you are at in your career now, be looking to understand how to eat all that layer of cake and then understand the one below it. I would say that would be the most effective strategy that I've come up with.

CHARLES: I like that. I like that a lot.

STEPHANIE: I want to become an expert in JavaScript. But sometimes I have doubts in my ability to "become a programmer" or think like a programmer. I feel like the people that excel in programming, and you could tell me if I'm wrong, I don’t know if you’ve noticed this as well or haven’t. But it seems like the people that excel at programming are the people that are naturally good at math. It’s like they think in terms of math. I don’t know if they're seeing algorithms in their brain or what it is. And I don’t know if other people relate to this as well.

But I'm a natural problem solver. I like problem solving but I don’t think in terms of math. And I've taken a lot of math courses for my undergrad degree. I took Calculus for Biosciences like two and a half times, and so I beat my brain enough to understand those concepts. But I don’t know if you have also seen that, if that is the case. And if it is the case, is there any advice for the hopeless programmers like myself that are not naturally good at math. But I am interested and I do want to be good at this.

KYLE: There's hope, Stephanie. There's definitely hope.

STEPHANIE: [Laughs]

KYLE: Again, lots to unpack here and I thank you for asking that question because I actually do have a particular sensitivity to the mindset that seems to come around between people - again, the haves and have-nots. There are people that naturally gravitate to or understand math and there are people for whom math has always been an opaque topic that they keep running into over and over and they haven’t been able to really fully engross themselves in or wrap themselves in. They haven’t been able to get it, if you will. And as an educator, I don’t teach math for a living. But as an educator, it deeply troubles me.

As a parent, my son, Ethan, is about to turn six. He's in Kindergarten for the first time, so it is right on the front of my radar screen to think about how we teach these things. And I want for everybody to be able to grasp important concepts like obviously reading is important, but Math is one of those core concepts that I think is important for people to not be intimidated by. And I think we do ourselves a really big disservice and have for many, many years by approaching the teaching of that topic as there's one right way to know how to do math. In a sense, I think, we're seeing a shift to know there's lots of ways to learn and we should embrace that. Just like we said there's lots of different ways that people learn. There's lots of different ways to approach. There's lots of different pedagogy, if you will, around approaching math and I embrace that idea that we should be doing that. I think we should be starting that with our Kindergarteners and working all the way up.

And I'm glad that there are educators that are thinking about that because my generation was taught that either you get it this way or you're just "not a math person". And I sat and sat alongside in my Science and English classes all the way through schooling even at University, I sat along people that were math people and on the other side of me were people that were "not math people". It's sad and it sucks that we would divide people that way or that people would choose to divide themselves that way because they struggle with math.

My sphere of influence right now is my two kids - my son, Ethan, and my daughter, Emily. I really want for both of them, whether they become math nerds or nor, whether they have a minor in math like I do or it's just a thing that they learn, I want them to not be intimated by that. I want them to understand it. And I hope that I will be able to, in the sense, partner with the educational system.

Our kids are in Austin IST Public Schools and they will be for their whole lives, as our plan, but I hope to, in a sense, be augmenting that by saying, "I understand that this is struggling for you, but let me help to at least not be intimidating, at least be a thing that you can grab on to and understand even if it’s not interesting to you, it won't be scary to you," because I have family members and I see it personally that have self-labeled and self-[inaudible] themselves as "not math people" and they struggle their entire lives as a result. And I don’t want that to happen. So, I'm glad I got at least a little chance to have some advocacy there to say I hope that people aren’t being that way and aren’t promoting patterns that treat people as either you know math or you don’t.

I was one of those people that gravitated towards math. But I can tell you for a fact that I do not use most of my math background on a regular basis as a programmer, and even if I try. As you're asking the question, I was doing some self-assessment here. What are the things that I know from math? Like I understand for example that a function is putting in an X value and getting out a Y value and when we plot that, we see a parabola on the graph. I get that concept. So, there's a tie in between the visual and the actual written out math for me. And I understand in calculus when we have the integral. I understand that’s the area underneath the curve. So, I get those concepts. But does any of that stuff actually play into my day-to-day work? Not really. Maybe a little bit about functions since I'm starting to be a bit more attuned to the functional programming these days, but it really doesn’t play into my job.

But there is a part of math that really does play in almost daily, and that’s what we call discrete math. That’s more of the computer science-y take on math. And discrete math is things like understanding number systems, things like understanding the difference between representing something as a binary or representing it in base 10 or hexadecimal. There are certain concepts that we talk about like Big O Notation - that’s one of those computer science-y concepts.

When I was writing this game AI, I had an intuition about a loop inside of a loop is going to perform worse than just a single level of loop. But I didn’t spend any time whatsoever actually calculating the Big O complexity of my algorithm. I just had some intuition about it. And the reason I have this intuition about it is because I took a discrete math class. So, if I could say anything to the people listening, for those that aren’t math people or for some reason or another didn’t really gravitate towards it, to be better at programming, I would encourage you to at least think about discrete math as an area to study to get some better understanding around, because I do think those things help.

But I don’t think that most of math, the stuff that most people struggle with, like algebra and matrices -- I was terrible at matrices. I hated them for some reason. I don’t think most of that ever comes in. I learned what an icon vector was but I've never once coded it. So I don’t think that you have to feel intimated coming at programming if you weren’t one of those "math people" but there are some parts of math that do end up playing quite a bit into the programmers' everyday life.

CHARLES: I think for me certainly whenever you have a particular problem, then that’s an opportunity to actually explore the math behind it. I think a lot of times we put -- there's this kind of inverse relationship -- we put the cart before the horse. It's like you got to learn math and then you learn the programming.

But it's almost like the equation ought to be reversed in the sense that it's like trying to -- let me just cast about for a random analogy here -- it's like learning the theory of fishing without actually living on the coast and going out on a boat every day. You can certainly study it and it can be interesting. Yes, we tie the line to the pole and we put it in the water but unless you actually have that problem of like, "Now, I'm trying to catch fish," you actually are connected to it in a way that’s going to help you understand what solutions work and which ones don’t.

I often feel like we frontload way too much on the theory. I feel it has to be connected to practice, I guess is what I'm saying. Because certainly my experience, I come from a CS background, but I didn’t switch to CS until my junior year of college. And that after I'd basically dropped out of school for two years to work at a startup. And I remember it made a lot more sense because I had this prior programming experience. It's like, "Oh…" Whereas, I think a lot of my classmates, they were kind of dumbfounded by, "What does this even mean? I don’t understand. I don’t understand how this connects to anything." But if you have that kind of experience, then the learning can come in hand with it but it has to be more of an organic process as opposed to one coming before the other. That’s my experience.

KYLE: I love what you're saying there and I want to build off of that to unpack some of my most recent passion and focus in the area of education and with developers because I really think what you're saying is the foundation is the same belief I have. So, I'm right there with you.

If you look at humans and the way humans have passed along information and skill to the next generation, if you look at that over the course of history, we have mountains of precedent around the idea that skills are passed along through the mentorship model. Some like to call it the master apprentice model. It's the more classical way to think about it. But just the more modern way is to call it mentorship.

For example, chefs. You would never suggest that the best chef at the best restaurant in town and the way that that chef got there, the way that that chef got to be the best chef in town and have the best restaurant was that they sat in a classroom and learned all the theory about how to bake a chicken. First, before going and baking the chicken, there's lots of ways that they could have gotten to be better but probably the least effective way would have been for them to learn all the theory upfront and then just go work in a kitchen for year after year after year after year and almost accidentally -- we call it the School of Hard Knocks -- accidentally learn all those experiences. That’s how a lot of people define experience is experience these mistakes over time getting practice making perfect. That does work and lots of people have done that.

And I certainly would say a lot of my story is that way, but I wish that I'd had a mentor. I wish that I'd had somebody like what happens with chefs to sit there and say, "I'm not just going to let you figure it out on your own and screw up a bunch of chickens. What I'm going to do is give you a little bit of information about cooking a chicken. Like for example, what the temperature of the oven needs to be, how to tell what the temperature of the chicken is to know that it's fully cooked, what materials you need and what utensils. But we're going to spend 10 minutes in the classroom talking about it and then we're going to go sit in a kitchen and you're going to watch me bake a chicken. And you're going to watch very carefully. And I want you to ask a lot of questions about what I'm doing and I'm going to talk to you about it every single step and the decisions that I'm making. And then I'm going to do that again and again and again and again. And over time, you're going to start to pick up on and glean some of my experience from observation. And then eventually, once you are starting to feel more confident about it, we're going to flip the tables and now, you're going to start baking the chicken but you're going to do it step by step methodically and I'm going to watch you and be very closely paying attention. And I'm going to ask you questions and I'm going to say 'why did you squirt that there and why did you do this and why did you turn on the oven right now'. And I'm going to ask you about that stuff and challenge you to make sure that you really got all the different pieces of what it takes to master this skill. And then I'm going to do that again and again and again. And after we feel pretty good about chickens, we'll go back to the classroom and we'll talk about cooking steak and then we're going to repeat this process over and over."

That is much more the picture of how that mastery of that skill is replicated in another person is that mentorship model. And we've seen that with stone masons and carpenters and plumbers and chefs and caterers. And on down the line through most of human history, we can see that that is how skills are passed along. What I think we're missing is that there's a lot of value to be gained by applying those models to software development. As a matter of fact, I think if you ask most developers, regardless of the skill level even if they were a senior developer -- although certainly the intermediate and junior developers are more willing to admit it. But I think if you really ask in their heart of hearts, almost all the developers would say, "Oh, I'd love to have a mentor to help me get better but I don’t know how or I can't afford it or there aren’t any available or I don’t know what to do," because we haven’t prioritized as our part of the industry making education more effective.

And so, when you talk about 'I need to practice a thing, not just know the theory', you're absolutely right. You're absolutely right that sitting in a classroom and learning a bunch of stuff which ironically that’s what I do. I teach corporate training classes, I threw out a bunch of information then I know as I'm throwing out that information, the vast majority of it isn’t going to be retained because the only stuff that will be retained is the stuff that somebody gets a chance to practice pretty quickly. And by pretty quickly, I think probably that horizon level is about three days beyond when you’ve learned it. If you don’t get a chance to really practice, and I don’t mean just the artificial stuff that we teachers come up with like a silly little toy examples and the foobar kind of stuff, I mean really practice in a context of something that matters and that you're thinking about it and you need to solve it. If you don’t get a chance to practice some of that theory within about three or four days, you're going to lose it.

So, I present to you a set of information in a week-long training course that you really ought to actually learn. And by learn, I mean more than just hear the theory but also practice it. You really should learn that over 12 to 24 months. But I give it to you in 40 hours because that’s, again, the industry incentivizes how quickly can I check off the check box then my developers learn how to become React developers or that we learned about JavaScript. Instead of focusing on how do I really get them to know it. And the only way to really get somebody to know it is to have somebody watching over them as they practice what was taught. You teach a little bit and you have a bunch of practice. And that practice can't be just the developer has to figure it out on their own and make their own mistakes and figure it out through Stack Overflow, it has to be monitored, it has to be proactively mentored. And they have to take a little bit of learning, a lot of guided practice. Pipeline that across, that’s how we make this educational process for developers become much more efficient, much more effective.

And so in a sense, what I'm trying to do is disrupt my own educational model and try to [inaudible] myself as a business by saying, "I teach it in the classroom but every time I walk out of that classroom, I feel empty inside," because I feel not just tired physically because it is exhausting, but I also feel empty inside because I know that what's really missing is that I just contributed to yet another transactional learning experience. But what really is important is for people to know that learning that is most effective is learning that’s relational. Learning has to be paired with people because at its heart, what we do as developers is a people game. It's not an 'instruct the computer' game. The 'instruct the computer' is a side effect of what we do in connecting with people and passing along information and skill and knowledge. We've got to do that because we are throwing all kinds of money and time and effort at figuring out how to make people learn better through books and videos and conferences and tech schools and the list just goes on and on and on. And it's good that there's a wide buffet for people to pick from, there's no question. But most of that stuff isn’t as effective as it ought to be, and that is why people have to keep doing it over and over and over again. They have to try all these different things because they don’t get satiated by picking the one right thing that they ought to have fixed.

I happen to be obviously very bias, but I happen to believe that a lot of the problems that developers face, a lot of the overhead of code maintenance and all of that stuff, it could be solved if people were trying to implement mentorship for developer education. And that’s what I'm trying to do. My recent efforts are around upending or reimagining the normal corporate developer training. Of course I still offer that. And if anybody wants me to come teach, I can still do that. But what I'm moving towards and building a startup to offer mentoring at scale because I believe that’s where we move it from transactional relationship. We make it about people and then we get a chance to really practice what we're learning. That’s how you take a person, and get them from being junior to being intermediate or from intermediate to senior is that they have to have practice. Would you rather them figure it out on their own and make lots and lots of mistakes or would you rather them be guided and monitored as they go through that process of practice? I think the latter would be a lot more effective.

CHARLES: For people who are excited about this, who want to figure out ways in which to engage in this relational learning, this can be a very expensive proposition especially for smaller companies. But even for larger companies, one of the things you're hoping to address is a way to make this when you say 'do it at scale, make it more accessible' in terms of those time and resources.

KYLE: In a sense I would be failed at the start if I didn’t feel like I had a model for scaling mentorship. If I was just on here and [inaudible] saying, "Hey, everybody. You should go mentor," and I had no way of doing that, then everybody will say, "Okay, that’s all well and great. Thanks." And as soon as this podcast ended, they'd just go on back to their normal day jobs and fix anything. I really do believe that there are ways to scale out and to make it effective. That doesn’t necessarily mean that the price tag is cheap because time is expensive. And what we're saying is you need expert time paired with your people to get them to where you need them to go. But I want to push back on the notion that expense makes things inaccessible, because I want to point out -- this is almost like I'm doing a customer pitch. But I just want to point out that there's an awful lot of things that we spend money on as managers of software development teams. For example, I've talked to managers of software development teams and they’ve said, "We probably spend 70% to 80% of our time maintaining our existing code and fixing bugs, and only maybe 20% of our time implementing new stuff." Some people listening would say, "Good lord, I'd love to have 20%. We probably spend 5% of our time on that and 95% on maintenance." So those numbers differ. But there's a lot of overhead associated with running a software development team. And one of my theories which I believe we will prove out as we scale this out, one of my theories is that if you want people to avoid having to come back and return on something. One of the ways to do that is to empower them with better education before they write that line of code. I think even though yes it will be more expensive to get your developers mentored, you will actually not spend more as a company, you will spend much less because you'll be investing that money much more effectively in the things that actually make them retain and get a chance to practice that. It also means that hiring will be cheaper because you'll know much more deeply what your company wants and needs and that will make it a lot easier to identify the right candidates. It means that the total cost of ownership of yourself will be vastly less. So there's lots of dollars here that I think we can pull that we are, in a sense, wasting or misappropriating to make it more effective to invest in mentorship. I think what we need is a process and a model instead of tools to do that, and that’s my mission. That’s my goal.

CHARLES: I am very, very excited to see that, because I know that that is something that one, holds the value. Here at the Frontside, we see as one of our core beliefs and one of our core aspects or mission is to level people up and make sure that they can improve themselves as a developer and improve the quality of the products that they develop. But it's definitely something that we've struggled with. So, I'm really curious and excited to see the outcome of this. So, we'll be on the lookout for it. Is it still under the radar?

KYLE: There's no company name to announce yet. There's no website or Twitter account. But I can say that it's been under active development now for four to six months. I have a team of founders with me and we are formalizing our process in trying to get funded for that. I hope within the next few months that there’ll be a much bigger announcement about where we're headed with it because I'm all in on believing that it's not just good enough for me to keep churning. I get emails and tweets weekly. I get a couple to maybe five or ten sometimes in a week of people saying, "Hey, I read your book," or, "I watched your Frontend Master's training video," or whatever, "And that’s awesome. I'd love it if you could help me with something. Could you spend some time? How much would I need to pay you to get a few hours of your time to sit here and talk with me?" And it pains me to get these kinds of requests. And the reason it pains me is because I would absolutely love to spend that kind of time with people, but that kind of time is so valuable right now. Time is so valuable because the process of mentoring currently is incredibly time intensive. It's very, very expensive to do this. And that’s why I think it's not done very widespread is because people haven’t figured out how to make it effective, from time and money perspective. And I know that pain personally. I have to turn people down and say, "I'd love to but I'm too busy because…" and then fill in the blank with a thousand things. I'd love to have that time.

What I really want is I really want to be able to do this effectively and to scale it, because people are hungry. They want to learn. I believe that what we need to do is unlock that hunger, not necessarily inspire people. I think we need to unlock and empower that hunger that people naturally tend to have to want to get better at what they do. And I think this is one of the ways that we can help people get better.

STEPHANIE: I also wanted to point out that for companies that are interested in doing this, not only do junior or apprentices benefit from this model but the senior developers also benefit from this. I have personally seen someone on my team, Alex, from all the times that we've been pairing and talking about JavaScript concepts, I have seen an exponential growth in just the way that he explains things. And they do say the one that does the teaching does the learning. And I have seen that in him and I think it's something that every team could benefit from.

KYLE: I 100% agree. And to build on that, I would say what we're really doing with that is we're helping people find more purpose for what they do. And who doesn’t want to have more purpose and more meaning? We're giving people a way to -- as I said, all boats rise with the tide. We're giving people a way to help other people around them. And it doesn’t have to be like some macro scale thing where you become an international conference speaker. You don’t even have to speak at your local city meetup. You can just pair with the person next to you and help them learn the thing that you're learning, and then learn from them. And you’ve made the world better, you’ve made the workplace better, you’ve made yourself better.

It goes back to what I said before - I think we have to get better. The biggest thing that’s lacking from us developers right now, in my opinion, the emotional muscle that we need to work on the most is recognizing empathy for our fellow human beings for the people around us because I really deeply in my core believe and my DNA I believe that what we're about is people and not about the code that gets written as a result of this connections.

If we can focus on building the relationships around this. You don’t have to go pay for the service of the startup that I'm building. You can implement this just like what Stephanie just said, by looking for opportunities whether it's coding, whether it's code review used as a way to learn, whether it’s doing a brown back lunch, you can look for ways to build the culture of learning into the workplace around you and people will benefit from that. You will inspire people to get bigger and better as a result of providing that environment.

CHARLES: Fantastic! If people need to get hold of you, Kyle, what is the best way to reach out to get in touch?

KYLE: The best way to get in touch with me is to find getify. That’s how people know me online. That’s my Twitter handle, that’s my GitHub handle, it's also my Gmail address. So, getify@gmail.com. Reach out to me in any one of those channels, probably through Gmail is best. If you’d like to talk more about education, if you'd like me to come and help your team, I would love to come and do a workshop and then build a relationship with you or we can begin this mentoring process as I spin that up. If you're interested in that, if you're hoping to learn from some of my resources, you can check out my book series. I have the You Don’t Know JS books that I wrote that many people know about. That’s up on my GitHub. I'm almost done with my next book which is Functional Light JavaScript, you can check that out on GitHub. All that stuff you can read for free. You can also buy it if you'd like to -- and I always appreciate people if they want to support me. But check out my books. I have training videos available on FrontendMasters.com. I think I have nine courses and we've already scheduled a few more that I'm going to be teaching later in the Spring. That’s a fantastic platform. There's 50 or 60 really incredibly well-versed experts that are teaching on that platform. So, check out Frontend Masters. Some of those videos are also out on Pluralsight. You can check them out as well. Check out books, check out the training videos, get in contact with me if I can help you in some way with training at your company. But I would love it that even if that isn’t the channel, if you take nothing else away from the podcast, go talk about learning stuff deeper within the workplace. That will be the best takeaway that we can get from this podcast.

CHARLES: Yeah, definitely. I think the things that we talked about here really apply far beyond JavaScript and even really far beyond the technical trade of programming.

All right, that’s a wrap. Bye everybody!