Interview with Paul Irish

[Nick Pettit]: Paul, Thanks so much for being here.

[Nick Pettit]: Paul, Thanks so much for being here.

I really appreciate you coming out. >>[Paul Irish]: No problem.

[Nick Pettit]: So, for people who don't know who you are,

how would you describe yourself?

Who are you, and what do you do?

[Paul Irish]: I am a developer advocate

on the Chrome team right now,

and so I kind of focus on--that encompasses a lot,

but I focus on everything I can do

to make it better to create compelling content for the web.

We've got a lot of great content inside of Chrome.

I wanted to help educate people about that,

help people understand how to use things like

the Chrome DevTools better.

I also come with a big history of front-end development

and open-source projects that I work on

to help developers

learn what they need to know

to do better front-end development,

make better websites and web apps.

[Nick Pettit]: That's awesome.

You're involved in a million different projects.

You're doing Modernizr, HTML5 Boilerplate,

which I use all the time by the way.

You've been on the jQuery team,

and you've made all these really handy tools for

front-end devs.

This might seem obvious, but

what's the motivation for working on all these different things?

[Paul Irish]: I think part of it

is basically that I feel a lot of satisfaction

helping other people, and so part of it is just that.

Also, the other thing--I think this is actually another part that's happened--

is that I have a really bad memory,

and what that translates into is

if I don't write something down, I'll forget it.

So, this happened in front-end development where you learn this technique

of using media queries or the viewport meta,

and you need to keep track of this

because this is the right way to do it

in this situation.

So, that eventually translated into what became

the HTML5 Boilerplate project,

where a lot of best practices were distributed

all over on blogs and books and things like that,

and I was just like we need to get this together

just to keep track of it;

so I can keep track of it and remember to use it on the next project.

So, that's helped me a lot and has helped other people.

The other thing for me that really drives me

is that I want the web to be

where people build great things.

I'm just really excited about anything that I can do

to help make the web be a stronger platform

for making great, really cool stuff.

[Nick Pettit]: So, you're very diligent

in tracking all of these different things?

[Paul Irish]: Because I can.

[Nick Pettit]: How do you balance your time working on all those different projects?

[Paul Irish]: I don't have a good mechanism

for time management right now.

I use a really cool tool called, 'WorkFlowy,'

which is like a super-enhanced

to-do method list app. It's really cool.

I set up priorities for myself

on a quarterly basis

and try and get them.

I think that's actually quite important,

which is to have a longer-term view of what you want

to attack, because it's so easy on a daily basis

to be totally distracted and

just be like, "I want to play with this new thing

and get it done. Oh, wow, something,"

and then you totally forget that you have this much larger,

higher-impact thing that you should be doing.

So, it's hard, and I'm still really bad at time management,

but I'm working on it.

[Nick Pettit]: I know what you mean.

With being involved with so many different projects,

I guess you kind of have to keep a big-picture view

as to what all those things are working towards.

[Paul Irish]: Yep, and what the priorities are. Yeah.

[Nick Pettit]: Cool. So, before we continue, I want to back way up

and just get some of your history.

Where did you grow up and what were you into?

[Paul Irish]: Sure. I'm from Western Massachusetts and Connecticut.

So, I'm from New England where we say,

'wicked,' 'It's wicked cool.'

[Nick Pettit]: Wicked.

[Paul Irish]: I was into music.

I was in the marching band; I played the tuba.

I was into drama. So, I was a band and drama kid in high school.

I was really into music and, in fact,

the first time that I really got going online was

I created a music blog.

This was in--I put it out in 2004,

and I thought I was so late to the music blog scene,

but it turned out that I was one of the first 50 or so.

Having that environment where I had a website that had a lot of traffic,

and I could play with the design and experiment

and get a lot of feedback

on how people liked it,

that was one of the first times when I was really like,

This front-end development thing is a lot of fun.

[Nick Pettit]: That's when you first became interested in the web and technology?

[Paul Irish]: That was when I was like,

this could definitely be full time.

I'd been playing with websites.

Back when IE4 came out

they did this really cool marketing campaign.

This was when the DHTML term arrived,

and so they had this marketing campaign

where they rented out all these movie theaters across the U.S.

and invited a bunch of developers,

and I went and I got free popcorn and a free t-shirt

and a free Windows 95 install CD,

and they showed about what you could do in IE4,

and it was amazing.

So many great features came out then,

and so that was when I was like,

this interest of mine, there's cool stuff in here.

Eventually, it quieted down.

I went to college, but after that everything picked back up again.

[Nick Pettit]: So, did you go to school for this stuff?

[Paul Irish]: I went to school for--

I got a degree in technical communications.

I don't actually know--

I really do wish that there was more university-level coverage

for web development.

Front-end development is hard, and it's a pain,

and I wish that there was a more sophisticated education

program for this.

I got education in computer science and mathematics,

and management and communication.

[Nick Pettit]: With us being an education company,

I'm interested to know if

you feel like your degree really helped you

in your career, or--?

[Paul Irish]: Mine did,

and I think these days having a computer science background

has a very direct effect.

I wouldn't say 5 years ago that computer science would help in web development,

but nowadays, especially on the client side,

there's so much logic there.

You're writing jQuery, things are going good,

you're translating, you're writing larger applications.

[Nick Pettit]: It's getting complicated. >>[Paul Irish]: It's getting real complicated.

A background in computer science lays a lot of the groundwork

so that you're not making stupid mistakes

and taking 4 months to learn how you should have done things.

So, yeah, computer science has a big influence

on where the trajectory

of front-end development is going for sure.

[Nick Pettit]: Cool. Well, I think a big challenge

that's facing people coming out of college today

is how to make the transition to

a career and not just kind of hopping from job to job

or being unemployed.

How did you make that transition?

Were you just kind of in an internship,

and it was a really natural progression

or did you--?

[Paul Irish]: Yeah. I started out I was doing

some marketing for

a stationary company

that made wedding invitations and birth announcements,

and I wasn't even starting out with web stuff.

I was creating

a mail-merge Word document,

and then we were using that to fax blast all of our customers,

and I was customizing the mail merge to be

depending on the customer, and it was all this logic inside Word.

It was awesome.

That transitioned, within that job,

into working on their e-commerce presence,

and so that was good.

I think for most people

having something you can develop on your own--

In my case I had my music blog,

but I think having your own web presence,

whether it's a blog; I think blogging is really good.

Blogging what you're learning is extremely smart

and having that place where you can iterate and play around.

So, when you see a new feature come out,

like you're reading a site and they talk about some new CSS3 feature

or something, make a demo with it.

Kind of explore it.

Put it up on CodePen.

There's a lot of communities now that are encouraging

and let you explore things, get feedback.

Having a social community

that you can talk to and explore

your own professional development with.

I had one, and it's just been very--

It's a very smart way to go about things.

[Nick Pettit]: So what first attracted you to

front-end development, specifically?

Because you were making a blog, did you do that in WordPress or something?

[Paul Irish]: Yeah, it was WordPress. >>[Nick Pettit]: Okay.

Why aren't you, say,

like a Ruby or a PHP developer, for example?

[Paul Irish]: For me, the thing that really rocks about front end

is that you're building the interface,

and not only are you building the interface,

and you can make decisions around

how the interactions are,

but you're also getting feedback from its users

and from the customers.

The thing that they're touching, their cursor is going over

what you've created, and you're in a position

to where you can define the style of interaction

and the quality of the user experience.

Other people can work on how fast it responds

and a really strong infrastructure,

but the UI is just very sexy to me.

[Nick Pettit]: So it's kind of about that instant gratification then?

[Paul Irish]: The instant gratification and the feedback cycle of

I'm creating the interface, they're using it,

they can love it, they can be delighted by it.

Or they can hate it when I apply

a lot of text shadow to it and make it hard to read or something.

[Nick Pettit]: Sure, sure.

So, I want to talk about HTML5 Boilerplate for a little bit,

because I'm personally interested in it.

I think it's a really amazing project

for people that are just starting out

in web design and web development,

and I think there's a lot more that goes into it

than people might realize. >>[Paul Irish]: Yeah.

[Nick Pettit]: So, first, how did that project start?

[Paul Irish]: Before working for Google,

I was at an agency in Boston making websites, web apps.

We had a big team of front-end developers there,

and when I was going from project to project,

I was noticing that I was pulling lines of code

from my markup and from my CSS

from my last one into my new one,

and then I was like, well, I should probably make a template

just to keep track of this, and so I could start off with that template each time.

That's the original genesis, was just

that I needed to keep track of all this stuff

and move it forward from project to project.

Soon after, I got Divya Manian involved.

We put out a 1.0 just to see what everyone else thought.

Immediately it was really great

because inside HTML5 Boilerplate

is a bunch of techniques, right?

One of the things that has continued up until a little bit ago

is having inline documentation.

You see a technique, and you can instantly see

the website where that was birthed,

and someone can justify exactly why this is important.

So, it's kind of serving as an education tool.

You've kind of got to understand why everything is in here.

So, what happened is we put this out there,

and immediately we got a lot of feedback

over on GitHub where we open-sourced.

A lot of people coming in and being like,

Actually, I see what you're doing here,

but if you tweak it, this is a much stronger position.

It accounts for this edge-case bug in Opera 9.6 or something like that.

Every character inside HTML5 Boilerplate

has had a lot of discussion around it,

and so everything that you see is the result

of extensive conversations that have included

some of the best front-end developers in the industry.

You can go and look back at all those past conversations

in the old issues on GitHub.

The commits in the project,

the log messages have very desciptive

explanations of why we're doing this.

It's very well-justified in why all these decisions

are very strong as a baseline for starting your web project.

[Nick Pettit]: Cool. I think when beginning developers

look at HTML5 Boilerplate for the first time-- >>[Paul Irish]: We've got a lot.

[Nick Pettit]: --they're just like, "Wow."

"What's all this weird code?"

Let's talk about that a little bit.

From the top, what are all those IE conditional comments,

because that's the first thing people see?

[Paul Irish]: Yeah, so the IE conditional comments,

they don't look great.

They look kind of nasty.

It's like sometimes you want your mark-up to look

svelt and sexy and minimal,

and I love doing that as well.

Inevitably when you're developing--

So, this is not a problem for IE6 and IE7,

which have no market share anymore.

IE8's definitely still around,

but it's been a case where

they have actual CSS bugs in their implementation,

and you can use CSS hacks,

like syntax hacks, to target them and change the width or something,

and change the padding

to make your layout work and to fix those bugs.

But using undocumented CSS hacks,

it doesn't allow you to communicate well with your team,

and when you're working in a group

you want everyone to read the code and understand.

So, the conditional comments

provide a first-class way,

that was provided by IE luckily,

to specifically target these browsers

with CSS styles that affect just IE7 and just IE8,

or a combination thereof.

It's tricky because that's provided for you for free

in the Boilerplate,

but I do think that you do want

to try as hard as you can to avoid vendor-specific styles.

A lot of times just setting explicit dimensions,

width and height, on an element will let you avoid

doing that, and so you should try and go as long as you can

without specifying specific browsers.

But it is there when you need it, and it helps a lot.

[Nick Pettit]: There's plenty more in Boilerplate

that we could talk about.

There's--I've heard you talk about

all the weirdness with carsets. >>[Paul Irish]: Yes.

[Nick Pettit]: There's Chrome Frame, Modernizr, setting the viewport, and so on.

What's your favorite feature,

and what do you think is the most interesting thing that's there?

[Paul Irish]: I found this on Ajaxian a long time ago,

and now on Stack Overflow there's a great question called,

'The Hidden Features of HTML.'

I submitted it a long time ago, and it's the highest voted, and it's in HTML Boilerplate,

and this is the protocol-relative URLs.

So, down at the bottom when we include jQuery,

we pull it in from the Google CDN,

but the script source is equal to

// stuff stuff,

and you're like, "I think you're--"

We get pull requests and bug reports on a monthly basis.

Like, "You got a typo, you missed the http:."

And we're like, "Actually, we didn't."

So, the protocol-relevant URL

provides an ability to--

the browser will grab the HTTP version

when the page is in HTTP

and HTTPS when you're hosted in SSL.

This is cool because it guarantees

that the assets are requested securely

only when it's required.

There is a small overhead in requesting a secure asset

when you're in regular HTTP.

So, this is really cool

and helps, although it is a little tricky on Windows

when you're just developing, when you've loaded it up

from the file system and then in your browser it says, "file:,"

it can be really slow.

If you use a local development server

however, you don't have that problem.

So, I think the feature is really awesome,

and that's probably one of my more favorite things.

[Nick Pettit]: It's crazy you brought that up

because I was just looking at that the other day

trying to figure out what happened here.

It's kind of amazing to me just how much

goes into a, supposedly, vanilla webpage.

I mean, it's called 'Boilerplate,' right?

So, it seems like it should only be the most basic things that you need,

but there's a lot there.

Do you think the job of a front-end developer has become

a lot more complicated in recent years?

And is that a good or a bad thing?

[Paul Irish]: Well, there's 2 things happening at the same time.

One of which is that age-old legacy browsers

are on the decline. IE6 is dead.

If you look at market share numbers, IE6 is dead.

IE7 has under--actually just about 1%.

IE is really strong but still

that's improving.

A lot of front-end developers' pain has been

the old browsers that haven't kept up

with not only fixes, but features that we want to use.

So, that part is getting easier.

By the same point, the last 3 years

have brought an enormous amount of features

to browsers that we now get to incorporate

and figure out the best way to incorporate.

So, for instance, if you're using a CSS transition,

do you use that CSS transition

and just let it fall back

if it's not supported by the browser?

I recommend you do.

But you could choose to feature detect it with Modernizr

and then use jQuery to animate

the same general transition.

So, figuring out your fallback scenario

is a little tough.

A little bit ago, a few of us put out a site called,

'HTML5 Please,' which aims to provide

a bit more guidance for all this stuff.

So, basically, you get to look up

for every feature, all the new stuff,

you get to look up exactly

what is probably the best way to handle this

for a cross-browser scenario,

where you might not have support everywhere.

Should you use a polyfill script to enable that feature in an old browser

or should you just let it fall back

or is there some in-between state that is probably the best way?

Finding that is tricky, but I think there's more and more resources out there that help.

[Nick Pettit]: It seems like this is something

that's unique to the nature of web development

where you have to come up with these fallbacks

for all of these different browsers coming out.

Do you think it'll always be that way,

or do you think we'll hit some point

where things are pretty stable,

and web development is just kind of a little bit more static?

[Paul Irish]: Well, so if we got there,

if we got to that point, that would essentially indicate

that there's not any

groundbreaking new features being added.

I kind of don't want to be there. Right?

At the same time, I don't like

having to send a bunch of polyfills

at older browsers

and just testing and worrying about that.

So,yeah, that's getting really complicated and messy,

and managing the various states,

like if you think about the old state of

all browsers must look--the experience must look the same in all browsers

to the new one which is we feature detect, we find out what we can provide,

and there's a lot of combinations of how your site looks.

Then you're like bringing responsive design, and it's changing.

So, from a capability and future perspective, it's different

from a viewport size; it's a different experience,

and when you've built a site,

and you're testing it to make sure that everything is right,

there's a lot of combinations to look through.

Here, the most important things are

choosing features to use where the fallback scenario

is you kind of forget about it.

If a browser doesn't have border radius CSS transitions,

that's probably okay.

A lot of these just kind of enhance.

The other part is

that I think we could actually, as a community,

do better to help encourage our users

to be using browsers that we specifically want

to support, and that helps our job,

and it helps them.

I know conversion rates improve significantly

when the experience is faster.

Helping your users be on the kind of browsers

that you yourself enjoy

actually has a good business support,

and is a lot more fun for users and developers, of course.

[Nick Pettit]: There's so many steps

that are involved in front-end development at this point.

This is something you were blogging about recently

where you said the tool chain is a little bit overwhelming.

There are so many steps and there are so many different

tools and techniques to deal with each one of them.

Do you think there's a need to simplify that

and try to bundle all of that together?

What are your thoughts on that?

Because I feel like the barrier to entry

is really high for somebody that's new to it.

[Paul Irish]: Yeah, so, it's tricky.

There's a lot going on,

and, yeah, it's a lot to absorb.

I've recently been working

with Addy Osmani

and some other people inside the web development community

to put out a project called, 'Yeoman,'

and this project is about putting together a lot of tools

that help you build better web apps.

Now, there's a lot going on in there,

but it's using things like CSS pre-processors,

live reload,

even shipping a plug-in for Sublime text.

So, there is like a baseline of features

that most front-end developers use,

and I don't think this is really listed anywhere.

Maybe I should make a blog post out of this,

but there's a few things that these days are pretty well accepted

as these are fundamental to development.

People don't talk enough to their colleagues, coworkers

about what is their process for developing.

How are they interacting

with their text editor, their source control?

I think there could be a bit more of a conversation

around what we can do to make sure that

when we're coming back to work on our projects

it's not frustrating and instead it's fun,

and I'm getting work done quickly.

Every time I watch someone else do their work

and I sit next to them and I'm like, "Whoa, whoa, whoa,"

"What did you just do? What was that keyboard shortcut?"

[Nick Pettit]: Right.

{Paul Irish]: I think we should do a lot more of that.

[Nick Pettit]: Do you think it's okay for people to just use the stuff

and maybe not totally understand it but just know that,

"I need to do this thing for it to work?"

At what point does it just become an abstraction?

[Paul Irish]: I think it's--that's a great question.

So, right now--

Nicolas Gallagher is the new project lead

on HTML5 Boilerplate.

He's kind of taken over, and he's doing a fantastic job.

So, his perspective is that

the Boilerplate project is aimed specifically

as a baseline--this is a baseline for web apps,

and it can be used for web apps and websites,

and there's not really much to take away,

and there's probably not much to add.

In fact, it's a very stable project

at this point because it's not trying to solve

other problems.

Now, let's say in jQuery, for instance,

this has been a longtime question

which is, "Should I learn JavaScript at the same time as I learn jQuery?"

"Should I learn it first?"

My answer to that has always been

you learn them at the same time,

especially things like math and strings and array methods.

You want to learn those JavaScript methods fairly quickly,

because there are not good answers for them in jQuery.

At the same time, you don't want to have to learn

how a lot of the intricacies of the DOM work

very early on.

So, I think it's a matter of

learning the techniques as you're using the tools.

So, in HTML5 Boilerplate,

you kind of dig into some of the documentation,

and at some point you'll just be like,

"Why?" And you should be asking that question.

That shouldn't preclude you from using the tool.

At the end of the day, you want to enjoy what you're doing,

and you want to do it fairly quickly,

and you don't want to be frustrated.

So, you use the tools that are available.

I think it's important to understand how they work,

and right now I'm trying to get a better understanding

how browsers work, and those are really complicated.

But I'm not going to tell everyone that every web developer

needs to understand how all of the web browsers work.

I think we're okay with that kind of working as a tool.

It's a balance.

Understanding the internals of any tool

will help you be much stronger at using it,

but you don't need to understand it

to use it.

[Nick Pettit]: So, wrapping up, what advice would you give

to web designers and developers out there,

just as a very general question?

[Paul Irish]: Sure.

[Nick Pettit]: What can they do to better themselves?

[Paul Irish]: One of the things that happened to me

a while ago was,

I had joined the jQuery IRC channel.

So, IRC is kind of, it seems nerdy.

Yeah. Nick's like, "Yeah, definitely nerdy."

But I joined that a long time ago,

and I was just super active in it, and that's how I got involved

in jQuery projects, started doing developer relations for jQuery,

joined the jQuery team, was involved in the project for a long time,

and it was all because I joined the IRC channel

and just started talking to people and helping people.

So, helping other people with

front-end development

you learn a lot, and I would recommend that.

The same time that that happened,

I found a group of people that were

doing a bunch of jQuery, doing a bunch of JavaScript,

and we just formed this kind of social group

of 20 of us.

It was also on IRC, and we would just talk all the time

about what we were doing,

and this led to--there was a little bit of competitiveness,

but a lot of cooperation.

We would work on projects together,

things like

and HTML5 Please, have come out of this group.

So, having--

So you're not alone without a mentor.

It's great to have a social group

where you don't feel like completely inferior to everyone around you

and can kind of support each other.

The last part of this is really just to

be able to have fun while you're learning.

I think part of that is

creating little demos and experiments for yourself.

Doing that will give you more experience with cool features

and things that you want to explore

and help you feel more confident when you

propose to your boss, "Really we should do it this way,"

"Why? Why?"

And you'll be like, "Well, I've actually done some work with this,

and it's not as bad or as scary as you think,

and, I don't know, it'll all work out."

[Nick Pettit]: That's the advice that I always give to people

is just, "Do cool stuff and share it with other people."

[Paul Irish]: Yeah, absolutely.

[Nick Pettit]: Awesome. Well, thanks so much for being here. I really appreciate it.

[Paul Irish]: Cool, thanks.

[Treehouse FRIENDS]

[♪music playing♪]


Expressions / Collocations