So it's my pleasure to introduce Jason Langsdorf from Copter Labs.

Here we have Lisa Larson Kelly from Learn from Lisa.

Alex Saxon from Stripe and John Reszic from Kahn Academy.

We'll be talking about tools and whether there's such thing as too many or

too few and from that I'm gonna let Jason take it away.

This is gonna be an interactive discussion which means that we expect you to

participate if you want.

So I'll be roaming around with the microphone.

So, please just raise your hand proud and high if you wanna talk.

Thanks.

>> Okay, so I wanted, the point of this panel is to kind of discuss where we

are going in web development and

the steps we are taking to make sure that we are still able to bring new people,

novice web developers, up to speed with the growing number of tools.

The reason that I was thinking about this as a topic is that when, you know,

when I first started in web development.

I had to know two things, I needed to know HTML and

CSS, and technically I didn't even need to know CSS.

So as the toolset grew, you know, you get into JavaScript and

you start working in the backend and, and there's just more and

more layers of complexity that built over time.

But now we're starting to roll out things,

especially with the advent of Node where there are dozens and

dozens of tools that make our jobs easier and more efficient, things like Grunt.

Templating lan, languages like Jade, EJS, Mustache and Handlebars.

There are you know, a bunch of different things that

allow us to very quickly build out different things.

But the comple, the complexity that comes from that is that

when you wanna bring somebody new onto a project, they don't just,

they can't just come knowing HTML and CSS and JavaScript.

Now, they have to be able to function in an environment that's built with

Grunt using SAS and a bunch of SAS mix-ins with a Jade template and,

you know, all the different things that you've put in place.

So we've raised the level of complexity of our projects pretty significantly.

And this is an ongoing project but I have noticed that it does seem to be

even more rapid than it, than it was now that Coden made it so easy to do.

So what I wanted to talk to these lovely folks over here about is

just kind of coming from a place of both Alice and

John have a lot to do with jQuery and still have a lot to do with.

[LAUGH] With, John you wrote JQuery in its original form.

And so I wanted to talk to them about what is arguably the,

probably the easiest framework to learn.

JQuery has a wonderful documentation, it's,

it's part of the reason why it kinda swept the, the development world.

And then Lisa, who is doing education for

people who are getting into web development.

About how she's approaching these new tools.

So, to start I guess, John.

When, when you were first doing jQuery did you come at it from

the standpoint of like, we're going to build this from documentation up and,

and make it something that everybody can learn?

Or was it a tool for you that, that you then retrofitted the docs to?

>> I guess it was a combination of both.

I definitely.

I didn't start with docs.

I did write code.

I, I, I was, I was definitely writing tools for myself, at least initially.

But it was very important that before I ever released the code,

that there was documentation in place for people to use.

I, when I released the, the library in August, January of 2006.

With with the initial release with documentation and everything.

At the time it was the only JavaScript library that had documentation.

And in, in fact it, it was that case until January,

2007 when Prototype finally released their documentation for their library.

So the prototype was undoc, undocumented for two years before [LAUGH] it was,

[INAUDIBLE] just told people to read the source code,

the source code was very readable.

But there was certainly a gap there, and difficult to get started.

>> I think that actually brings up a really good point.

Are, are we building these tools, especially some of the more advanced ones.

Are we building them with the expectation that you, you must be this smart to play.

where, you know, the expectation is that you will have amassed the level of

expertise and knowledge about a certain, discipline of web development, that then,

then you need to know that before you can ever start working with a given tool.

Like, you know, a [UNKNOWN] runt.

Alex, do you have any thoughts on that?

>> Yeah, I'd play some music, I'm a drummer, and, same thing,

guitars and microphones, things like that.

You can buy, like a, $3000 guitar, and

I'd say that like if all guitars are three thousand dollars, no one would play them.

It would be too hard to get into the business of music.

But it remains true that when you start out, you buy the hundred

dollar first act guitar from Wal-mart and you learn from there.

And then, once you out grow it, you can move to something else.

And so, I feel like, if Grunt is too hard,

like it's fine if you wanna write a batch script that cats four files together or

whatever, or use some automated tooling system that does that stuff for

you that is even easier than Grunt, and then when you need it

to be more customized, and you've outgrown that level, you can kinda move on.

I don't think it would be helpful to the community to

dumb down all tools or, just assume lowest common denominator.

I think we can serve people on different levels.

>> Mm-hm, and so Lisa, when you're teaching these tools have,

have you run into any walls where you're just not able to get people over them?

Or like, how are you approaching the idea of, of some of the more complex stuff.

>> Yeah, I mean, I definitely agree that there are different levels that need to

be served for you know, Frameworks for example are helping people who

couldn't possibly do things that frameworks allow them to do, right?

>> Definitely. >> So it's a double edged sword.

>> Mm-hm.

>> But starting out with something that they can grasp,

something that they can actually understand and work with.

And they have all the pieces, kind of.

Or you can help them get the pieces.

>> Mm-hm.

>> And then build on it from there.

It, it is a process.

So there's, there's this huge gap but it's incremental.

>> Sure.

>> Yeah. >> So from a,

an employer's standpoint well, actually,

does anybody have any questions right now before I go off on a a diatribe?

No, okay, I'm gonna go off on a diatribe.

From a, an employer's standpoint, when you're looking at,

at building out your development team and, and equipping them with the things that

they need in order to build projects even on a medium-size team.

Do these tools that we're building make it harder to hire people or

does it make it more expensive for the company to to acquire talent that then has

to learn these extra tools and frameworks that you're using rather than somebody who

just has a very solid understanding of how, you know, the, the front end works?

>> I think any competent company wouldn't require certain tools to

hire a good developer, I mean, it's, I mean,

in the case of [UNKNOWN] academy we hire we interview and hire a number of people

and there you know, we don't like our two main programming languages are python and

JavaScript, and we don't even require that you know, either of them.

You know, if, if you're a, a good, if you can demonstrate that you're a good

developer and capable of learning we will, we'll bring you on.

And some of our best developers who are now writing amazing Python code and

JavaScript code have, were, just came in and

they didn't even know those languages when they started.

So yeah, I don't, I, I don't think that that's a, a prerequisite, that.

You know, I think it's a little bit silly,

a little bit nearsighted where if a company says oh, you must have

two years experience with Grunt and you have like all these sort of things.

Like, I'm like, yes, you can have those things but

like, there's really not much point to it.

I mean, like, that's assuming that.

You, you've been using this tool for a long time but

you're also really dumb [LAUGH] and you can't actually learn a new tool,

I don't know, it's a really weird thing, I don't know.

>> Alex, I'm actually curious so you so you're at Stripe,

and obviously if you can't share this, you know, no problem, but.

Do you guys have a stack that you work on?

Or like any sets of tools that like somebody who like joins the team needs to

like, gain mastery over before they are able to work?

Or like how do you have that set up?

>> You just wanted to know like social security numbers of like 100 people?

I can get that for you after [LAUGH].

yeah, so strikepire is in a pretty similar conacademy.

We do a fairly general interview no matter what role you're coming in for.

If you're coming in for systems you're going to do like OP-C work or

you're going to do financial things.

You more or less get the same solved set of problems, not really high CS

fundamentals either, it's more like can you solve sets of problems, and, and

actually when we do any sort of screen or interview, it's all tools that you

are comfortable with on your device on, in your environment.

So we want to see you, the, in your most comfortable state developing.

And not in our preferred environment.

And I think that works really well for, for, if someone is,

is fumbling around in their editor not remembering like,

you know, the function keyword or something like that and

they chose their editor and they chose their language, that's a pretty good tell.

But if you're forcing people to, to do something they're not comfortable with

its, you're mixing signals I think, so.

>> Sure. >> One question I

guess that I'd like to throw out to the crowd.

So Stripe and Kahn Academy are obviously some leaders in the field.

Is there anyone who has encountered either at a current or former job,

you don't have to tell us, something that was a very bizarre barrier to entry where

you had some tooling that you absolutely needed to learn or the moment you

walked in the front door you have to learn this or else you can't work on our stuff.

>> Outlook.

Look.

Lotus notes.

No one?

No one has any experience with it?

>> So here's another question for the crowd.

Is anybody is anybody using these types of frameworks?

You know, GRUNT, GULP, you know, JADE, things like that?

Just by a show of hands, how many different tools and.

So we're getting a fair number.

Now, did you have to learn those, did,

were any of you like forced to learn them as part of your job.

Or were they things that you brought to your team?

So if, did you bring them in?

[BLANK_AUDIO]

Okay.

Okay, so it looks like mostly like a, an at will sort of thing.

[BLANK_AUDIO]

No, I, I definitely, I wouldn't expect in,

people coming into the team to have those skills beforehand.

Like, I, I think that like, they're talking up there, you know,

Con Academy and, and it's stripe that, the people come to the team and we say,

okay, go take time and learn about this, like learn how to write Grunt plugins.

oh, hey, you don't know Angular and our entire app's built on Angular, but

you're a really smart person.

We'll bring you in.

The first two weeks you get to go work on videos and

learn angular, dig into the apps, and start working on some bugs.

So, I think that education on the job is extremely important.

>> Sure. >> And in practice.

>> Definitely. Now does that make it-

does that add a level of difficulty for the small business?

Maybe somebody who doesn't-

Maybe somebody who doesn't have a, a large budget, you know,

a small team that then needs to, like, put in time to train people.

>> First guy in the pool gets the book.

There you go.

>> I, I'll bite on the money thing.

I think.

That would be true if the libraries and

frameworks that we're talking about didn't provide more value in, in return.

So if you're saying hey everyone learn Python.

Let's go write this rails app.

But you have to know Python and we're not going to use that.

>> Sure.

>> I mean, maybe you'd like [UNKNOWN] it, it.

>> [LAUGH] >> But.

I think that if you're using angular or, versus nothing, probably the time

that it took someone to ramp up on Angular is immediately paid back you know,

a few weeks later by how quickly they can

build a rich internet application that works in many browsers.

So I know my company what, what we run into the most is we have,

we have our list of tools and requirements for the position,

and I think it discourages people to apply because they don't know,

and I think that that is a big problem in itself.

Because there are so many tools, if people don't know it,

they don't think they are going to get the job, but they don't know that,

you know, that training is available.

>> Mm-hm.

>> Okay. >> I think it is important to-

>> Yeah, I mean, one of the big issues here is sort of the.

It's the cult of the new where like,

everyone wants to be using the new thing and trying the new thing.

Cuz new things seem better than old things, even if they aren't necessarily.

And I mean, it, it's, it's fine.

I, I, I like I'm fully, I've fully bitten down on

that like I've used tons of new tools all the time to try and

at least keep on top of, and I guess this is another issue is that web,

web development in general moves very fast, technology changes frequently,

that you feel like you have to keep on top of the new stuff and like, like,

I've done this, I've, I've made sure that I do side projects where I'm using.

Relatively new technology, you know, MongoDB, and using WebRTC and

stuff like that, they may not be crazy awesome things but

at least I'm like trying to keep on top of it but

again the issue becomes where I was like I'm spending all these cycles trying to

keep on top of this thing that's going to be coming down the pipeline.

And-

>> Or Not >> Or not, right, right, you know, like,

i guess, that, [INAUDIBLE] is saying, if I'm working on RTC's stuff and

I'm like putting all this effort into it, but Apple decides they're

never going to [INAUDIBLE] RTC, then like, was that like all for not, like, you know,

like, you know, you know, I don't know, it's.

I, I, I, I definitely think that there's a large hype factor around,

around this, around the tools.

And in it's, it's important for us as developers to

be good at differentiating between when something is hype and

when something is legitimately useful to your everyday practice.

And I think this is probably just something that's probably more something

that's a skill that you hone over time, that as you get burned by more and

more tools, [LAUGH] that you eventually are like, okay, I'll wait a little bit and

I am fully at that, I am like one of the slowest adopters of new tools.

Because I just, I, I don't want to get burned, I don't want to sink months and

months into learning something that's not gonna matter.

>> Have you been burned before?

Oh, sorry Lisa.

>> Well, we were talking earlier and

you had said that that's one way that you kind of vet new people, right?

Is to see if they can differentiate that, you know, like, have them review, compare.

[CROSSTALK].

>> Yeah, yeah, so, so.

Yeah, yeah, yeah, so, so like we have a,

can I be I want a project based interview for new applicants and

I give them a project that they take home and they, they code on their own terms.

And one of the things I ask them to do is look at two different tools which do

essentially the same exact thing.

It's two JavaScript frameworks.

And I want them to write up why they picked the framework that they did.

And so it, it's, it's, it's I feel it's a very basic skill that isn't

a programming skill per se, but it's a skill that all developers should have.

Because being able to differentiate between a library that is actively

developed versus not actively developed is documented versus not documented

that there are bugs being posted and being fixed.

Like all these sort of things that like,

are indicators of a healthy project that will probably continue to exist.

You know, one to hopefully five years in the future.

You know, and I think it's something that people need to be more aware of.

And again if you have these hot new products that are coming out and

then like, everyone's like aw man have you checked out this new whiz-bang library?

and then, but then you realize like, and then you look at them like, hey, wait.

That no one is actually fixing bugs in this, the developer left like 3 months ago

and like, you know, and like, maybe I shouldn't jump in this right now?

Maybe I'll just wait a little bit,

I'll wait 3 more months, and if someone wants to take an older project, great,

I'll jump in then, but in the meantime, I should wait.

>> You shouldn't talk about TJ like that.

I really like John talking about how you have to be able to tell hype from now,

because some of my favorite.

If you've ever been to compilating JavaScript the old news group.

There's some really, really mean people there that,

that used to really rail on John and jQuery in the very early days.

And just, they would call him John Ressick, master of hype.

And like.

>> [LAUGH] >> He's just a one man marketing machine

for jQuery and he's trying to push these terrible libraries on us superior DOM.

developers.

>> [LAUGH]

>> So it's good that you've finally learned that skill.

>> [LAUGH].

>> Anybody have any questions for the panel?

[BLANK_AUDIO]

>> One of the problems or opportunities we have in our,

in our small company is we have people who are not developers at all, but

are actually really interested in starting.

And a few years ago I, I think I know what I would've said or

suggested in terms of maybe starting either client side or, or server side, but

with the success of JavaScript on the server and this sort of rising importance

of JavaScript well, everywhere I find it difficult or more difficult to suggest.

Where to begin in what path to, to follow sort of

like they're these eager padawans and they want to become Jedis.

But what, what do you, what do you do with people who know nothing?

Or, or, you know, but are really eager to learn.

I've suggested actually Khan Academy, thank you.

And John, that's good.

But beyond that, what, what do you suggest?

What do you, what do you tell them?

>> Well, first off, they've started with the right attitude.

I think that's huge to not feel like you're starting out and

that you feel stupid.

And, why don't i know this already?

To have that eagerness and

excitement about it, is like you can't go any further without that to start with.

And then doing something like KHAN academy,

that gives you the basics, what's a variable?

What's a loop?

You know, all those things, and then project based, Having a mentor.

Kind of help you and to have something in mind that you want to build,

because there are so many tools and so many pieces that go together and

then just start to build from the ground up and learn like, you know,

when I started with Web RTC, I didn't, you know, what's an NPM, you know?

So I had to start somewhere and start building out of that,

I knew what I wanted to do, so I started.

Building on those technologies, and when you have that basic knowledge you know,

it makes it a little bit easier.

But it's very intimidating to just look at this full stack and,

you know, without something, a goal in mind.

>> Mm. >> Just enroll them in

a four year university and.

>> [LAUGH] >> [LAUGH]

>> At Stripe we have a lot of people who,

who are interested.

At, rather in sales or risk people or something like that and

we will run classes taught by developers, developers love teaching other people for

the most part, so use your internal resources.

Stay an hour late and you can do really fun projects.

I think the one I did last year, I'm remote so

I rarely get to do them, but the one I did while I was there was.

We wrote an animated gif capture.

And then we put a function block that was pre-made that already gave

you some variables for pixels.

And then you could just change the pixel color values and

essentially write filters over animated gifs.

But you, you're essentially working in this tiny little section and

then at the end of the day.

Everyone learns about loops and variables and how to change numbers and multiply and

do all that kinda stuff and then, then they show off their animated gifs and

it's fun and, so you can have little pro, I mean, that's very specific, I'm sorry.

[LAUGH] But you can have little contests and projects.

I also run contests among all of our interns.

Every kind of path to say, like who can wrote the best parser because none of

them have wrote a parser before and I need all of them to know how.

For no reason. [LAUGH] I feel like,

I feel like it is an important skill.

I think about like a sign, an XKCD print and I was like.

That the co, my code is compiling one, or whatever.

And I said whoever writes the fastest parser for

this made up I think I called it Emota Bars, template language.

That they win this.

And they all compete and benchmark all their stuff and

there's tests, they'll share test case.

So that you'd learn a lot.

So I, yeah. Projects are really good.

>> Yeah. >> And, and working

together with other people.

>> Yeah. >> And a little bit of competition,

you know, it's.

Makes it interesting.

Yeah. >> Mm-hm.

>> You have to keep them engaged though.

It's really easy to like, stop as soon it's done.

>> Mm-hm. >> Yeah, and I think,

one of the big important parts about having a mentor in place is the fact that

you could help them make sure they don't bite off more than they can chew.

Because, you know, the initiative they'll be like and we have all these things and

there'll be stuff flying around and then like, you're like, okay,

well, let's narrow the scope a little bit.

Like, like what's the bare minimum you need to like actually have

this be a thing.

And then, and then,

so just keep, you don't wanna be a downer, but you kinda have to be a downer.

You're like, dude, like, okay, let's just think a little bit smaller and

think a little bit smaller until they're just getting at the very core what

they wanna do.

And then you can slowly introduce new technologies and work them, back up again.

>> Start with vertically centering text in CSS.

[LAUGH] >> Oh, we do have the mic over here.

>> Hi so I feel quite the opposite sometimes.

I feel like sometimes we've made it too easy to learn web development.

And by that I mean that a lot of the JavaScript libraries and frameworks out

there more and more reduced to last lines of code really complex behavior.

And I get concerned about that because.

I feel less secure about my job.

[LAUGH] You know, if that makes sense.

>> Well, I mean, it's, it's,

I would say it's the sort of the rails mentality like when rails came out,

before that point there weren't that many NBC server-side frameworks.

Works.

And then, essentially, they introduced, like, when,

when they first launched there was like that, that video that released,

like making a blog in like a minute or two and they just had like the command line.

Just like, it just generated it.

They tweaked some variables and they like poof there's a blog.

And, like, up until that point if you wanted to write a blog it was like,

it was an evolved thing and essentially just made like a blog generator.

Generator.

This is a multi, anyway.

But the. It was, so like, and

like people flipped out.

Like, like. [LAUGH]

When people were like really upset.

They were scared and

upset and they were like there's too much magic happening in here.

And I think that some people would still agree.

That there may be still too much magic in a lot of frameworks.

and, and I mean.

And you certainly do see.

I think you, I feel like you see the same trend here.

On the client side.

Like, you know, you know, frameworks that are capable of doing lots of really,

really complex things, perhaps too easily.

but, but, I think one of the things here, an,

and I guess the, the, the, to change your point a little bit, one of the things

that always scares me about those frameworks isn't necessarily job security.

It's more the fact that if it doesn't work, if it breaks at some point,

I have no idea how to fix it.

Like, like if I, if I have this one thing that is like, dot make awesome and

then this only, everything is awesome, but like, there is like this one little thing

that I needed to change at some point later how do I do that if I,

if I have no idea how it works?

You know, I think that's one problem, and

I think that's a, that's a way in which you shouldn't be worried about your

job security because if you know, how it works, if you know,

how to build the equivalent thing, then you won't have to ever worry,

you aren't really competing with a person with someone who drops in an [INAUDIBLE].

You know.

>> I hear you, I was mostly joking there.

[LAUGH] but, to follow up on that are we in a larger scale doing a disservice

to a newer generation of developers by sort of abstracting out all of this.

You know, the meat and

potatoes of what's really happening there, into more simplified terms.

I don't know if Lisa or Alex have any thoughts on that.

>> Let's see.

[LAUGH] To some extent, yes.

If they skip over the basics and they're just using that API and

building stuff and they never, and things break and they just throw their hands up.

Sure, that's disempowering for sure.

But at some point they're gonna have to dig in and, or

they're not gonna be successful.

They're just not gonna be developers.

You know, so- >> So, yeah.

So, so continuing on that question.

How do we as developers ensure that we, that we don't build so

many tools that the internet doesn't exist for our children?

>> I, so I [LAUGH]

you, you asked why is America the greatest country in there?

[LAUGH].

>> I, I think that's the wrong premise so I, I, reject the question.

>> [LAUGH] >> I guess both questions.

>> [LAUGH] But I, I feel like it, I understand where you're coming from,

but that was the same thing someone said about their flash, and

that was the same thing someone said.

About C++ or Java, swing, applications,

and before that people who did guis, then something else and something else.

I think it's fine that if we build something that we like more,

like, how many people are, are,

like digging into the chromium code that actually renders the.

The paint, the paints and renders and all that kind of stuff,

because that's what you used to have to do and now you don't have to do that and so,

those abstractions have been fine and I think as long as we continue to

build good abstractions, the good ones will end up in W3C specs.

You have all sorts of stuff that we.

We did a jQuery or that are happening now that are moving into native APIs and

you have the, the scary native mobile applications also innovating and

we're, we're playing catch up on a lot of those APIs too.

So I think it will constantly change in holding on to the past where.

You had to know how to script down libraries by hand, and

notepad.exe, doesn't need to exist in the future,

even though we have fond memories from those days, right?

>> Not, inherently put.

>> I think one of the things as well is that you,

I feel like you should be willing to, genuinely want to look for.

When you're looking at new technologies, I would say it's pry better to go for

ones that are revolutionary as opposed to incrementally better.

like, like for example, if,

if there's, if there are frameworks that are simply taking existing ideas that, but

are just making them slightly easier to do I don't

think those are nearly as good as ones that are completely rethinking how we.

I think about concepts in, in, in, in, in total.

So, like-

>> A sick low dash burn.

[LAUGH] >> I like low dash.

[LAUGH] But the, like the, the, the, you know, like, for example,

like lately I've been playing, and I, I guess this extremely cult of the new,

I've been playing with the Facebook's Reacts JavaScript library.

And that can not be possibly be any more different from the existing way of

writing applications.

It's extremely different and it's breaking my brain.

But like, I've, I've been, I've been enjoying that that process, and

I feel like it's helped me, it's starting to help me to think about

architecting JavaScript applications that are better in a different way.

Even though I don't necessarily end up writing it for, using it for all of my.

Code in the end.

>> Okay, so we have time for one more question, does anybody have a question?

>> [INAUDIBLE].

>> [INAUDIBLE] >> Is everyone, did everyone hear that?

The yeah, so the, the statement was that there, there will always be

view source and so we'll always be able to look at the, the HTML and JavaScript.

Which I, I agree with in principle but

when you get into things like, like Angular or, you know,

minified JavaScript, it gets a little more difficult to view source.

But I, I think you're right in principle.

>> Well, especially cause like,

[INAUDIBLE] where you're [COUGH] literally compiling C to JavaScript.

Like that's not readable by anyone.

Literally only a computer.

So like I don't know.

It's-

and it's interesting because this is a case where actually

Richard Stallman, the free software foundation-

I feel that any sentence that begins with that is going to be interesting.

But like the like-

He considers any sort of minification of JavaScript

to be essentially compiled code that is no longer free.

So that includes any sort of,

you know, using like uglify or a closure compiler or any of those things.

And I, and I can kind of see what he's getting at because in those cases.

You no longer have a nicely readable block of JavaScript code.

That like, like,

I learned from the prototype JavaScript library back when it came out.

I was reading it, I'm like, this is amazing.

There are all these sort of functional programming techniques in here I'd never

seen before and it was so clear and so well-written.

But whereas, like, you know,

doing these like really complex compilation steps you now have.

A 200 K minified JavaScript log is coming down to you and you like that,

as even though you can technically read the source you can't read it.

Like, there's nothing there that you can learn.

So I'd say that the situation as it exists right now even though we

can technically still have, we still have that right of the view source.

It is not nearly as, as effective as it was I would say a decade ago.

>> So with that being said does anybody have

any burning thoughts before we shut down?

>> Source maps can, can help with that.

But it's nice you can still shift minified code in and,

and people could still read the source but, that's just.

>> That assumes you want people to.

>> Correct. >> Yeah, right.

Well, thanks everybody.

Thanks to the panelists for sitting with us.

[APPLAUSE]