Treehouse Friends: Paul Irish

paulIrish

Treehouse Friends is a series of interviews with interesting people in the web design and dev fields and other industry experts.

Paul Irish is a web developer and a member of the Google Chrome Developer Relations team. He’s been a part of many noteworthy projects including jQuery, HTML5 Boilerplate, HTML5 Please, and more.

In this interview, Nick Pettit talks to Paul about the increasing complexity of front-end development, career paths, HTML5 Boilerplate, and several other topics.

Links mentioned in this video:

HTML5 Boilerplate
http://html5boilerplate.com/

HTML5 Please
http://html5please.com/

Yeoman
http://yeoman.io/

Want more Treehouse Friends?

Treehouse Friends is a great way to get behind the scenes and into the minds of some of the web’s most talented people. It is part of the Treehouse membership and just one of the many bonuses available to Treehouse Members. It’s okay if you’ve missed the first few because we’ve archived them, but you won’t want to miss the interviews coming up! Sign up today!

Interviews currently available to Treehouse members:
http://teamtreehouse.com/library/treehouse-friends
Chris Coyier
C.C. Chapman
Paul Irish
Chamath Palihapitiya

Interviews that are coming up (in no particular order):
Kevin Hale
Jessica Hische
Tyson Rosage
Josh Elman
Chris Hutchins
Jeff LaMarche
Dave Wiskus
Jonathan Ozeran

Video Transcription

Nick: Paul, thanks so much for being here. I really appreciate you coming
out. For people that don’t know who you are, how would you describe
yourself? Who are you and what do you do?

Paul: I am a developer advocate on the Chrome team right now. That
encompasses a lot, but I focus on everything that I can do to make it
better to create compelling content for the web. We have a lot of great
features inside Chrome. I want to help educate people about that, help
people understand how to use things like the Chrome dev tools better. But I
also come with a big history of front-end development and open source
projects that I work on to help developers kind of learn what they need to
know to do better front-end development, make better websites, web apps.

Nick: 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 of these different things?

Paul: I think part of it is, basically, that I feel a lot of satisfaction
helping other people, so a 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 happens 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 for the
situation. So that essentially translates into what became the HTML5
Boilerplate project where a lot of best practices 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 that on the next project.” That’s helped me a lot and has
helped other people.

But then the other thing for me that really just drives me is that I want
the web to be where people build great things, and I’m just really excited
about anything that I can do to help make the web be a stronger platform
for just making great, really cool stuff.

Nick: So you’re very diligent in tracking all of these different things.

Paul: Because I can.

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

Paul: 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
nested list app. It’s really cool but I set up priorities for myself kind
of 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 just totally distracted and
just want to play with this new thing and get it done and, oh, wow,
something, and then you totally forget that this much larger, higher impact
thing that you should be doing. It’s hard and I’m still really bad at time
management but I’m working on it.

Nick: No, I know what you mean. 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: Yeah, and what the priorities are, yeah.

Nick: 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: Sure. I’m from western Massachusetts and Connecticut. So I’m from New
England where we say “wicked”, it’s wicked cool.

Nick: Wicked.

Paul: 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. 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 like 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 just like, “This front-end development thing is a lot of fun.”

Nick: So that’s kind of when you first became interested in the web and
technology?

Paul: That was when I was like, this could definitely be full-time. I had
been playing with websites and back when IE4 came out, they did this really
cool marketing campaign. This is when the DHTML term arrived, so they had
this marketing campaign where they rented out all the movie theaters across
the U. S. and invited a bunch of developers. I went and I got free popcorn
and a free t-shirt and a free Windows 95 install CD. They showed about what
you could do in IE4 and it was amazing. So many great features came out
then. That’s when I was like, “This interest of mine is like, there’s cool
stuff in here.” Eventually, it quieted down. I went to college but after
that, everything picked back up again.

Nick: So did you go to school for this stuff?

Paul: I got a degree in technical communications. 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 just got education in computer
science and mathematics and management and communication.

Nick: Well, us being an education company, I’m interested to know if you
feel like your degree really helped you in your career or …

Paul: Mine did. I think, these days, having a computer science background
has a very direct effect. I wouldn’t say five years ago 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: It’s getting complicated.

Paul: 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 four months to learn how you should have done things. Yeah, computer
science has a big influence on where the trajectory of front-end
development is going, for sure.

Nick: Cool. Well, I think a big challenge that’s facing people coming out
of college today is just 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?

Paul: Yeah, I started out, I was doing some marketing for a stationery
company that made wedding invitations and birth announcements, and it
wasn’t even starting out 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 like, depending on the customer,
and it was all this logic inside Word. It was awesome.

That transitioned, just within that job, into working on their e-commerce
presence so that was good. I think for most people, having something that
you can develop on your own, so in my case I had that, 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 a
place where you can kind of 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 just kind of
encouraging and let you kind of explore things, get feedback, having a
social community that you can kind of talk to and explore your own
professional development with. I had one and it’s a very smart way to go
about things.

Nick: So what first attracted you then to front-end development,
specifically, because you were making a blog. Did you do that in like
WordPress or something?

Paul: Yeah. That was WordPress.

Nick: OK. I mean, why aren’t you, say, like a Ruby or a PHP developer, for
example?

Paul: Sure. Yeah, for me, the thing that really rocks about front-end is
that you’re building the interface. 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, that their cursor is going over what you’ve
created. You’re basically in a position 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 like very sexy to me.

Nick: So it’s kind of about that instant gratification then?

Paul: 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 tech shadow to it and make it
hard to read or something. I don’t know.

Nick: 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. So first, how did that project start?

Paul: Before working for Google, I was at an agency in Boston making
websites, web apps. 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 mark-up and from my CSS from my last one into my new one.
Then I was like, “Well, I should probably make a template to just keep
track of this, so I can just start off with a template each time.” That’s
the original genesis was just like I needed to keep track of all this stuff
and move it forward from project to project. I soon after got Divya Manian
involved. We put out a 1.0 just to see what everyone else thought, and
immediately it was really great because inside HTML5 Boilerplate is a bunch
of techniques. One of the things that has kind of continued until a little
bit ago was basically having in-line documentation and 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. But you can kind of understand why everything is in here.

What happened was 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 actually being like, “Actually, I see what you’re doing here but if you
tweak it, this is actually a much stronger position. It accounts for this
educates bug in Opera 9.6 or something like that.” Every character inside
HTML5 Boilerplate has had a lot of discussion around it. So everything that
you see is the result of extensive conversations that have included some of
the best front-end developers in the industry, and 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 descriptive explanations of why
we’re doing this. It’s very well justified in kind of why all these
decisions are very strong as a baseline for starting your web project.

Nick: Cool. I think when beginning developers look at HTML5 Boilerplate for
the first time, they’re just like, “Whoa. What’s all this?” So 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: 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 just look
svelte and sexy and just minimal and I love doing that as well. Inevitably
when you’re developing, so this is not so much a problem for IE6 and 7,
which have basically no market share any more. IE8′s definitely still
around. But it’s been the case where they have actual CSS bugs in their
implementation. You can use CSS hacks like kind of 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.

The conditional comments provide kind of a first class way, that is, 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 just 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 within
height on an element will let you avoid doing that. So you should try to go
as long as you can without specifying specific browsers. But it is there
when you need it and it helps a lot.

Nick: There’s plenty more in Boilerplate that we could talk about. I’ve
heard you talk about all the weirdness of carsets [SP]. 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: 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” and I
submitted it a long time ago and it’s the highest voted. It’s in HTML5
Boilerplate, and this is the protocol relative URL. So down at the bottom
when we include jQuery, we pull it in from the Google CDN but the script
source is equal to //ajaxgoogleapis.com stuff stuff. We get pull requests
and bug reports on like a monthly basis like, “You’ve got a typo. You
missed the http:.” And we’re like, “Actually, we didn’t.”

So the protocol relative 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 just 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 in your
browser it says “file:”, it can be really slow. If you use a local
development server, however, you don’t have the problem. I think the
feature’s really awesome, and that’s probably one of my more favorite
things.

Nick: It’s crazy you brought that up because I was just looking at that the
other day trying to figure out what happened here.

Paul: Exactly.

Nick: It’s kind of amazing to me just how much goes into, supposedly,
vanilla webpage. I mean, it’s called “Boilerplate”, right?

Paul: Yeah.

Nick: 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: Well, there are two things happened 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 like just about 1%. IE8′s
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’s getting easier. By the same
point, the last three years have brought an enormous amount of features to
browsers that we now get to incorporate and figure out the best way to
incorporate.

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 that you do. But you can choose to feature detect it with
Modernizr and then use jQuery to animate the same general transition.
Figuring out kind of 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, and
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 are
more and more resources out there that help.

Nick: 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: 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, and
I kind of don’t want to be there. 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 kind of the old state
of “the experience must look the same in all browsers” to the new one,
which is like, “We featured a text until we find out what we can provide.”
And there are a lot of combinations of how your site looks. Then you’re
bringing a 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’s 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 OK. 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. 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 you as a
developer, of course.

Nick: There are so many steps that are involved in front-end development at
this point. This is something that you were blogging about recently where
you said the tool chain is kind of 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 that together, or 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: Sure. Yeah. 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”. 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 a baseline of features that most front-end
developers use. 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, co-workers, 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 our project, it’s not frustrating and instead it’s fun and I’m
getting work done quickly. Because every time I watch someone else do their
work and I sit next to them, I’m like, “Whoa, whoa, whoa. What did you just
do? What was that keyboard trick?” I think we should do a lot more of that.

Nick: Do you think it’s OK for people to just use this stuff and maybe, not
totally understand it but just know, “I need to do this thing for it to
work”? At what point, does it just become an abstraction?

Paul: That’s a great question. 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. 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. There’s really not 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 jQuery, for instance. This has been a long time question
which is like, “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. But at the same
time, you don’t want to have to learn a lot of the intricacies of the DOM
work very early on.

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. At
some point, you’ll just be like, “Why?” and you should be asking that
question. But that shouldn’t preclude you from using the tool. At the end
of the day, you want to enjoy what you are doing and you want to do it
fairly quickly and you don’t want to be frustrated. So use the tools that
are available. I think it’s important to understand how they work. I’m
like, right now, trying to get a better understanding of how web 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 browser
works. I think we’re OK 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: So, wrapping up, what advice would you give to web designers and
developers out there just as a very general question? What can they do to
better themselves?

Paul: Yeah, one of the things that happened to me a while ago is I joined
the jQuery IRC channel. IRC, it seems nerdy. Yeah, Nick’s like, “Definitely
nerdy.” I joined that a long time ago and I was just super active in it,
and that’s how I got involved in the jQuery project, starting doing develop
relations for jQuery and joined the jQuery team. I was involved in the
project for a long time, and it was all because I just joined the IRC
channel and just started talking to people and helping people.

Helping other people with front-end development, you learn a lot and I
would recommend that. At 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 like 20 of us. It was also
on IRC and we would just talk all the time about what we were doing, and
this kind of led to there was a little bit of competitiveness, but a lot of
cooperation. We would work on projects together. Things like
MovetheWebForward.org and HTML5 Please have come out of this group. So that
you’re not just like alone and without a mentor. It’s great to have a
social group where you don’t feel completely inferior to everyone around
you and can kind of support each other.

Then the last part of this is really just to be able to have fun while
you’re learning, and 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.” “But why? Why?” And you’ll be like, “Well, you know, 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: That’s the advice that I always give to people is just do cool stuff
and share it with other people.

Paul: Yeah. Absolutely.

Nick: Awesome. Cool. Well, thanks so much for being here, Paul. I really
appreciate it.

Paul: Cool. Thanks.

Nick Pettit

Nick is a designer, public speaker, and teacher at Treehouse. He is also a co-host of The Treehouse Show. Twitter: @nickrp

Comments

3 comments on “Treehouse Friends: Paul Irish

  1. Thanks for sharing this interview! I agree with Paul when he says “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 our project, it’s not frustrating and instead it’s fun and I’m getting work done quickly.” I love the idea of being able to learn tricks and tips from co-workers. I think that’s the key to using a tool like Treehouse; supplementing the information with a team element creates a quicker learning process and a super fun atmosphere. Cheers!