JS Remote Conf starts tomorrow! Get your ticket TODAY!

 

03:59 - JavaScript Tools Fatigue

09:25 - Are popular technologies ahead of public consumability?

12:53 - Adopting New Things / Churn Burnout

18:02 - Non-JavaScript Developers and Team Adoption

30:49 - Is this the result of a crowdsourced design effort?

35:44 - Human Interactions

45:00 - Tools

47:03 - How many/which of these tools do I need to learn?
On YouTube
194 JSJ JavaScript Tools Fatigue

Picks

Julie Evans: How to Get Better at Debugging (Jamison)
Totally Tooling Tips: Debugging Promises with DevTools (Jamison)
Making a Murderer (Jamison)
Scott Alexander: I Can Tolerate Anything Except the Outgroup (Jamison)
@SciencePorn (Dave)
postcss (Aimee)
Cory House: The Illogical Allure of Extremes (Aimee)
Kerrygold Natural Irish Butter (Aimee)
Star Wars (Joe)
@iammerrick (Joe)
Greg Wilson: What We Actually Know About Software Development, and Why We Believe It's True (Joe)
The U.S. Military (Joe)
Operation Code (Aimee)
Ruby Rogues Episode #184: What We Actually Know About Software Development and Why We Believe It's True with Greg Wilson and Andreas Stefik (Chuck)
Serial Podcast (Chuck)

 

Oh, it's so sad I have to cut off my Star Wars music.

Hey everybody and welcome to episode 194 of the JavaScript Jabber show. This week on our panel we have Aimee Knight.

Hello.

Jamison Dance.

Hello, friends.

Dave Smith.

May the force be with you.

Darth Vader. I mean, Joe Eames.

[Chuckles] Oh, man. Now I wish I had some [inaudible] response.

That's just how Darth Vader giggles in the movie.

It is. It is.

It's the Darth Vader giggle. Hey, everybody.

I'm Charles Max Wood from DevChat.tv. This episode should come out right before JS Remote Conf. So, if you want a great online conference, check it out. We do have Aimee from this show and AJ from this show speaking. So, it should be great. We were talking a little bit before the show.

About Star Wars.

Yeah.

Of course. [Laughter]

And so, this week we're going to be talking about Star Wars.

That was my show idea. [Laughter]

That was my show idea. I wanted it to be about Star Wars.

And it's all Joe had.

That's all I had.

That's all he could come up with.

So, if you don't want spoilers, then don't listen to Joe's outtakes.

It's like the episode of The Simpsons where they show Homer's brain and there's that Mickey Mouse cartoon just going on.

That's all he has in his brain. That's like, it's just lightsabers.

For Joe?

There's a little thought bubble above Joe's head with lightsabers in it.

So much of my sample data for my courses for Pluralsight are Star Wars sample data.

I have to say my boys got lightsabers, that when you swing them they make noise and when you hit stuff it [makes lightsaber sounds].

Oh, that's awesome.

Oh good, [inaudible]. I love it. Awesome

I played with those for like an hour.

Oh.

I was so amused by all the sounds. And you swing it [makes lightsaber sounds]. I'm just like…

You were reverse-engineering it, weren't you? [Chuckles]

No, I was just swinging it to hear it make noise.

I actually heard that when Ewan McGregor was in the lightsaber battles, he kept making the noises with his mouth.

And they had to like, edit them out because he was ruining the scenes.

Yeah. That's my Star Wars trivia.

[Chuckles] That's awesome.

So, what is our topic for today if it's not Star Wars? Or is it actually Star Wars?

I don't know. I'm kind of tired of the topic already.

So, it's the JavaScript tool fatigue that people have been talking about on the Twitters.

No pun intended.

It is the JavaScript star wars. Because there, stars. [Chuckles]

Oh, there we go.

Oh, yeah. The stars are fighting.

Celebrity wars?

Oh. [Inaudible]

So, Jamison kind of brought this to our attention. I think he's probably best versed to get us started with this and give us kind of an overview of what people are talking about.

Sure, I can attempt it. And this will be biased and leave things out, I'm sure. But it should get us started.

I'm also going to mention that the show notes are going to have lots of links to Twitter.

Yup. So, the basic idea is this comes mostly from the React community but it's kind of spread to more general JavaScript stuff. There are all these awesome tools that help you write better JavaScript. There's Babel and Webpack and Browserify and ESLint and TypeScript and Flow and things like that. And they all add overhead to setting up and working on a project. They all have separate configuration. They all have different things that you need to learn about them that aren't just like writing your app.

And some people, there was this article that kind of blew up on Medium, and then a bunch of tweets on Twitter by various famous people in the community both complaining about it and saying like, “I'm an expert JavaScript developer and it takes me a day to get a project started. And then also people on the other side saying, “But look at all the awesome stuff we can do with these tools. You're complaining about things but it's so much better than it was because we can do all these great things with JavaScript today that we couldn't before.”

So, who's right?

Surprise, surprise, I think they're both right. I think the answer lies in the middle. But the basic conflict is it's harder to start a JavaScript project using the latest state of the art tools now than it was, I don't know, a couple of years ago. Because there are more tools and they do more. And yeah, that's kind of my summary of it.

Right. And it's not just about more tools that do more as well, but the tools themselves each have their own separate setup. So, they've added some complexity to the setup.

Yeah, yeah. That's a good way to summarize it. There's a lot of added complexity if you want all the cool new stuff.

Is part of the problem also that we've seen a lot of tool churn over the last year or so where things have come into fashion and then gone out of fashion like, I don't know, [what is it], is Grunt now out of fashion, Gulp is the new hotness?

Oh, no. You're way behind.

[Inaudible] out of fashion now.

Just Babel's churn is [inaudible], you know?

Yeah, but the people outside the community, the people outside the JavaScript community, that's kind of the classic tool conflict they see is, “Oh, we had Grunt and now we had Gulp and then we had something else that's another task runner.” And they each have their own setup and so when I migrated from Grunt to Gulp I had to rewrite my config. Except you have this times a hundred for each tool, you know, one for each tool.

Yup. I think that's definitely a part of it, Dave.

Yeah. Some of it is the churn. I think some of it is also genuinely, I don't know, maybe changing best practices. I don't want to say new things because I'm sure these things have existed in other tools. But I feel like the expectations of the community that you use something like a linter are now a lot stronger than they were five years ago or something. So, if you just pull open a JavaScript project on GitHub it's going to have more metadata at the top level of an actual source code by far. You'd have like ten dot files and…

Oh yeah.

There's just a lot of setup. And the conflict is that the toolmakers are like, “Yeah, we did these things and they're awesome. Why are you complaining about them?” [Chuckles] Like kind of, “Stop your whining. This makes your life better.” And then there are beginners that are trying to learn the language and then they're just overwhelmed by an avalanche of stuff that isn't getting your work done. It's like, all these things that people tell you, you have to have, but they're all added complexity. And then there are kind of some people in the middle that are maybe not beginners but also are just looking at it and saying, “Why does it take me a day to start a new project using all the best practices?”

Well…

So, there are all these people with different wants and perspectives. And they're all kind of talking past each other I feel like at this point.

Mm, maybe.

The other thing though is that I think we've also gotten used to some of the more cohesive, some people would use the word monolithic systems that sort of tie all this stuff together for you to do them the way that they expect you to do them. And so, when you go and you set things up, okay, drop in whatever framework. And then you're pretty much done. And now that we're seeing this growth and this progress with JavaScript, people are kind of expecting the new tooling to be as cohesive and as automatic as the older systems used to be.

I think that's a good point. Another good point is some of this is exacerbated by the kind of React style of building applications where you use React but you have to use other stuff, too. It's not all bundled in together. And the fact that you have to use other stuff means you have to pick the other stuff, you have to learn the other stuff. And everyone picks a different subset of things. It's kind of interesting.

The Ember team has put a lot of effort into this tool called Ember CLI which basically just unifies all the build and test and kind of all these tooling steps. It bundles them into one tool and makes it a lot easier. There's only one thing you have to learn. It's all built-in for you. And they're kind of like, they're not being mean about it but they're using this to point out, “Hey, this is a good thing about Ember. If you are fatigued by these things, then check out Ember, because we have this built for you.” So, that's kind of interesting. Even within the JavaScript community there are different perspectives on it.

So, are some of these technologies just popular kind of ahead of their public consumability then?

Ryan Florence had an interesting tweet talking about it. He said that there are different requirements in a project and different developers that are better at different things. So, some people are really good at the initial burst of ideas and prototyping things out. Some people are good at taking in lots of contributions from other people and running an open source project. And some people are really good at the user experience side. And those are all different skill sets that we kind of… I guess it's unrealistic to expect one person running a project to have all those skill sets.

So, I think some of it might be due to the fact that yeah, these tools are still in the burst of cool ideas phase, which means they haven't had the developer come in that has, that cares a lot about the user experience of the new developer or maybe someone that's not an expert JavaScript developer, that just is trying to get stuff done, and making it easy for them instead of making it possible for experts to do cool stuff.

Right. Well, and I think another big issue with this is the fact that this is happening in JavaScript, right? If this were happening in a different ecosystem somewhere, then… JavaScript is what everybody just about has to deal with. It's hard to find jobs where you don't have to deal with a little bit of JavaScript here and there. And so, you got a lot of people who do JavaScript just a little bit, or new developers. JavaScript is a great way to learn programming because it's ubiquitous. It's in every browser. You don't have to install anything in order to run JavaScript.

But once you get past that, “Oh, I'm going to open up the console and play around a little bit,” or go through a tutorial on Code School and I want to do something real and you hear React, oh my gosh. There's a huge gap between, I just barely started coding in JavaScript and now I want to do React. Right? So, it's so pervasive that there are a lot of people from a lot of varying backgrounds that are affected by this. Where if we were talking about difficulty in setting up maybe one particular server-side language, the conversation might be more limited.

So, is that an experience gap? Or is that what you're saying Joe?

Well, I don't know that it's necessarily just an experience gap. But I think we're just seeing a lot of developers from a lot of walks of life that are all getting involved in this. On the other hand, was it Christopher Chedeau, right?

CHUCK: Uhuh.

He's the one who tweeted, what did he say? I can't believe how difficult this is to set up a JavaScript application in late 2015. His tweet was pretty interesting.

We got the hot takes from Twitter.

Yeah. I mean, and Christopher is one of the Facebook guys. And so, even here, one of the most advanced well recognized developers in frontend is still saying, “Yeah.” So, it's not just inexperience. I think he's reflecting and seeing and admitting the fact that it is complex. So, it just exacerbated when you talk about people that don't have the experience, aren't primarily frontend developers, maybe are new to development. Or whether they're not, maybe they've been a .NET or a Java developer for a long time. They're just barely getting into JavaScript. Or they've been doing just a little bit of JavaScript. Now they want to do something more serious and they're seeing… you know, imagine you've been a .NET developer for eight years. You've been doing a lot of web and some JavaScript but all of a sudden your company says, “Great. We're going to do a React project.” And now you go to look into how to set up a React project and it's entirely, it's so much different than the ecosystem in .NET, right? It's not just a couple of install clicks anymore.

So, are we talking about React or are we talking about JavaScript? Because it seems like a lot of the JavaScript stuff, you can still get away with using ECMAScript 5 and just doing things the way you've always done them.

Oh, sure. That still works.

And plug in jQuery. So, it's… is it…

But it's…

Are we talking about adopting new bleeding edge or close to bleeding edge technologies then only? Or does this affect the broader JavaScript group?

So, if you just stick with the tried and true stuff, you're missing out on potential advances. And if you're always on the bleeding edge you're going to go down some wrong paths that people turn out to realize weren't the right way to do things. But just saying, “We'll stick to jQuery until they get this figured out” will work for some people. But to some people it feels like they're missing out. And then to some companies, I think it would make them less productive overall than if they'd tried to find the new better way to do JavaScript.

So, here's an interesting quote from Michael Jackson that directly relates to this. He says somebody was talking about how it's too much cool stuff. I don't have time to stay current with it. And Michael Jackson says, “Time is always a problem. If you can't make time to learn this stuff, you're free to build sites like you did two years ago.”

So, what's the downside, then? I mean, it works, right?

Well, yeah. So, you won't get some of the cool productivity niftiness and you also won't be able to take advantage of new features. But you know, you can keep going.

And you also got to look at the fact that it might be like, “Oh, it takes me an extra 10 or 20 or 30 hours to set up.” It could be a big payoff in the long run. It will save me more than 30 hours in the long run. But right now it's a big pain. But that doesn't change the fact that it's a big pain right now and there are people that don't like the fact that it's a big pain right now.

Yeah, totally true.

Yeah. In my experience, that's definitely what I've seen from people. Like, you guys are mostly in Utah so you guys are like in the JavaScript Mecca. I'm…

Oh, jeez.

You are welcome…

I thought it was Star Wars Mecca. [Chuckles]

You're welcome to make a pilgrimage whenever you want.

[Chuckles] I wish. You know, my experience, on the east coast, in Baltimore, it's smaller. The majority of people I talk to, it is like the churn has turned them off so much that they just do not want to hear about it. They just want to do their job and just… it's, I don't know. For me, because I'm newer I have this insatiable, like I'm thirsty and you know, want to do more and more and more. But it seems like people that have been around for a while are just kind of burned out from the churn.

Well, and you also might not have their perspective of, for 10 years I've been doing things…

Yeah.

That didn't have a bunch of churn.

Yeah.

Now I'm getting… I need to do this stuff. And look at all this churn. This is crazy. You know, I didn't have to live with this before? Why do I have to live with this now?

Yeah.

Yet on the other hand, I don't want to miss out on really good features either.

Yeah.

Yeah. Like, there's been… it's like been slow to adopt ES6 and slow to want to look at Angular 2 or React. It's just been very difficult to try to have conversations with people about that. Some people are definitely open and then others just, not so much.

Well, and I talk to a lot of Ruby developers. So, JavaScript isn't even the main technology that they're using. It's almost a secondary thought when I need something fancy on the frontend. And so, trying to convince them that A, I need to look at some of the tooling and some of the nice features that come with things like ES6 or TypeScript, plus possibly JSX and React, or Angular or one of these other things, as opposed to just using jQuery like I always have… and it's a painful thing. And then directly related to this tool fatigue, a lot of those don't plug in neatly to the Rails Asset Pipeline. And so, I have to essentially create my own tool chain in order to make it work. And that just seems like a lot of work for a benefit that may or may not actually exist.

Isn't it true that creating your own tool chain is a time honored tradition for pretty much every JavaScript developer? [Laughter]

Right, but these are people that don't identify as a JavaScript developer.

Oh, I'm not saying it's a good thing. [Laughter]

Right. So, [inaudible]

Yeah, that's another barrier.

That friction with your server-side could be painful.

Oh, yeah.

Like in .NET, this NuGet package manager has become all the rage, right? And then everybody over here is saying, “Nope, you got to use npm.” In fact, Angular 2 which has just gone into beta has publicly said, “We deliver through npm. That's how we're going to deliver. That's how things are done nowadays. That's how we're going to deliver. We're not going to deliver through other means, through Bower and download off the web. We deliver through npm.” And that makes a lot of people upset.

Mmhmm.

I think it's really, really important too to keep in mind that from the people that I've talked to going to conferences across the country and stuff, not everyone works a 40-hour work week. Some people work 25, 30 hours and get the rest of their time to do open source. And then other people are working 60 hours a week. So, be careful to call people lazy. They might just be putting their hours in differently.

Yeah.

So, Joe and Chuck, you both kind of mentioned the people that aren't mainly JavaScript developers. And I think the takeaway for them is be a year or two behind the curve if you don't want to dive into the craziness. I kind of imagine it as like there's this swarm of bugs devouring a forest or something. That sounds kind of destructive. Maybe they're building cool little bug houses behind them. And if you're like up the front lines in the middle of the swarm, things are nuts. It's like this madhouse of wood chips flying everywhere. But you get to see the cutting edge. And if you don't want to do that, then just be a little bit behind. I think that's perfectly find advice. And that's kind of like what Michael Jackson was saying, too.

Yeah, the other thing is that specifically with Rails, since we're talking about these people, there is actually a React Rails gem that actually does set up a lot of the tool chain for you. And I mean, it's not perfect, but it does handle a lot of the JSX, Babel. You know, there's a lot of stuff there that it does for you. And so, you can get away from… or you can get away with hooking this up and adopting somebody else's tool chain. The problem is, is that if there's a problem with the tool chain or it doesn't do exactly what you want, then you have to become an expert in that tool chain.

Right.

Eh, problem solved.

Or just wait a couple of years and someone else will figure it out.

Yeah.

Well, but one thing that's also important to realize here is developers also have to operate at the pace or cycle of their projects. So, you might have been doing a Backbone app for the last four years, right? And all of a sudden it's time to go, you got a big new project. And so, what are you going to do? You're going to do Backbone again because you know it? No. Or are you going to look and say, “Well, the current-day technology has some churn and it's hard so I'm going to go and pick the two-year old technology on a project that's going to be alive for six years.” That would be, now you're talking at the end of its life cycle, it's using a technology that's eight years old. So, you might be looking at that saying, “We need to be using what's current now so that five years down the road it's not so… it's less antiquated than it would be.”

Mmhmm.

So, now you feel like you're forced to use what is hot today. And if what is hot today is difficult to work with and set up, then that could be a struggle for you.

So, I think I hear Jamison's point that if you adopt something that's a year or two old and has solid tooling and solid processes around it, then you don't have to become that JavaScript expert. You just have to be good enough to set up somebody else's tool chain and make it work for you.

Yeah, but there's one other thing you have to do in that case, which is ignore a ton of hype.

Yes.

And also a bunch of complaining, because two-year-old stuff tends to have people who have had problems with it and they speak vocally about it. And then you have to be willing to say, “I'm going to use this despite all the haters.”

Yeah, instead of using the thing that they haven't discovered the problems in yet, because it's new.

[Chuckles] Yeah.

Yeah. But let's ignore that case for a minute. A lot of our listeners are people who are actually involved in JavaScript. They want to be involved in the new, hot thing. They want to be learning these new technologies. They see the promise that exists in React, TypeScript, Babel, whatever. And so, they're looking for the opportunity to pull this into the project, really get to understand it, and have it solve a lot of their problems and make their lives better. So, where do people come down on that? How do you decide whether or not you have the time to deal with the tooling issues now and deal with that fatigue rather than actually just wait a little while until somebody figures it out?

For me, I've been dealing with this a little bit. I think it's like maybe a bit of a personal decision. I know at work that I have some ambitions that I would like to bring onto our team. And because we have certain deadlines that we need to meet, it is, if I want to do this, it's going to be on my own time. So, it's not something that work is going to provide me the time to research.

It kind of makes me sad. I guess that's hard to get around.

Slacker works. [Chuckles]

But I mean, I feel like that's going to be the case for a lot of people.

Oh, totally.

Yeah, it's true. Tooling can be really hard to justify the investment in for sure.

Well, especially if they're used to using another technology that was much easier to set up. “You spent a week figuring out how to get all this stuff to work? Why are we even using it?” And…

On the same token though, like some of the Twitter conversations have said, it is like, it's a great learning experience and it's rewarding. So…

Oh, totally.

If… like for me, I just set certain goals for each quarter and that's how I fit it into my personal time.

Yeah, I could just see some manager coming in though and saying, “So, how's it going with the new framework?” and…

Some developer having to justify the fact that they spent a whole lot longer than it took with the previous framework.

Yeah.

To just get it set up and going.

Well, and one other thing, too. So, just because you put in the time and you're able to show a prototype to your manager that works and is efficient, then you also have to get everyone else on the team on board because there's going to be a learning curve for them involved. So, just because you're able to solve the problem doesn't necessarily mean the whole team's going to adopt it either.

Right.

I know, I think it was Merrick, maybe he wasn't the first person to talk about it. But I know he did mention it. He said that maybe a good approach is instead of… there's a lot of cultural stuff going on here where to be a cool JavaScript developer you have to use the new thing. And there's a lot of hero worship in the community where we love the people that make these exciting blog posts about the cutting edge and we want to be like them. And he suggested maybe that's doing a disservice to people that are beginners and programming more in the language. Because you're forcing solutions on them before they've encountered the problems. So, if you're just starting a new JavaScript project, just like make it a file. And then load that file in your index.html and wait 'til you need modules. And then show them okay, if you need modules, you can use…

Yeah.

Webpack or Browserify or things like that and do it iteratively instead of just saying, okay to start you need these 10 dot files. And then you need a bower.json and a package.json. [Chuckles]

And you need Stylus and then you need Compass because Stylus doesn't work well with [these two things].

And it's just like 10 tools before you write a line of code.

Yeah. Like the downside to that is you're learning all these tools without the knowledge of what they're actually being used for. Because you don't have that context yet to know what problem they're solving.

You mean, if you just learn them all upfront because that's what everybody else uses?

Yeah, yeah.

Yeah, yeah.

You don't have the context to know. I know, when I started learning, I started off with Rails. And one thing that our instructor did at the bootcamp was they had us do a plain old Ruby project and then convert it to Rails so we had an appreciation for what Rails was doing.

Mmhmm.

I like that a lot.

So, I think for JavaScript, if you are starting, start with like you just said. Just put in your script tag [chuckles] and go like that. And slowly but surely…

Maybe you don't need async/await in your first JavaScript project. So, you don't need Babel and all that stuff.

Well, that's a great point. But there's also a reason for abstraction. Like, we don't start off by learning Assembly so that we can appreciate C so that we can then appreciate…

I did. [Laughter]

To be fair, I started off learning Visual Basic and then Assembly. But whatever. [Laughter]

But the great thing about Assembly for example is you really… it's rare that you need to understand Assembly. Like, super, super, super rare.

Totally, totally.

I don't know Assembly. It hasn't hurt me in my career so far as I know. Maybe I would be a better developer and more awesome if I did. But so far as I know…

I'll just silently judge you a lot less.

[Inaudible] some raw EAX instructions.

But the difference is Assembly and the abstractions over Assembly are very solid. And they're not leaky abstractions. When you get to, when you talk about the tool chain in JavaScript, even if they were easy to set up, they would probably be not very solid and fairly leaky. So, that needs [inaudible] better.

Can we have confession time?

Yes.

I can't figure out how to get source maps working. I am a professional JavaScript developer and I just fail to do source maps.

How does that go in the Star Wars movie? No! [Laughter]

[Inaudible] I'm shaking my fist.

I know what they are. I know how to use them when they're there. But I just like, I tried for a couple of hours with the tools and I was like…

Every time I've tried to get source maps going, they slow down my build so much that I'm not able to use them.

I just [inaudible] crashes in Webpack when I try and do source maps.

I thought the way that you do source maps is the flag in TypeScript and that's it.

I don't… whoa. I guess now I got to change my build process, add another tool.

Yes. [Laughs]

That's right.

That's the only way I've ever done source maps, is because TypeScript did them for me.

Yeah.

So, here's my confession. On our team we've been using a homegrown concatenator for all of our JavaScript code for the last four years, because four years ago we couldn't really find anything and we just decided, “Ah, it's easier to concatenate a couple of files.” And then that grew of course over the course of four years into thousands and thousands of files. And this is the problem with not adopting tooling early. Well, first of all it wasn't available four years ago. But even if it had been… now if we don't adopt the tooling early it's really hard to retrofit our codebase to use the tooling. And so, it took us about six weeks, one full-time developer to port the system to Webpack. It was a monster effort. It's way cool now that it's done and it does some really slick stuff. But man, was it hard.

It would be an awesome episode to do JavaScript confessions where we just talk about all the horrible things that we do in real life.

I have multiple confessions. [Chuckles] So, we still use Gulp for eight of our APIs. Or I'm sorry, we still use Grunt for eight of our APIs. We only have Gulp on the frontend. Our frontend still has dollar scope all over it. We're slowly migrating away from that. And we have yet to put in a module loader.

Do you concatenate or minify?

Yeah. We just all have it in like a Gulp workflow. We don't have the modules though. We're just using like [inaudible].

Oh, oh, oh, yeah. Everything's global, effectively.

Yes, yes, yeah. Well, we have everything around in if/e's.

Mmhmm. But there are no modules.

Just, well Angular 1.

Just Angular modules? [Chuckles]

Yeah, yeah, yeah.

But you still make money at your [inaudible].

Yeah, I mean we're productive. [Laughter]

You get paid to do this? [Laughter]

I thought we just crucified people who did that. [Chuckles]

I just want to make one more point about what Aimee and I were talking about, about iteratively arriving at the newest solutions in response to problems. And not being cool enough doesn't feel like a real problem. Like you're not cool if you use Gulp so you use Webpack. That doesn't seem like a solution to an actual problem. If there's something you can't do in Gulp, then maybe that's a better solution.

I think you're saying that my feelings aren't real.

I mean, isn't that what I'm supposed to say as a computer programmer?

[Laughs] True.

No, well, what do you mean by that? Because there could be something good there.

I mean, I feel cooler when I use Webpack.

Yeah.

That comes down to a maturity thing, I think and being able to identify…

Oh, oh, man.

Oh no, that's not what I mean.

I feel like I'm talking to my therapist.

Well Dave, if you were mature like me, you would recognize…

No.

I think part of being a mature developer is identifying when you want to use something because it's cool and when you want to use it because it solves a problem. And I struggle with that. We use Elm at work because it's cool, right?

Yeah, because it's cool.

It has other reasons, too. But…

But that's the main one, right? [Laughs]

Yeah, so I can brag about it on this podcast.

And then the money just flows in after that. All those [inaudible]

So, I have to ask. Do systems like Elm have this issue as much? And you know, does Ember CLI completely eliminate it for Ember?

I have not actually used Ember CLI since their 1.0 came out. So, I'm not a good person to talk to about it. But it would be really interesting to hear from somebody on the Ember CLI team.

Yeah, I'd love [to hear about it].

Elm avoids this issue by not having as mature a tooling basically. They haven't reached the state where they're working this much on developer experience. They work a ton on it in compiler messages and things like that. But there's… I think they still have some other problems to tackle before they're going to work on loaders and, I don't know. They just use Gulp or Grunt or Webpack or whatever for all their stuff now.

So, I have a slightly different perspective on this situation. But I'm not totally sure if it's legitimate. Maybe I'll just throw it out there and see what you guys think. But I feel like this is an aftershock or a ripple effect of really the original JavaScript language design and how it was… I mean, I don't want to like, throw a bunch of blame on Brendan Eich for building it fast. That's not what I'm saying.

But what I'm saying is that it's basically been crowd-sourced designed ever since its inception. And it's not just language features but how you deploy it. You know, like for example, the fact that we put script tags in HTML and load it and then everything becomes global that was defined in that file… and then developers have to figure out how to optimize that because if you have too many script tags your page loads slowly and so on.

And so, that over time, we've always been like this where it's like, “Oh, I've got an idea for concatenating your files,” or you know, “I've got an idea for minifying your JavaScript.” And this just comes from the community. But now the stakes are really high because we have more people writing JavaScript than ever before and they're building applications that are probably more mission-critical than ever before. And so suddenly we have this like  high-pressure situation with a ton of people working in it. And someone releases this whiz-bang tool and people are confused about how to use it but there's all this on the line. You know, like… and there's tons more people using it than ever before. And I mean JavaScript as an ecosystem. And so, I feel like this is coming out now because it's basically the natural consequence of a crowd-sourced design effort.

What's the solution to that?

The solution is had it all over to Microsoft and let them tell us how to do it.

Nice.

So, it's really interesting you brought that up, because that's one of the arguments for Elm, is that JavaScript is wildly popular and incredibly successful but it has a lot of baggage. And if you start over knowing what we know today about building languages and ecosystems we could do a better job.

Oh yeah, that's the other thing. You say start over and that's I think one of the causes of the things we're experiencing today, which is in a crowd-sourced ecosystem of tools, nobody cares to maintain the old tools. If someone has an idea, they can just build a new one and then it takes over. And so, there's no incentive to go back and maintain say backward-compatibility with the old tool or provide an easy migration path to the new tool, because it's completely different people building these things. Whereas when you have a, I'll just say a cathedral style framework that's handed down from a company or an organization, they have this incentive to keep people engaged and make it easy for them to switch between versions of their stuff, whether it's a framework or whatever.

So, I just want to… oh, go ahead, Chuck.

Is that a solution then? Everything just becomes centralized?

Oh, I don't… I think it is a solution but it's not necessarily the only solution. I don't think it's the solution for JavaScript. In fact, I think JavaScript is wildly popular precisely because there has been no entity doing that. And so, the community is free to innovate in crazy, disruptive but sometimes hard to understand ways.

I love the JavaScript community and the mad like hothouse of activity is one of my favorite parts of it. So to me, that means the solution is more mad hothouse activity.

Yeah.

It means…

You know, I agree.

So, somebody building more cohesive tools? I mean, what is the solution that you're aiming at, then?

The solution I'm aiming at is for it to be easier to set up and run a project. And I think the way you get at that, actually Christopher Chedeau, we've talking about him already, he kind of issued this rants manifesto about how hard it was for him. And he said, someone make this easier. When I did PHP I had one editor, I wrote a PHP file, I uploaded it to a server, and that's how I prototyped and worked on my site. Someone make it as easy to do as it was in PHP. And because he's famous and nice and people like him, a bunch of people went on and made projects in just a couple of hours. They were like, “Hey, check it out. This is a cool solution to it.” So, I think the solution is harnessing that activity in the JavaScript community and making people aware of the problem and then just throwing it out there. And people will make cool solutions to it.

Totally agree. Totally agree

One other, I wanted to talk… oh, go ahead.

Before we jump on there. I don't think we'll ever get consensus. I think that this kind of struggle is inherent in the system. So, I don't think there's a solution. And I don't think we should be shooting for a solution either. But I [inaudible].

I think yeah, consensus would destroy what makes JavaScript great.

Yeah, yeah. And if… honestly, if you're not going to be able to get comfortable with that, then you have two options. You can either stay a couple of years behind and take all the lessons learned and be a wise person about it, or you can change to using an ecosystem, joining an ecosystem that has this kind of handed down from on high mentality. And I think those are two perfectly fine options for people. Everyone doesn't have to be in the hothouse.

I also want to talk a little bit about the kind of human interactions that are happening here. Because I think when people are complaining about how hard it feels or how fatiguing it is, I think a lot of the people that make tools can feel personally attacked sometimes. Because if you make Webpack and then you hear people complain like, “Webpack is so hard to set up,” it's hard not to take that as people are attacking my work.

An attack on your work.

Yeah.

As opposed to, yeah and we're seeing people come out and basically say, “Well, it was a lot worse before I made Webpack.”

Yeah, yeah. So, I think some of the toolmakers are getting defensive because they feel attacked. And maybe some people are attacking them and say like, “Hey, you suck because you made Webpack and I hate you,” and stuff like that. But I think it's important to recognize that, to me, it doesn't feel like a personal thing. I guess it could seem ungrateful like, “You whippersnappers. Back in my day we had script tags and that's all we had.”

But I don't think it means you're ungrateful if you're complaining about the developer experience. I think it means that something could be better. And maybe you want to bring up the problem so someone creates a solution. You're kind of bringing to light a problem instead of complaining mindlessly, I guess. Does that make sense?

Yeah. And a lot of it goes about how you go about doing that. That really depends on how things are received. But imagine if people were more critical of new, innovative solutions that didn't integrate well with existing solutions, right? Somebody came out and said, “Webpack really sucks because it really doesn't work well with all these other, the rest of this tool chain. It takes a whole lot of energy and effort to set it up and it should have been done this way.” Well now, you're adding all this overhead for anybody that wants to build a new, innovative solution. So, that's not a good thing either.

But on the other hand, if the new hotness, whatever that is, integrated super well with everything else such that you didn't have to know a whole bunch, you just added one small little bit flipped right here and all of a sudden this thing was now working… imagine if you wanted linting all you had to do, it was as easy as adding source maps to TypeScript, a little flag in your command line, nobody would be complaining about linting, right? Yet, is it the… is it the responsibility of the people who are making linting tools to make sure it integrates well with whatever solution is out there?

I think if you say that, then they won't make them.

Yeah, exactly.

Because it's too much of a pain to do that when you're just trying to make a cool tool.

You want those innovative solutions. But also, people want to have… the more that you can bundle things together and make it easy for people without having to understand everything and spend hours setting it up, the better it is.

There are a lot of good examples of that I think already. And like, I'll just give one example. Like when I set up Karma for the first time to do JavaScript unit testing, it automatically loaded Jasmine and automatically loaded Istanbul for code coverage reports. And I didn't even know it was using those under the hood. And all I knew was I had awesome code coverage reports and a great expect library, or assertion library. And it just worked. And I followed their documentation and it was great. And it's almost like we need more of that. People who are willing to write these glue-ish frameworks that bring tools together for people instead of saying, “Here's a command line utility. Now you have to do everything else.”

Right. Now, let's be fair. Karma was built by guys at the Angular team who their job was to build this tool. They weren't doing it on the site. They had a lot of resources available and time. And they had a lot of really, really, really high standards as well before putting the tool out. And they innovated a lot. And the infamous, their first [inaudible] name which I think…

[Chuckles] Yeah.

Ryan Florence single-handedly got changed was…

[Laughs] Yeah.

An example of the fact that they didn't do everything perfectly. But they had a lot of momentum to get it done. So, we do need more tools like that.

It's hard, right? It's hard for individuals to do that [inaudible].

Yeah.

Mmhmm.

WE do need more tools like that, but we don't want people to have one innovative idea and one solution to not do it just because they don't have the time to make it perfect like the Angular team could have made Karma.

Yeah.

Which is why we all need to be really nice to the Babel author. [Chuckles]

Yeah.

It shouldn't feel like the open source thing where someone makes an issue that's just so entitled and like, “Why doesn't this work for my exact use case, you moron?”

[Laughs] Right.

And then the classic response is…

Mandrake Linux.

Like, “I'm doing this for free. Pull requests accepted.”

And of course we want the people with the problems to go out there and say, “Hey, I've got a problem with this working. I'm going to work on the original tool to make it work better with a bigger ecosystem.” But on the other hand, we also should be understanding of people who don't have time for that, or the capability, whether it's experience or just understanding of the ecosystem. I mean, it could be scary, right? I want to contribute to some open source project so I go in there and try to make it work, to think that I might submit a PR and have that come back rejected because, “You didn't think about this, this, this, this, and this.”

Yeah.

And it comes off making me feel like I'm an idiot for trying.

Mmhmm.

It can be really painful.

But yeah, to be clear, the tools that exist today are awesome. And if I complain about them, having… let's see, how do I say this? If I complain that they could have better user experience it's because I want to use them so much because they're so awesome.

Right.

And I want them to be easier to use for everybody, not because I'm like entitled or I think they suck or anything.

Constructive complaints, huh?

That's very well said.

Well, they're not just…

Yeah. I wish I said it that well all the time. [Laughter]

They're not just awesome. They're necessary and important, these things. We're building important thing with these. I thought of a personal experience, a very personal experience that I think it kind of relates the fact that those who are complaining, it's okay for the tool authors to stop and step outside of themselves and realize these people are feeling pain and to be able to empathize with that. And it would be great if the people who were complaining could stop, get outside of themselves and look at the tool authors and realize that their complaints might cause them problems. But for either side, there's pain going on and empathy will fix that.

As an example, when my 13-year-old daughter was just barely born she had some real medical problems. She ended up in the hospital for a long time. And the doctors had zero clue what was going on, what was the issue. And she was losing weight and they were afraid that she was going… you know, an infant, a six-week-old infant losing weight is going to die. That was where she was headed. And she was in and out of the hospital. And we were frustrated because the doctors had no idea. They tested and tested and tested. Nothing came back with any information as to what the problem was. And yet she still continued to lose weight.

Finally one day, my wife started feeding her solid food before she should have, before they tell you to, the rice cereal. And that fixed the issue and then she was fine. The entire time I was very frustrated by the medical profession. But that doesn't mean that there's anything wrong with the medical profession or that the things that they have done and all the lives that they save is a bad thing. Just at that moment, I was feeling a lot of personal pain and I was venting it in a way that if I had said some of the things that I said in private to a doctor he would have been very upset.

[Chuckles] Yeah, yeah.

Like I was attacking him and his work. And at the moment I had that pain. I wanted to attack him. It was very frustrating to me, right? And so, it's possible to see both sides of the story but yet at the moment be in so much frustration that it's hard to look at the other side.

So, your daughter almost died. I upgraded from Babel 5 to Babel 6. [Laughter]

That was my analogous experience.

Yes.

That's basically the same thing, right?

Yeah.

Basically the same thing.

I feel like we understand each other.

Except there's a big difference because your doctor won't accept a pull request.

Right.

Yeah, that's true. [Laughter]

Damn doctors.

Listen, I thought about this. I read some stuff on Wikipedia and I created this serum myself. [Laughter]

No, that's alternative medicine though. So, you can… [Laughter]

Okay, so it's there. That's open source. It applies to medicine.

Yeah, you just say that I founded an elixir of health. It's in beets. Cures everything.

Yeah, that's right.

Beets are awesome.

I think in defense to the tool authors, we're the kind of people in this community that pour a lot of ourselves into our work. So, it's easy to take things personal.

Oh yeah, yeah. I'm not blaming tool authors for getting upset at being criticized.

Oh, yeah, yeah.

Because I would feel criticized too, if people said the things that I said about Babel 6 about my work.

Yeah, yeah. [Inaudible] yeah. [Laughter]

It's easy to feel that way.

Yeah, yeah.

And maybe rightfully so. You pour a lot of yourself into it.

We just all got to hug it out.

Mmhmm.

Well, I think it's great that people tie their personal identities to their work. Not because that's necessarily healthy but because it means they're really passionate about it.

Yeah.

And I love that about this ecosystem.

Yup.

[Chuckles] I thought you were going to say it's because it means they work really hard and just do all this work for you for free.

Yeah, they do all this work for me.

Yeah.

Yup.

CHUCK: So…

They're basically my employees. [Laughter]

I pay them nothing. They are slaves. So, Dave recommended in the chat that we take a few minutes and specifically list the tools that are being talked about. And we've talked about a few of them like Webpack and Babel. But other tools or other libraries that we're talking about in particular here?

I think some of it is just all the stuff that comes with React, whether you use Flux or Redux or Relay or there's a bunch of decisions you have to make.

Reflux.

Yeah, about how to do all the rest of your project that React doesn't do for you. So, I guess I don't have a list of specific libraries. It's just…

Some of the ones that come to mind that you have to figure out how to integrate into your system, there's like CSS modules that are super popular right now.

Yup.

Mm.

PostCSS is kind of…

Yup.

Related to that  stuff.

ES 6, ES 7, linting.

Yeah, linting.

It's not specifically tools, but I mean TypeScript is getting super popular now.

Yeah.

Yeah, and [inaudible] type…

Which adds another layer of tools, right?

Yup.

It's hyping in JavaScript, it's now becoming more and more popular.

And then lots of these will end up having editor integrations, too. So, if you have linting and typing then you need to set up the editor integration and…

Mmhmm. Not to mention the browser reloading integration like for hot reloading or even just straight up page refreshing.

[Chuckles] Hot reloading is amazing. But making it work makes me want to go…

Switch careers.

I just heard…

It deflates me.

Prediction. I think the mobile world is about to have this whole stuff land on them, too. Because I just say a bunch of React Native hot reloading examples being touted.

Mm.

So, it's only a matter of time.

Oh wow.

And this doesn't even begin to get into…

Which is awesome.

Functional programming, functional reactive programming and reactive programming.

Oh yeah, yeah. There's a whole bunch of RxJS stuff that… I just saw an article today that was about…

It's not really a tool chain, but…

That was about debugging RxJS and talking about new tools and techniques to learn, because the regular Chrome debugger or whatever debugger used doesn't help you that much in a different paradigm.

Before we wrap up, I kind of have a question for you guys. So, as somebody who is newer to the ecosystem and newer to programming in general, there are all these tools to learn. So, one thing that I've struggled with is how much of these tools do I need to learn? But also, there are a lot of just fundamental programming concepts that are important. So, for me the past, I don't know, third and fourth quarter of that has been more of my goal is to step away from a lot of the JavaScript hotness and focus on design patterns and algorithms, data structures, stuff like that. So, what is your advice to people learning? I'm kind of curious for all of you guys what you should focus on.

Well, I spent like four hours today messing with my editor config. So… [Laughter]

I might not be the right person to talk to about efficiently using your time where it's most effective.

Yeah, you didn't even get into the two days setting up your project.

Yeah.

Yeah. [Laughs]

It's easier to switch editors and find new packages and all that stuff than it is to face what do I actually build.

I do want to point out one thing and that is that part of the problem that we're talking about here is the fact that each of these tools are designed to run independently at least to a certain degree. And so, there's no reason why you have to go through the pain of setting up the entire pipeline. You can go figure out one tool at a time. And so, if you want to pick up TypeScript you can just write some simple script in TypeScript and then run the build tool and see what you get. And then once you understand that tooling then you can move into, “Okay, now I want to hook this into this web tool or this build tool or Webpack or Grunt or Gulp or whatever.” And you can kind of figure it out a bit at a time. So, I don't want people to go and try and pick up the whole thing at once because I think you're going to get into a world of pain that even experienced people are going to struggle with.

Yeah, I guess my question is, if I have let's say for me the first year I tried to set aside an hour to two hours a night on top of work and then 10 hours on the weekend. So, if I'm a newer developer am I better off spending my time learning about Webpack and ES 6? Well, maybe take away ES 6.

I think that's important. But Webpack and Gulp. Or am I… like, observables… or am I better off taking time to go through coding challenges or learn design patterns?

So, my perspective on that topic is that for new people, I think fundamentals are always more important than specific tooling. I would say that tools come and go but fundamentals are here to stay. And the better, the stronger you are with programming language fundamentals, design patterns I think are a great thing to study, that stuff is classic and timeless. But Webpack will likely not be around in five years. Whereas…

Programming language fundamentals will. And so, learning that I think is absolutely a great way to focus your time. Now having said that, I do think that there's still value in learning some of these tools and understanding how they work, especially… and a lot of that value can be a more immediate feeling value. Like, you can benefit from a tooling change really quickly but fundamentals sometimes will take time to get benefit. So, I would say a little bit of both. Maybe like 80%, 20%, something like that.

That's perfect.

So, I used to snowboard a ton when I was a teenager. And there's this weird, in some ways the culture around JavaScript feels like the culture around snowboarding in that there's both an emphasis on the substance and also the style that comes with it. So, snowboarders are the most fashion conscious group of people I've ever been around in my life. There might be another one but I haven't been around it. [Chuckles] So, there's so much emphasis around and industry that goes into convincing you, you need a new $500 jacket every year and designing new boards and bindings and boots and hats and gloves. But if you spend all this money on new stuff and you still can't snowboard very well, then you're kind of a poser.

So, in my mind a new board can make you a better snowboarder just like learning a new tool can amplify your ability to build things. But if you don't have the ability in the first place, then you want to be careful of being like the JavaScript poser that knows every build tool but can't build a good application. So, I guess I'm kind of agreeing with Dave that it's more important to know how to make stuff than it is to know the right tooling around it. But you should still spend a percentage of your time because those things will amplify your ability. Does that make sense?

Here, here. I love that. That was a great answer.

I love those answers, yeah. I think that's awesome.

Oh, there is one exception. I think everybody should master Git.

Yeah.

Like, no matter what. [Chuckles]

I don't know, dude. I have feels about Git.

I think I… yeah.

Jamison's a CVS fan.

No. I'm not a CVS fan. I'm like a nothing fan. I don't know anything about another version control system that I'd rather use. But…

Yeah, exactly. Like given [inaudible]

Visual Source Safe?

But I'm sad that Git is the most popular thing, because it is a nightmare under the hood. And then when people wax lyrically about the purity of its object graph model and things like that, I don't care. That doesn't change the fact that there are 400 different conflicting commands to do the same thing.

Except if it's like Tuesday in the eastern hemisphere and you use this other flag. I don't know. Git isn't…

Well, regardless of its problems you should still use it because it's… I think it's here to stay for a while.

Yeah.

I hope we have something better soon. But I got to tell you, people who don't know how to use Git and use Git on their project can make so much work for themselves.

Oh, yeah.

And it's one of those things you really have to understand it deeper than you think in order to not screw it up.

Git, okay. This is great because it's putting in perspective all the JavaScript tooling pain. Because it's nothing compared to the Git pain. [Laughter]

Absolutely.

If you are a Git master then you can never complain about any UX of anything you ever use in your whole life, ever again. Because it's all better.

Alright. And on that tangent, why don't we get to picks? [Laughter]

Well, we didn't talk about Star Wars. Can we do another hour?

[Laughs] I'm down.

Has everyone seen it?

I haven't seen it but I was watching Twitch.tv and people were donating so that they could post messages on the stream that would spoil it. So, I know what happens in it.

Oh, I didn't want to spoil it for anyone.

Because someone donated three dollars to tell me. [Laughter]

Alright. Let's do the picks.

Before we get to the picks I want to take some time to thank our silver sponsors.

js}. Let's face it: errors cost you money. You lose customers or resources and time to them. Wouldn't it be nice if someone told you when and how they happen so you could fix them before they cost you big-time? You may have this on your backend application code, but what about your frontend JavaScript? It's time to check out {Track:js}. It tracks errors and usage and helps you find bugs before your customers even report them. Go check them out at TrackJS.com/JSJabber.]

Jamison, what are your picks?

I have, let's see how many picks. One, two, three… I have four picks. My first pick is this article by a developer named Julie Evans. I love her blog. She has a lot of great stuff on there. But this is an article specifically about 'How I Got Better at Debugging'. That's been a thing I've been into lately, is trying to get better at debugging, at raising the difficulty level of bugs I can fix and getting faster at fixing bugs. And it's a really good overview. She talks about some cool system-level tools that help if you do a lot of server-side stuff like tcpdump and strace. Then some general techniques as well. So, that's a good read.

My next pick is a thing I had no idea. It's a video about the Chrome Dev Tools promises debugger. So, apparently Chrome has this specific tab that will just show all your promises and show them resolved and show the chains and let you inspect them, kind of like the network tab. And it's pretty sweet. I didn't know it was there. So, this was just a little short video about it.

My next pick is the Netflix series Making a Murderer. If you listen to the Serial podcast and you liked that then this is just as good. Folks [inaudible] very different kind of case. But the same type of thing where it takes this event that happened and gives you all the backstory and all the nittygritty details. And kind of asks a lot of questions and doesn't really give you a lot of answers. But I'm in the middle of it and it's amazing.

And my last pick is this article called the 'I Can Tolerate Anything Except the Outgroup'. I talked about this a little bit before the show but it's about how we often form these social filters around who our friends are and who we interact with. This is by a psychologist that, he talked about how he has maybe 150 people he closely associates with. And how not a single one of them is a young earth creationist, even though 46% of the United States believes in that and how the odds of that happening randomly are like a quintillion to one or something like that. So, he very clearly without necessarily meaning to has filtered his group so that he's excluding this large proportion of the United States and how… it's not about a specific political or religious viewpoint. It's just how it happens to everybody. And how we kind of leave out conflicting viewpoints in some ways based on the way we interact with people. So, that kind of just made me sit and think.

Those are my picks.

Oh, for what it's worth I really enjoyed that article as well. And I took out a completely different lesson.

Huh.

Which I won't share right now.

Okay. [Chuckles]

Dave is the outgroup.

But I also took that lesson. [Chuckles]

Dave is the outgroup. Now he knows why he doesn't fit in for certain people.

I am the one in quintillion.

Yeah. Dave, what are your picks?

Okay, I just have one pick for you today. This is a Twitter account that I've been following for about a year. And I really enjoy it. The name of the account is a little bit unusual. But it's called science porn. And it has nothing to do with pornography which I am staunchly against. But it does have a lot to do with science. And it's really cool. And every day they post something interesting that makes me go, “Huh. That's really cool.” And a lot of stuff makes me laugh. So, if you are into geeky science-y humor and math humor and stuff you might enjoy following science porn.

Alright. Aimee, what are your picks?

I have a couple. So, the first one and because we've been talking about tooling today I thought this was fitting, somebody told me to check out PostCSS. Jamison I think you mentioned this when we were talking today. But it parses your CSS and turns it into like an AST so you can manipulate it with JavaScript. So, that is my first pick because I thought that was pretty cool, what you can do with that.

The second one is an article I saw on Twitter this week. And it's called 'The Illogical Allure of Extremes'. And so, this is like perfect balance to what we were talking about with tools and everything. But not… I guess it's a guy who's a Pluralsight author and he just talks about the rewards and the risks that he's experienced from working really, really hard for five years as a developer.

And then my last pick because I like to always pick some of these health nut things, I've picked Kombucha in the past. So, the new thing that I want to pick is Kerrygold Butter. So, you might think, “Butter. That doesn't seem healthy.” But this butter is grass-fed. So, I've been putting it on my vegetables and stuff like that. I don't know. It makes me feel pretty good. So, that is my third pick.

And that's it.

Wait. Butter eats grass?

[Chuckles] That sounds confusing. But the cows who you get the butter from are grass-fed.

Aha.

So, it's really, really, really… they say it's really, really good for you. And as far as for me, the way that I kind of gauge a lot of these things is how, because I'm really, really careful about what I eat, I can tell if something really sticks with me. So, I could have a small amount of vegetables but by putting this butter on top of it, it's really, really filling. So, that's how I gauge everything.

Cool. [Laughter]

It's a good excuse to put extra butter. My husband does, like there's this craze going on where people put butter in their coffee. And they put this butter in their coffee and that's what my husband does. I put it on vegetables. He puts it in his coffee.

[Laughs] Alright. Sounds like he's got his priorities in line.

Alright, Obi Wan. What are your picks?

So, I have five picks. Star Wars, Star Wars, Star Wars, Star Wars, Star Wars. [Laughs]

Alright. Glad we got that covered.

Was that [inaudible] five of the seven episodes? [Laughs]

Yeah.

Which ones didn't you pick?

One and two.

That just so happened to work out. And it was only half of a pick for three. I would also like to pick a Twitter account that I've followed for a long time that is very relevant to the discussion we had here. And that is the Twitter account of Merrick Christensen, a personal friend of mine. I find that when he does get involved in conversations online like this, he always has the most measured and introspective responses. And I'm always enlightened as I read the things that he says about interesting stuff.

I so agree. I feel like he just tweets from on top of a mountaintop somewhere.

Yeah, like…

Gazing into the sky.

He's got to be up there…

Meditating.

Yeah.

All of a sudden he opens up his [Twitter].

He just rises above all the petty nonsense and is like…

What if we just loved each other more?

And also, here's how to do this awesome thing in JavaScript.

Right. [Laughter]

Carved into stone tablets, right?

Yeah.

[Inaudible] So, my other, my third pick is going to be something that he tweeted about really recently and that is this great talk called 'What We Actually Know About Software Development and Why We Believe It's True' talking about the difference between the scientific rigor of knowing things and then all of the stuff that in software development we think is true but we don't actually know, just because there's a common consensus that something is true and anecdotes seem to prove something. But yet without scientific rigor, it's… it's just, it's a great talk. Very fantastic talk.

I loved his point about TDD and Agile development in that, too.

Yeah.

It's really interesting.

Yeah.

That's my tease. I'm not going to say what it is. You got to go listen to it.

Yeah. Definitely go listen. One of those talks that everybody should absolutely see regardless of what kind of a software, where you are in your career and what kind of a developer you are. It's one of those things that is universal in its applicability and enlightening regardless of any viewpoints he might have.

My final pick is going to be the US Military and specifically the people that serve for it,

Aww. [Chuckles]

I think that there's not enough respect for the danger that people put themselves into. Regardless of how you believe our politicians run our military or how much money we should spend, the people that are there putting their jobs on the line for less than what most teachers make deserve our respect. And that's my [final] pick.

Can I, I want to, can I add a quick pick in there? [Chuckles]

Mmhmm.

Absolutely.

So, as we were talking before the show, [inaudible] his brother and he's an Iraq and Afghanistan war veteran. So, I really appreciate that.

And the other pick I'm going to have that I wanted to add on top of that, I am a board member for an organization called Operation Code. And they are working to take the GI bill, which is what you get when you serve because right now the GI bull can only use, more like an accredited degree. And they're working with some of the coding bootcamps so that you can hopefully view that GI bill towards that.

Awesome. So Joe, your last pick or your second to last pick, coincidence of all coincidences, there is an episode of Ruby Rogues that has that exact same title where we had a two hour discussion with those exact same two people that give that talk.

Ooh, awesome. You'll have to give me the link to that.

Yeah. I put a link in the show notes. If you like this format of a discussion and you want to hear it, we have really smart people that we had a discussion with them about this. So yeah, definitely check that out. It was kind of mind-blowing. Like yeah, I guess there really isn't any hard evidence other than my anecdotal, it felt like it made it better. [Laughs] And how they measure things. So, terrific, terrific talk.

I'm going to piggy back on Jamison's pick real quick. He talked about Serial. Serial is actually back for its second season. And it is really, really interesting. They're highlighting Bowe Bergdahl who is the soldier who was captured in Afghanistan. And there was all the hullabaloo about him being a deserter. And the president trading terrorists for him and all that crap. It doesn't go too much into the politics of the situation. But it does explain his experiences there, which is just really, really interesting. So, if you're interested in finding more information about that then go check that out. But really, it's mostly done from interviews and phone calls that were done with Bowe Bergdahl. So anyway, fascinating stuff. And I'm not going to pontificate on the politics of the situation. And they really don't either. So anyway, super good.

And let's see. I had another pick and I don't remember what it was. So, I will just bow out with my picks. Go check out JS Remote Conf. And thank you everyone for this awesome discussion.