Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I have the pleasure of interviewing Eric Elliott. Eric is an author. He wrote a book for O'Reilly called Programming JavaScript Applications. Of course he is a developer. He loves JavaScript. We talk quite a bit about JavaScript on today's episode. He's in the process of writing another book. He talks about creating high velocity development teams and we talk quite a bit about that in today's interview as well. Thank you so much for listening to the interview. I hope you enjoyed it as much as I did. Today's episode is sponsored by spec. Well it's not actually sponsored. It's brought to you by spec. Now spec is the network that Developer Tea is on. I highly recommend you check out all of the other shows and the content channels on spec.fm. You can go and check it out. There are also job listings on spec. So if you are looking for a job in the industry either as a designer or as a developer, there are job listings on spec on the homepage actually. So go check it out spec.fm. Now let's get to the interview with Eric Elliott. Eric thanks so much for joining me on today's show. I'm glad to be here. So you reached out and contacted me and asked me if I wanted you on the show. I definitely wanted you on the show. I'd seen your name all over Twitter, Plastered everywhere. Until now I actually didn't even know this but you are the primary author and the curator and all of that stuff for JavaScript scene. Is that correct? Yeah. Tell me a little bit about JavaScript scene. Yeah, JavaScript scene is a blog on medium. We get a lot of traffic over 100,000 visitors per month and it's been growing really fast since we started it last year. I basically just post a lot of articles, some in-depth, some not-so-in-depth on various JavaScript topics. But the prevailing theme is just how to be a better JavaScript developer. I love that. The reason I love that is because number one, you are talking about a broad idea of how to be a better developer, but you're scoping it to JavaScript. As we'll get into in this interview, you have a pretty strong bend towards JavaScript. That's right. I'm happy to go into it in lots more detail whenever you want. We will do that. You might have heard of Eric from his books, Programming JavaScript App Applications, which is an O'Reilly book or Learn JavaScript with Node, ES6, and React. What does that one publish through? That one is a book currently in progress. I'm hosting it on Lean Pub right now. But when I'm finished, I will shop the finished version to print Publisher. I'm not sure which ones will target yet. That sounds awesome. These books are also obviously focused on JavaScript. You've heard the word JavaScript a few times in this episode. You're going to hear it a few more. I'm going to go ahead and let you know. Yeah, absolutely. Can you explain what your background is? I read an article from you and you mentioned that you've been doing development for at least. It seems like you said since the 90s, isn't that right? Yeah, actually, I started when I was a little kid around the time I was learning how to read and write. I had a friend that I'd go over there and practice our play games on their computers. I started that way. But I've been doing it professionally for most of my life. Wow. It's a long time. Yeah. I think that's true for a lot of developers. They find something interesting as a young kid or maybe they're interested enough in computers, but it doesn't really come to fruition until later on in life as a potential career option. Yeah. It really has been a long career of helped a lot of companies. Like Adobe, Zumba Fitness, Wall Street Journal ESPN, BBC, Usher, Frank Ocean, Metallica, and a lot of others. I've done user experience for a lot of them and did a lot of node at Adobe and the app that did the Wall Street Journal ESPN, BBC, that was a lot of node as well. That's awesome. It's a great list. Yeah. So in other words, these books are probably built off of some pretty legitimate experience. Is what you're saying to me? Yeah. Absolutely. I've helped contribute to lots of apps with more than 100,000 lines of code and some of them with millions of lines of code. I've done a lot of consulting with lots and lots of different businesses. I've had my hands in hundreds of different applications, both small scale and large scale, mostly large scale. Sure. How do you have time to write two books and curate a blog and create what we'll talk about here in just a minute, some more course content? So the writing the books thing that my first book was, I thought, oh, I can do this on my nights and weekends and kick it out in a few months and three years later we published it. So it's not really like I have a lot of time. But what does happen is that the time that I do have I invest very heavily in JavaScript. And I think it's really important to train people in JavaScript and to talk about education and really beef up education. In fact, I'm the host of a film called Programming Literacy, which is produced by JS Cheerleader on Twitter. And that film is targeted at the fact that there's this huge skills gap in the marketplace. And there just are not enough talented developers available to fill that gap. So definitely education has been a major focus for a long time and I've spent a lot of time writing about it and talking about it and working with other Developer To boost their skills. Yeah, it's a valiant effort because it is definitely true that there is a gap in what is needed and what is available. It's really an interesting thing. I'm as a hire or as an employer, I guess you could call me. I'm always looking for people who are who are talented and it seems that the job market is flooded with a lot of people who are either very young in their careers and don't have any experience or you know, they don't have experience in relevant things. JavaScript is always going to be relevant and this is actually a good segue into your into what I'm calling the case for JavaScript that I want you to make because you can probably make it much better than I can. But it's an interesting problem that we have in the industry. So yeah, my case for JavaScript really revolves around the need to develop high velocity development teams, which means that the teams that we're producing to build the software that we're writing, they have to be able to add a lot of features or remove a lot of features and change and adapt to changing consumer expectations or changing requirements from business departments. And a lot of other languages present kind of a more rigid structure. So it's harder to change them like a for instance Java and lots of strongly typed languages, strongly typed object oriented languages. They tend to lock you into designs and they make it really hard to refactor. JavaScript is a lot more free form, which means it's a lot more dynamic and you can you can add and update and change things a lot easier. Sure. Yeah. And there's one other point that I want to make about JavaScript. It's the only truly universal language, which means that it runs native in every browser. No other language does that. You'd have to compile to JavaScript to get stuff to run and there's a select number of languages to do that. There are actually hundreds of them, but most of them are not well known or widely used. So you can have one code base that runs on the server, runs on all of the clients, even runs on things like robots. So it's really universal in the sense that it solves the problem that Java is set out to solve, which is right once run everywhere. Java failed at it. JavaScript succeeded. Yeah. That's really interesting that you mentioned that because I was actually going to try to bring up a few questions that maybe some of the listeners would have. For example, Ruby, there is a similar concept of isomorphic development that is coming out in Ruby through Ryan Stout's project called Volt. The only issue is it still relies on compiling to JavaScript. Yeah. Compiling to JavaScript is a lot harder for dynamic language like Ruby. So they have to jump through some more hoops compared to a language like C++. So there's a couple of different ways to write languages. There's high level languages and low level languages. So C++ can target the low level features of JavaScript. It's a subset called AsimJS, which is being supplanted by WebAssembly soon. So those are a lot easier to compile to JavaScript than something like Ruby where you have to reinvent the whole mapping so that you can introduce the dynamic features of Ruby into the JavaScript code base. Sure. They've done a relatively good job of introducing those features. The thing about it is keeping that up to date, for example, trying to re-implement some of or take advantage rather as some of the new features in JavaScript coming in ES6 and eventually in ES7. Some of that stuff is going to make a lot of the things that are currently being done obsolete in the project is called Opal, by the way. Opal translating Ruby to JavaScript. Some of those things are going to be less efficient than they could be, for example, recursive tail, what is it called? Tail recursion. Proper tail calls. Yeah, that's what it's looking for. For example, the proper tail calls. And those kinds of things can't really be faked. They're just going to have to re-implement them as JavaScript changes over time. Yeah. And JavaScript is really becoming a much better target for compilers. We're adding SIMD, single instruction multiple data. That's probably going to come in ES7 next year. And we're adding a lot of other features like that. We're getting a lot better type deraids and stuff came in ES5 or ES6. We started using it during the ES5 era a little bit. But now we've got broad support for type deraids in the current version of JavaScript, which is great. And that's going to help a lot of those compiled to JavaScript languages as well. Sure. I was speaking with one of my, I guess you could call them like a personal hero in the Ruby community of D. Grimm. And I asked him about prototype languages and what he thought of the prototype model. And he said that he thinks that, and this is probably the first time this has been on record, but he thinks that prototype actually gets, oh, oh, better than most object oriented languages do. Absolutely. Yeah. So the thing about prototypes is that you inherit behaviors from other objects or be it inherit properties from other objects, rather than inheriting from a class. So in classic class inheritance, you get a parent class and a child class and the child is tightly coupled to the parent. With JavaScript, it's more like we can just go and steal whatever properties from whatever combination of objects we want and inherit those into our new object. And I've got a project called, called stamp it. And we're working on a composable specification that will actually allow you to have composable factory functions, which support a lot of JavaScript's really, really cool object oriented features. So I'll probably be doing some presentations on that very soon. I think we're talking in October and Sydney, Australia, at the web directions conference. I'm going to give a presentation on that. That's awesome. Yeah. I think that JavaScript in many ways, because of the prototype model, it allows you to do things that know whether language really has support for in the same way. And that the idea of composition is truly fundamental to a strong object oriented programming except my only caveat there. And you can maybe fill in the gaps for me here a little bit. My only caveat is I don't think that object oriented is enabled as much by inheritance as often as it's enabled by, you know, simple message passing. But I think that's what JavaScript does so well is that because you don't have to inherit strict inheritance, doesn't really, like you said earlier, it kind of locks you in, strict inheritance locks you into a design pattern that maybe you don't want. Yeah. Every, I've consulted on a lot of applications, as I mentioned before, in the hundreds. And every large scale application that I've consulted on that had, that made a lot of use of class inheritance, we saw a lot of refactoring work going into those applications to make them better because when you use class inheritance, you're opting into a strict higher-archial taxonomy. So for instance, if you want an animal that can fly and jump, then you might be inheriting from a specific type of animal. And then if you need to add another capability, for instance, like say you've got animals that are birds can fly, right? But then you have to create a penguin, right? So there's a lot of problems like that. It's that every taxonomy eventually is wrong for new use cases. And this is a problem that's been widely discussed in classification of all kinds of things, including natural science, classifications, and things like that. And there's really, in nature, what you find is instead of strict classes, you end up with kind of a, like a gray scale fading between like some things are more, what are they called, prototypical of a class than other things. And it's a sliding curve. It's not a thing that is or is not sure. Yeah. And that's I'm actually doing an episode about this after after after this episode airs. But the idea is that we impose these structures on things in order to understand them better. And a lot of times that structure is kind of leaky in its description, right? Because we want things we want to understand things categorically, but things don't exist necessarily categorically. Exactly. Exactly. And that's part of the big problem. And another part of the problem is that we impose our understanding of things on our classification systems and our understanding of things and the reality of those things are two completely different problems. Sure. And it can often cause real issues when our understanding of the category is stronger or more seated than our understanding of the reality. Right. So we impose those categories stronger than we impose the realistic use case. Exactly. And the really big problem that I encounter is people dramatically underestimate the cost of refactoring when we get those categorizations wrong. Yeah. Yeah. Definitely. And partially because a lot of that design has been molded around a system that fundamentally was broken from the start. Exactly. Yeah. That's great stuff. If you have worked in a strongly type of language, then we're probably kind of nodding your head in agreement with us because this stuff is so common in so many scenarios where you feel like, you know, maybe this thing is kind of like this thing. So let's inherit and the inherit and structure that you create ends up shooting you in the foot over and over and over. And a lot of the time the better way of doing things is to just share properties or, you know, create what in Ruby we would call just module mix and whatever. But the reality is, you know, a lot of that behavior that you otherwise would inherit like the bird penguin example is great because penguins can't fly and birds can't swim, right? Typically speaking, but the prototypical bird is not at all like a penguin. So a penguin is on its own. It's up in the or down wherever in the Arctic, right? Yeah. It's kind of an outlier quite literally. There's a really funny story that I like where this team was building a software for, you know, military simulations and stuff like that. And they wanted to add kangaroos so that they could train helicopter pilots not to scare flocks of kangaroos and reveal the position of the helicopter, right? So they decided that they were going to, hey, we've got these troop movement things already programmed. Let's inherit from that. And then as they're flying the simulator, they decide to go and buzz this flock of kangaroos to show the behavior. And the kangaroos started shooting at them because they inherited from the military unit stuff and they had weapons and they would attack and you got close. I'm sure that was a fun surprise for the programmer. Yeah, that's kind of a really good description of the gorilla banana problem, which is what you wanted was the banana, but what you got was the gorilla, the banana and the entire jungle. That's a quote from coders at work. That's great. So these are, these are some good reasons at a language level to think about JavaScript as, and not only as a front-end language anymore, in case you haven't been paying attention in the past, I don't know, what has it been about eight years now? Several years, yes, since 2009. Node. Node.js and similar things, but primarily Node.js has brought JavaScript to the server side. In other words, it's not just a language that you use for quick scripting in the browser on the front end or on the client rather. It's also a very serious language to use on the back end. Yeah, very much. In fact, it's taking over a lot of enterprises. I've had a lot of projects where I ported from Ruby to JavaScript, specifically because of dramatic performance benefits and developer productivity gains because of the ability to have universal JavaScript or aka isomorphic JavaScript. It sounds like Ruby is gaining that isomorphic capability now, but after seeing the types of performance gains that I've seen, we're talking about huge, huge factors of 10 performance gains, according from Ruby to JavaScript. I'm skeptical about Ruby's ability to keep up. Sure. I have a question about performance, by the way, but specifically related to JavaScript, as it relates to parallel computing. If the listeners are unaware, JavaScript runs on a single thread. It does so because it can basically has something called the event loop. Eric can fill in the details where I'm missing here, but JavaScript has been known for performance because this event loop happens to be really fast. It turns out that it's a really good way of handling tasks that a computer has to deal with because it doesn't lock up the thread. It puts them into a queue to process them at the right time. Eric, if you want to expound on that, and then I'd love to hear what you see as the future of parallel computing as it relates to JavaScript. Sure. The great thing about the JavaScript event loop is that in node, everything is asynchronous by default. Whereas in Ruby, you go to load a file that thread is locked up while you're loading the file. In JavaScript, that doesn't happen. Instead of doing that, it fires off the request to load the file and then it frees up the event loop to start processing other instructions. Then when the file is loaded, it comes back and basically interrupts the flow again, and then you can get diverted into the code branch that processes and handles the file. This sounds complicated, but it's really not once you've got a little bit of experience writing asynchronous JavaScript, which is everything in JavaScript is asynchronous. It's always been in the browser because you're always waiting for user interruptions because you're handling inputs and IO basically. All of that is asynchronous. Writing asynchronous code is nothing new. It's been around since the mouse was invented and before that even. The way that JavaScript treats everything is asynchronous by default, especially for blocking operations like file loading or hitting the network or anything like that. By default, it chooses the most efficient way to process the program. There's a single event loop, but we can and do fire off multiple instances across a large number of processors and across a large number of computers. The fact that we've been doing all this asynchronous by default programming since the very beginning actually makes the architecture much more well suited for that kind of distributed computation. I think that JavaScript has a huge advantage in that territory and on Ruby people might be thinking, but we have event machines so we can do that too. The difference is that most of the Ruby Gems don't work with event machines. You have to actually have event machine specific Ruby Gems for your event machine program in Ruby. Whereas with Node, it's that way by default. You don't have to have some special NPM module to handle asynchronous behavior because that's what we have. This is built into the language basically. Yeah. That advantage over other languages applies to, for instance, Python has twisted and tornado. Java has different kinds of systems that the Scholar programmers are starting to get into this kind of thing. But all of this is not default behavior in these other languages, whereas in JavaScript it is and it has been since the beginning. That's a huge advantage. The types of performances, the types of performance increases we see are really orders of magnitude 10 times faster, 20 times faster. And every porting project that I've been involved with, we were able to get these kind of orders of magnitude performance gains. Interesting. I'd love to hear what you would think would be a project that JavaScript would not be well suited for. Because I know that every great tool has something that it isn't perfect for. Right? Sure. Right now, I think JavaScript's biggest weaknesses, it's really, really great that we have the web platform APIs. That gives us all really great access to user interface tooling. We can build really great dynamic user interfaces and really great networking and communication layers and really great notifications for collaborations and so on. It's really good for all of those things. One thing that it's not really good for is things that require really intense computation like some of the scientific applications or I'm a musician. So I think of like the music applications, like I want to guitar effects, pedalboard in the browser. And there's actually a project that does that. But it's not ideal yet because JavaScript's in the browser APIs, we're waiting for the browser standards to catch up with the technology. For instance, we're still using WebGL is like an older version of OpenGL. So we're a couple of generations behind on our ability to do high end graphics, which they're working on very, very strongly right now. So both like Unity and Unreal Engine are working on helping improve these things. And they've been working really closely with Mozilla, especially. They've really made great strides in that department in terms of getting really great AAA games running in browsers. But it's still, I would be lying if I told you that we're caught up and we are the cutting edge of that technology. We're not there yet. But we are trying to solve those problems with things like the type to raise in the new version of JavaScript and you know, SIMD, single instruction, multiple data coming in the next version of JavaScript. Those kinds of things are going to really help us catch up with those really processor intensive kinds of applications. Sure, that's great. So I'm going to take a sponsor break here and then we're going to come back and talk about using JavaScript specifically because you actually propose that JavaScript is really the only choice for high velocity development teams. We're going to come back and talk a little bit more about what you mean when you say high velocity development teams. Perfect. All right, so I will record that spot after. Cool. So, Eric, thank you again for joining me today. This has just been such an interesting conversation about JavaScript. Quite honestly, your understanding of JavaScript goes far beyond mine, of course. So this is enlightening for me. I'm sure that is an enlightening for most of the listeners. So thank you again for joining me today. Yeah, it's my pleasure. It's been a really great conversation so far. Yeah, definitely. So let's continue it and I want you to tell me a little bit about high velocity development teams. This is not only a concept, but it's also, is it a course that you are developing? There's a blog post called How to Build a High Velocity Development Team and my courses are all about educating developers so that they can be part of high velocity development teams or even lead them and start to create a culture of high velocity development in the workplace. Okay. So tell me kind of the core tenets of what a team that you would consider to be high velocity, what does that look like? So high velocity to me is all about agility. It's the ability to keep up with changing technologies, the ability to keep up with changing user requirements and keep up with changing business requirements. And in order for that to happen, you have to have a very malleable code base. And JavaScript is uniquely suited for this kind of development because it's such a dynamic and such an expressive language with particular regard to how it handles objects. The object system makes it very, very powerful and very, very expressive, even for things like functional programming concepts. The object system is really friendly for creating data structures and data types that are very interesting and very usable. It's really a uniquely suited language for this. And I also mentioned the fact that JavaScript is great for universal application development. And that means you can literally use the same code base on iOS, Android, and servers and the web client. So these things are all sharing literally the same code base. And each one will have its own little particular, this is for this platform only, right, to customize to things like how iOS handles user, user widgets versus like how Android does and so on. But the bulk of the application really lies in the logic and the capabilities of the program and how state gets manipulated rather than how the user interfaces get displayed, right. That's the user interface code is maybe 50 to 70% of the code. And then there's another 30% that you can share between all of your platforms. And in fact, with things like React Native, you can even share a lot of the user interface code. So it turns into more like 60 or 70% get shared. So that's a dramatic savings. If you know anything about development, in terms of the man hours and how expensive it is to build that much of a code base for a continually evolving app, it's really expensive. So high velocity development is really important and universal JavaScript makes it a lot easier. Yeah, it's interesting that you mentioned that specifically about how it takes multiple languages. In a given web project, for example, you could find yourself writing JavaScript, HTML, CSS, or some pre-processed version of CSS like S CSS. And then you could write something like a gulp file to glue all this stuff together. And then you may have to know something about Photoshop. And probably you have to know something about compressing images with some kind of image processor. And then you may even have to know a little bit of Apache or NGNX. And all of these things just adding up and adding up. And the reality is, the wider that gets, the less good, you're going to be at any one of those things. If you have to split your focus amongst, you know, 50 languages, it's difficult to become a masterful at any of them. Now it's certainly good to be aware of these languages. In fact, Eric, how many languages are you familiar with? I'm really just mainly fluent in JavaScript now. But before I hit JavaScript, I was, I programmed in something like 20 plus different languages, including C++, assembly language, straight machine language in my early days playing with games and stuff. And then there's things like Pascal and Delphi, which was like an object-oriented advancement of Pascal and so on. And the list goes on and on. Would you say that your experience with those languages has kind of helped inform some of the ways that you write code, particularly the way you write JavaScript today? Absolutely. In fact, I think my early experience in graphics, for some of your listeners who aren't aware, there's something called AutoCAD, which is used by a lot of people in the 3D modeling and things like drafting homes and stuff like that. Well, AutoCAD has this dialect of Lisp called AutoLisp, which was- Wow. I didn't know about that. Yeah. So, and this is a functional language. And my early experience to AutoLisp really informed how I think about all kinds of problems. And it really started driving me more in the direction of JavaScript before JavaScript was ever invented. And then when JavaScript came out, and I was really deep into 3D graphics and using things like AutoLisp a lot, it was a really natural transition for me to go to JavaScript because JavaScript supported things like first-class functions that are very functional in nature. And that's one of the things that really drew me to JavaScript early on is number one, the flexibility of the object system and number two, the ability to have first-class functions with closure support. That was incredible to me. I really loved it. Yeah. Yeah. So, in the point being there that, you know, seeing all of those connections is really certainly valuable. So, this doesn't- this isn't to say that, you know, just because you're focusing on becoming fluent with the language that you shouldn't have the perspective of other languages because that perspective certainly helps you approach problems differently based on, you know, the different ways that each of those languages enforces the rules. JavaScript happens to be a very lenient language in a lot of ways. It turns out that it's, you know, dynamic types or, I guess, not strongly typed rather is the better way to put that. Yeah. It's not strongly typed. It allows you to kind of, you know, do pretty much any paradigm that you could impose on JavaScript. That's not true of every language. If you are working with JavaScript, consider yourself lucky because most languages have much more imposed rules and some of them for good reason, certainly. Yeah. And I actually really like type systems that are really well done because they can provide hints for the developers and the IDE's and anything that can reduce the developer's cognitive load and help them understand how the program fits together is a great thing. But JavaScript's loose type system made every function genEric by default. And what I mean by that is that the same function can operate on any number of different types, which is a fantastic feature of JavaScript. For instance, there are genErics built into the object built-ins. So for instance, you can call the array methods on a string. You know, and the ability to use those functions in a really genEric way over lots of different types helps to make those functions more reusable. So that's a very cool feature of JavaScript. I agree. And you know, I'm going to be the evangelist for JavaScript here. There are a lot of negative thoughts thrown at JavaScript. In fact, you know, the long-standing canonical JavaScript, the good parts, that implies that there are a lot of bad parts. But I would contend that the bad parts of JavaScript are typically actually just misunderstandings or assumptions that people bring to the language. And those are because of the flexible nature of the language that comes with the cost. And that cost is knowing, for example, that you can perform array operations on a string. And some people would consider that a bad thing. But if you know how it works, and you know how to use it properly, it can be a fantastic thing. Yeah, it's a really great, really powerful thing. For instance, things like that, making functions genEric lifting functions so that they operate across multiple types is something that people frequently did in C++ too. But instead of the JavaScript where it's genEric by default in C++, you kind of had to hack the language by using what they call templates. And those templates are just ugly. I'm not going to sugarcoat it. They're really, really ugly. And I don't ever want to see a C++ template again if I can help it. Because they're not readable, it's not great syntax to work with. It's like in PHP, mixing PHP and JavaScript. And you get really jumbled because there's two different languages that you're constantly context switching between to keep everything in focus and understand what the thing is doing. That kind of complexity just doesn't exist in JavaScript in the same way that it exists in something like C++. And if you don't have dynamic features in a language, you know, if you develop a large program, eventually that program is going to need some kind of dynamic features. There's a green Spun's 10th rule, which is basically that every sufficiently complicated application eventually has like this half implemented buggy version of list in it. So the point is that people, if you don't give them dynamic features, they hack them into the language in really buggy, ugly ways. Yeah. Yeah. I think even in JavaScript, you see some negative effects of people trying to hack the system for even further dynamic, like meta programming, if you want to call it that, using eVal, for example. Yeah, exactly. And I'm definitely not a big fan of that. In fact, that opens up your code base to a whole lot of potential to need to refactor it in major ways. So I just tend to avoid that as much as possible. There are a couple of good use cases for something like eVal, but there's the chances are if you're looking at eVal, you're doing something wrong. Yeah, I was going to say, chances are you need to refactor. You're probably looking at, you know, you're trying to access the scope of something that you don't have access to in that particular spot or, you know, something is going wrong in your application. Yeah. It's definitely more of a code smell than something that you should consider. In fact, in the early days of JavaScript, I would see people using eVal instead of square bracket notation. And JavaScript supports this square bracket notation where you can put expressions into object property names to grab the object properties. So you don't need to evolve to do things like that in JavaScript that you would need to do, that you would need to hack other languages to do. Yeah. And that's actually what I was thinking in my mind is the way that I would do, you know, what we call metaprogramming is I would probably define functions on an object. And now we're getting into the weeds, but I would probably define, you know, properties on an object and then set it equal to a function that has some dynamic properties inside of it. Yeah. Yeah. And then things like that are going to get easier. Now, particularly with ES6, we have things like template literals where we can literally basically invent our own language syntax. And then it calls a function using that tagged template literal. And you have the ability to interpret what was going on with the inputs when that string was evaluated. So we can really do all kinds of cool metaprogramming and like introducing DSLs into JavaScript and things like that with some of the newer tools that are coming to the language. But even before all that, JavaScript's had some really great features for things like that. And I think now they're looking at things like sweet JS gives us a good idea of how macros might be brought into the JavaScript language. And they're seriously discussing that for ES7 or ES8 to bring macros into the language, which in LISP was a very powerful feature, which also gave you the ability to create your own kind of DSLs and add syntax to the language. Very powerful stuff that would be very useful, especially if you start using JavaScript on larger applications. And that is something that I think more and more people are going to pick up on. And I think Eric that you're completely right on that that JavaScript is probably if you had to invest in any language, and I've said this a few times, I'm not sure if I've said it on the show before. But if you had to throw money at any language or throw time at any language, pick JavaScript if you have no idea where else to put it. Oh, absolutely. Just default to JavaScript. And then if you have some requirements that don't fit well with JavaScript, like huge parallel processing needs on a single computer instead of in the cloud, JavaScript is great for that in the cloud, but on a single computer it's not so it's not quite as good. So just default to JavaScript and then only divert from JavaScript if you find a place where JavaScript really is weak. And that's a very small subset of programs can say that now. But I want to kind of circle back a little bit to the high velocity development thing. High velocity development is the ability to easily change and adapt your program. I think that there are some things that are definitely a definition of high velocity development. And one of them is that you have some sort of automated QA and continuous delivery process. So you must be doing something like TDD to really get the maximum benefit of high velocity development. Otherwise you're going to spend too much time fixing bugs and putting out fires and testing new features. So TDD and continuous delivery is definitely like it's part of the definition of what I mean when I say high velocity development. But there's a few other things like default to open source so that lots of other teams can be involved in finding and fixing your bugs. And you can benefit a lot more from the open source community. You're giving back as well as accepting help from outside. So default to open source modules. Encourage collaboration and do code reviews and occasionally do pair programming and things like that. A lot of problems come when you have just one developer assigned to do this one thing and he bumps into something like I don't know how to do this or that. Whereas if you've got a really collaborative work environment and you've got other people around to help you, you can just like pop off a question and somebody can jump in and help you out. And another thing that I think is kind of a definitional or high velocity development is that you default your team communications to be asynchronous rather than synchronous. So you don't interrupt the developers while they're deep in a problem because that can cost the developer about 20 minutes every time they get interrupted. So if you get interrupted like just 10 times a day or something, you've lost several hours of productivity. And developers really need these long blocks of productivity in order to get over the big humps. So it's really important not to interrupt developers. So I think that's a little bit of it. There's also like I really think that a lot more companies should be doing remote work by default for just those reasons because you build a more modular app and your communication defaults to asynchronous just as a side effect of being remote. So I think remote workers have definitely have a big advantage. Our remote teams have a big advantage in velocity. So but I wouldn't say that that's an absolute requirement for high velocity development. But it definitely really really helps. The more your team is remote and asynchronous, the better for your development velocity. That is incredibly interesting that you mention those as side effects rather than trying to implement those things for the effects that they give. So a lot of people they go to remote work not because it it betters the team but rather because they want to have the the freedom to go to remote. But having those side effects you're talking about that's a really interesting value proposition that I don't think a lot of people are thinking about necessarily. Yeah, absolutely. I mean just the fact that remote work automatically defaults to asynchronous communication. That's a huge thing by itself. But then there's also that the developer has a lot more a lot more free time because they're not wasting time commuting to work. Right. So and they have this they have this better quality family time because then they can choose if they they need to do something like go run an errand with the family or something they can. And if they want to put in some hours later in the evening, maybe they're more productive when everybody's gone to sleep and there's nobody around and they can really get that uninterrupted time that developers need. You know, maybe they can choose to work the hours that makes sense for them. The hours in which they are more productive rather than the hours imposed by a nine to five office scenario. Yeah, it's interesting because I work in a more traditional office scenario currently. And we actually impose some of the things that you're talking about intentionally like we have hours in the morning that we consider protected hours where nobody is allowed to talk to anybody unless it is asynchronous. You can email me or you can you know message me on Slack or something like that. But you know, don't walk up to my desk and don't intentionally interrupt what I'm doing. In fact, I found myself and this is really funny that you mentioned that too. I found myself actually escaping away from the office whenever I have something really intensive to work on so that I ensure that I have that truly focused energy to put towards something. Yeah, exactly. And some of my most productive times it was outside of the office and I would actually leave the office intentionally to get something done. And that was incredibly valuable. But that just happens automatically when you've got remote teams. Yeah, and this may come as no surprise to some of you. But to others of you, if you are looking, this is just like a bonus here on this episode. If you're looking to increase productivity for a day or if you feel like you're kind of stagnating or something, try getting out of the office, try going home or wherever your particular employer is okay with you going to. But try going home or down the street to a coffee house or something away from where other people can walk up and interrupt you. It also has the added benefit of your brain being in a different context, which is extra stimulus. And all of those things that we've talked about on the show previously. But this is just this is fit in right right into to things that I've talked about previously on this show. Oh, that's great. I'm going to have to go back and listen to some of those episodes. Yeah, for sure. So Eric, I want to ask you a few things were were just on the edge running out of time. I've got two more quick questions for you that I like to ask all the guests that I have on Developer Tea. Sure. But before we do that, why don't you tell people where they can find out more about high velocity development teams as well as JavaScript scene? Sure. So on JavaScript scene, there's an article called How to Build a high velocity development team. And we can send you the link to that. And what was the second part? The JavaScript scene. I was going to ask about how to find JavaScript scene. Okay, that's medium.com forward slash JavaScript dash scene. And I think that high velocity development team post is a featured story. So you should see it when you load up that page. Perfect. And we'll include these links in the show notes. Of course, which can be which can be found at spec.fm or at developertea.com. Great. So here's here's the the two questions that I'd like to ask you. Number one is what is one thing that you wish more people ask you about? What is one thing that I wish more people asked me about? I think that one thing would be the role of programming and technology going into the future. Like I mentioned earlier, I'm the host of the documentary film programming literacy. And that is because the future is going to be a lot more high tech than it is right now. And a lot of jobs are going to be dependent on programming. And we're just not teaching our kids how to code. You know, 9 out of 10 US K through 12 schools. Don't teach accredited computer science program. So I mean, literally, you know, half of the jobs, almost half 45% of the jobs we take advantage of today are take for granted today are not going to exist in 20 or 30 years. So it's going to become increasingly important to train our kids and technology and, you know, programming and robotics and high tech things like that. And including things like biotech and you know, that stuff is going to be increasingly important going forward. So that definitely I wish everybody would ask me about that because I can talk I can talk about that forever. Yeah. That sounds really interesting. Is it when is that film scheduled to be released? So we started, we kicked it off at the Sundance Film Festival this January. And we're planning on doing shooting for quite a while before we pick the spots and put it together and edit it together. So it'll probably be at least 2016. Maybe maybe maybe even later. But we're really working on it a lot and it's definitely a passion. Yeah, I think that's going to be a really, really interesting film. So I will personally watch out for that. And definitely whenever it comes out, I'll most likely say something about it on the show. Yeah. And you can look at a trailer at programmingliteracy.com. Perfect. And we'll include that in the show notes, of course. And the second question Eric is if you could spend just one minute with every developer or any developer, what advice would you give them? Learn JavaScript. That only takes three seconds. Yeah. I probably spend the rest of that minute telling them why JavaScript is so important. And even if you're not going to program your apps in JavaScript, which you should, but even if you're not, you're going to learn a couple of very important programming paradigms in JavaScript. You're going to learn how to do composition better for building objects and data structures. And you're also going to learn about functional programming and higher order functions. And that is tremendously valuable in every language that supports them. And those languages that don't support them are adding support for them or should be adding support for them. So yeah, definitely JavaScript is going to teach you a lot more about how to do asynchronous programming well and how to do function composition and so on. So definitely learn JavaScript. That's my advice. Great. And beyond programming JavaScript applications and your new book, are there any other resources that you would recommend? Of course, JavaScript scene. And what else would you recommend if anything? So I'm a little bit biased here, but I offer courses online at Ericelietjs.com. Elliott has two T's at the end. Definitely do that. I've also got an article on on JavaScript scene. I think it's called learn JavaScript. And that's on JavaScript scene. I don't see it coming up right here, but I'll find it. Great. Well, those are great answers and really insightful. Thank you again, Eric, for being on the show. It's my pleasure. Thanks for thanks for interviewing me. Thank you so much for listening to my interview with Eric Elliott. Eric, thank you so much for coming on the show. I really enjoy interviewing people from all different backgrounds, but as always, I love interviewing other developers because you know, it's really fun to click with other developers. Eric and I just had a fantastic conversation. I really enjoy talking with him. If you have questions for me to answer on Developer Tea, you can email them to me at developert.gmail.com. And of course, you can get in touch with me on Twitter and app Developer Tea. Thank you so much for listening and until next time, enjoy your tea.