Greetings, everyone.
Welcome to Rethinking Full
Stack: Cost and Compromise.
My name is Jeremy Osborn.
I'm the academic director of
Aquent Gymnasium, which you
can find at thegymnasium.com.
And what do we do?
Well, we offer
free online courses
on topics such as web design,
front end development, user
experience, JavaScript,
and much more.
This webinar is the
latest in our series
of discussions with notable
figures in the industry.
Today, I'm joined by two
said esteemed professionals,
Eric Meyer and Dan Mall.
We're going to do some formal
introductions in just a moment,
but let's talk a little bit
about the format of this.
I'm going to be talking
with Eric and Dan
for about 45 minutes, and
then leave around 15 minutes
at the end to take questions
from everyone here.
We do have Gymnasium's own Keir
Cullen Janey in the background,
and she's going to be
available if there's
any technical problems
or support that you need.
Feel free to enter it in the
chat window in the control
panel here.
And there's also a
questions section,
so you can add those
questions at any point.
But again, we're only going
to answer them at the end.
Also, when you
registered, some of you
sent questions ahead of time.
So I'm going to
be sprinkling some
of those throughout the event.
And we'll spend some
time talking about those.
So thank you for those.
So onto our guests.
First of all, we have Eric
Meyer, author, speaker,
blogger, sometime
teacher and consultant,
technical lead at
Rebecca's Gift,
and co-founder of
An Event Apart.
Eric's been working
on the web since 1993
and still finds it
deeply compelling.
He also released
the fourth edition
of CSS, the definitive
edition co-written
with Estelle Weyl,
published by O'Reilly.
Good afternoon, Eric.
How are you, sir?
Pretty good.
How about you?
Fine, thank you.
Thank you for joining.
Yeah.
Glad to be here.
And next up we have Dan Mall,
creative director and advisor
from Philadelphia.
He is the founder and Executive
Director of SuperFriendly,
a design collaborative
that brings
exquisite creative direction
and design to the world's most
important and interesting
organizations, also
the author of Pricing
Design, co-founder and CEO
of SuperBooked, and writes
about design and other issues
on Twitter and on
his site, danmall.me.
Hello, Dan.
How are you, sir?
Hi there.
Doing great.
It's a cloudy,
windy day in Philly.
Cloudy, windy day.
It is the same here in Boston.
And how about you, Eric?
Cleveland, what's
the weather like?
Oh, it's somewhat cloudy,
although not too bad
for this time of year.
And we had frost on the
ground this morning, so--
Nice.
It's the first time since
last winter that we had frost,
but there it was.
So--
Excellent.
Well, thank you again, both
of you, for joining me.
I am super excited to
have this conversation.
And before we dive in, I
wanted to talk a little bit
about some of the rationale
for this discussion
and some of the thinking that
went behind this topic, which
has to do with the difference
between full stack web
development and front
end web development.
But kind of more
specifically, I'm
going to point to this
article by Mandy Michael,
and her Twitter
handle is down below.
And the article had
this compelling title,
"Is there any value in people
who cannot write JavaScript?"
And if you read the
article, it talks a lot
about this kind of interesting
dynamic in the web industry
and among managers and
folks who run web teams
and among designers and
developers about the emphasis
on full stack, which we're going
to talk about in just a second.
But really, what
that is is HTML,
CSS, JavaScript, and potentially
some other back end frameworks.
So that's full stack.
And then on the
other hand, we just
have front end, which again,
you can define what that means.
But for now, we'll
just say HTML and CSS.
Some other folks have
written about this, too.
Here's another interesting
article by Brad Frost,
and the link to that article
is down below, as well,
where Brad talks about walking
into organizations and asking,
who owns the front
end code here?
And typically, that answer,
which should be simple,
is not always simple.
Who does own the front end code?
So those are some of
the things that kind of
inspired this talk.
And there's just
a few other things
that came up in the questions
that the registrants came
and submitted.
I'll tear through
just three of these,
and this will help frame
the discussion, hopefully.
So Melissa asked
this, where does one
start to make that
decision between front end
and full stack development?
So this is kind of one part.
This next part is without
an agreed definition
of how much stack it
includes, is this term full
stack even useful, or
just a resume buzzword?
And then last, full
stack developer
hadn't been coined as a term
or need in the 90s and 2000s.
Did managers or did
developers originate it?
So let's just make sure
we're on the same page.
And it'd be interesting,
both Dan and Eric,
to hear first of all what your
definition of full stack is.
So Eric, do you want to
take a crack at that first?
Oh, I was going
to throw it to Dan
first, because he works
with clients more than I do.
Let's go for Dan first.
All right, I'll take it
first if it's helpful,
because I think
as an industry we
don't agree on the definition.
So like you said, Jeremy,
when you were teeing it up,
some people call full stack
HTML, CSS, and JavaScript,
right?
A lot of people would
also call that front end.
They would say HTML, CSS, and
JavaScript is the front end,
and the full stack means
front end and back end.
So I think to me that's
one of the places to start.
It's like, what do you
mean when you say that?
And so for me and when I work
with my clients and the people
that I tend to
work with, we tend
to avoid the term altogether
and just not say it
because people
don't know what we
mean by it, because we always
end up having to define it.
So I'm not sure that I have
a good definition for it,
nor have I seen a
canonical definition.
I think normally rather
than saying, oh yeah,
this is my full stack developer
or I'm a full stack developer
or we work with the
full stack, I generally
try to be a little bit more
explicit but for clarity
to say, oh yeah, we'll be
doing the HTML, the CSS,
and JavaScript,
or yeah, we'll be
doing both the front end and
the back end, which means HTML,
CSS, and JavaScript,
as well as building
this thing in whatever,
Laravel, or something like that.
Mm-hm.
Yeah, I mean Eric, you've
been in the industry
as long as anyone.
And so this idea--
do you recall when this
term started popping up?
And even if you
can't recall that,
what's your take on
the term in general?
Time gets fuzzier
as I get older,
but I feel like in the last
five or so years is when
I've started seeing it a lot.
I mean, I've come
across it before then,
but it feels like that's a sort
of rough time frame in which I
started to see it.
I mean, to me if someone said
to me, define full stack,
I would probably say
front end plus back end,
right, which front
end, as we said,
means HTML, CSS,
usually JavaScript.
And then back end is
whatever's in back.
But that's because I come from
a front end perspective, right?
I've done back end
things, but I've primarily
worked in the front end
for lo these many years.
If I were more of a back
end person, I might say,
it's the browser
plus these six things
we've installed on our server.
And I think that gets
to what Dan was saying
is that there is no
agreed upon definition.
And depending on who he's
talking to at a given client,
even at a single given client,
if he's talking to the back end
guys, they have one
thought about full stack.
The front end people have a
different view of the stack.
If you want to get super
technical about it,
the full stack is literally
every piece of technology,
front end and back end.
But that's difficult, right?
The front end I
think probably we
tend to have a clearer view
of, because there are so
few actual things, right?
You have HTML, CSS, JavaScript.
And if you want to count
images as a fourth part
of the stack, which we could
have that debate, that's it.
The only way you can parse
that any finer is, well,
which format of
image are you using?
And if you're using a particular
JavaScript framework, which one
is it, those sorts of things.
Whereas on the
back end, it could
be PHP, Ruby, Laravel,
Expression Engine, which
is sort of PHP, and et cetera.
There's a whole
lot of stuff that
can happen on the back end.
So I think that's where a lot
of the confusion comes from.
And it's much
easier to just say,
it's these three
things on the front end
plus server over there, right?
Right.
Is it Apache, or is it
Expression, or is it .NET, ASP,
whatever they're
calling it these days?
Right.
And I think that's--
yeah, so this is
part of the dilemma
is that there is this
term that kind of gets
loosely tossed around.
It is like you
can do everything.
And of course, on
the face of it,
I think a lot of organizations
would look at that
and say of course.
Of course we want those
folks, because they're
interchangeable.
And if you have a team made
up of four or five quote,
"full stack
developers," it's almost
like you can mix and match
and they can do everything.
They could do the
user interface.
They can do again the
database management.
And that's obviously a
little bit of a pipe dream.
And I think the reason,
part of the thing
is that if this is
becoming a standard,
does it create a form
of anxiety in folks
who only consider themselves
front end developers?
I think the answer
is yeah, it does.
Yeah.
Oh, go ahead.
Yeah.
No, I agree.
And actually, there's
a guy at Digital Ocean
named Joel Khalifa.
I apologize to Joel for probably
mispronouncing his last name.
But he literally has a talk
called full stack anxiety.
He talks about this and
how he deals with it.
Yes, and I think
it's totally a thing.
And I think the other corollary,
the other term that that gets
bandied about a lot is
also the imposter syndrome,
which is again, someone comes
on a team and they're supposed
to know a certain part of
the stack and they don't.
And so they feel like
they're faking it.
So Dan, I see you
nodding your head.
Is that something you've seen?
Yeah.
I mean, I think that
the anxiety has sort of
evolved with the way
that the industry has.
So like I'm just kind
of hearkening back
to how I've experienced this
as a designer and developer.
I remember doing
work in the mid-2000s
when before responsive
design came out
and when browsers were
supporting standards really
well, and I remember AJAX
becoming a thing then.
And I think to me it was
when AJAX sort of became
popular because
the conversations
we started to have
before that was well,
you write the HTML
and CSS, and then
the back end developers would
write the JavaScripts, right?
If we needed any, because we
would build a lot of sites
that just didn't need
a lot of JavaScript.
And then when AJAX came around,
it started to be like well,
as the front end
developer, I don't
know enough about JavaScript
to write AJAX calls or anything
like that, so maybe
the back end developer
should be writing
the JavaScript.
And that became really
weird, because the back end
developer's well, it's
a front end technology.
It's a client side
technology, so technically, it
is not part of my purview.
And I think ever since
then it's escalated, right?
So as a front end developer,
I don't know enough JavaScript
to be able to do this.
And since then, now we have
server side JavaScript,
where JavaScript used
to be client side only.
But now we can write
node on the server.
And so kind of the
division of those lines
became a lot blurrier.
And speaking from
that point of view
like I know a little
bit about JavaScript,
enough to build sites with
it, but I'm not by any
means a JavaScript expert in the
way that I know HTML and CSS.
So there is a lot of anxiety
that comes with the fact
that oh, I should be
writing AJAX calls,
but now I'm writing server
side code in a client side
technology, so I see
how a lot of people
that come from that background,
myself certainly, I get anxiety
around that and just go well,
I don't know how to do that.
Am I supposed to
know how to do that?
Do I need to learn that?
But isn't that somebody
else's job, and then
am I stepping on toes?
So I think that the evolution
of the industry I think maps
nicely to the anxiety
that-- or not nicely,
but maps well to the
anxiety that I think people
that have that experience have.
Yeah.
And that's interesting, because
when you did your talk at Event
Apart here in Boston, one of
the things that I remember very
clearly in your slide
was one of your slides
was talking about the fact that
modern designers, for example,
should know JSON.
So how does that kind of fit in
with this kind of definition?
Like, where is this line?
And I think maybe
this is the question.
What should you know someone
who calls himself a front end,
or-- to what degree do modern
web designers need to know
a little bit about this stuff?
Yeah, so I think on the
surface, it looks the same.
But I think one of the
things that's really
an important distinction is
if the lines are going to get
blurred anyway, let's
do it in a way where
we're helping each
other rather than
in a way where we're
deferring, right?
So rather than going, well
JavaScript's not my job,
it's your job, you
do it, let's instead
start to share that
workload and say,
I know JavaScript's
not your job,
but I'm going to
teach you how to write
a little bit of a JavaScript,
even if that means
a little bit of JSON or a little
bit of configuring variables,
or whatever that thing is.
And I think that
that's the thing that
reduces anxiety on teams.
So there was a great study that
Google did, I forget the name.
I think it was the
Aristotle study
or something like that a few
years ago, where they managed--
or where they studied what makes
people perform well on teams.
And they analyzed a bunch
of different variables.
And what they thought their
initial hypothesis was, well,
if you put the best, the
most experienced people
on the same team,
they'll all do well.
And that didn't
turn out to be true.
Well, if you put the
most tenured people
or if you put the most
skilled people on a team,
that's not true.
And what they found was created
the best teams was where people
feel psychologically safe.
And I think part of that is
about just being OK with--
or helping your
team members, right?
If everybody does
this, everybody
helps their team members to go
I realize this is not your job,
and if you don't know how to
do this, I got it for you.
Don't worry about it.
But in the meantime,
let me create a scenario
where you can learn
where it's OK to fail,
it's OK if you don't know how to
do it, because I got your back.
I'll be the safety net.
But that way, you can grow, too.
And I think a lot of it--
I've seen that reduce anxiety
on teams, where I go, well,
what do you want to do?
Well, I'd love to learn Angular,
but-- and I'm all right, cool.
Well, if we don't end
up using that Angular,
we can do something else.
And then that creates a little
bit of safety for somebody
to go, oh, it's OK
if I don't get this.
And I've seen that work
really well in just reducing
the anxiety people have
about the pressure that
is their jobs, because
what do people think?
If I don't do this,
I'm going to get fired.
And that's a big deal.
So if you can
reduce that anxiety,
I feel like actually people
grow better in that environment.
Yeah.
And also, I think that it's
important to realize, too.
What I find
interesting, and Eric,
I think you hopefully
agree to this,
but I think so that
HTML and CSS, again,
may have this
reputation as being easy
or something like that.
And again, what I think of,
I go directly to something
like this, which
is Eric, this is
a copy of your latest book,
CSS, the Definitive Guide.
And if I remember correctly,
it's about 1,100 pages.
Almost.
I've been saying
1,088, but I forgot
that the PDF counts the
front and back covers.
So it's actually 1,086 pages.
So to me, that by
itself is almost
like well, CSS is a language,
and it's a large one.
And so talk a little
bit about that.
Yeah, I should admit that the
fourth edition doesn't even
have every bit of
CSS it could have.
There are bits that I left out
because they're too fragmentary
right now.
One that I think will surprise
people is multi-column.
I left it out
because browsers just
don't deal with it the same
way, and the whole spec
might be about to
change, anyway.
So that probably could have
added another 10 pages.
CSS, I mean--
CSS more and more--
this has been true
for a long time,
but more and more it
reminds me of that old tag
line, minutes to learn
but a lifetime to master.
It might be a large number
of minutes to learn,
just because there are
so many properties.
But the mastery comes
from understanding
how all those pieces interact
with each other, which
is the source of most of
the bugs, to be honest--
at least these days.
If you come across a layout bug,
it's probably because somebody
didn't think about this
particular combination
of things that you
happened to put together,
which is why when
people run into those,
It's super important that
they report them to Firefox
or the WebKit
people, or whoever,
to say I had a Flexbox in a
grid that had some absolutely
positioned stuff in it, and
then I added an SVG that I had
a clipping box on, and
suddenly the whole thing ...
I mean, whatever it is,
just because nobody ever
managed to get down to
that level of testing.
And that's why CSS, for example,
is a lot more complex, but also
a lot more powerful than
people give it credit for.
I think HTML is
kind of the same.
You know, I think most of us
learn the bits of HTML we need
to do the thing
that we're doing,
and we forget that there's
a whole lot more in there
that rarely gets used but
might actually be useful.
Not many people used
the data attributes
until they were forced to
by some framework or other,
and their only understanding
of data attributes
is how they relate to being
used in that framework.
But there's a lot more
that could happen there,
to pick one example.
There's plenty more, as well.
The various input types,
which admittedly not
supported super well.
But there's a
color picker input.
You put in type equals
color, and in theory you
should click on it,
it will give you
a little palette where you can
pick a color off a color wheel
and have little sliders,
and all that kind of thing.
Those haven't been very well
supported, but they're there.
And most of us
aren't aware of them.
And HTML4, as simple as it
seems, it's still complex.
I think the reason
that the two of them
get looked down
upon by people who
are more traditional programmers
is that HTML and CSS don't
really have things
like looping structures
or real conditional logic.
CSS has that a
little bit with media
queries and feature queries,
but it's pretty coarse grained.
It's not the let me test
for these three things
in this combination
of parentheses
and symbols and that.
If those all evaluate to
true, then do a thing.
It's not that kind of
language, which in one sense
is good, because by not being
those kinds of languages,
HTML and CSS are incredibly
fault tolerant, right?
You can botch half your
markup and half your CSS
and still have something
come out the other end.
That's a really remarkable
design paradigm, and most--
the imperative languages,
compile languages or even
JavaScript, are not like that.
You get one curly
bracket missing
and the whole thing just fails.
XML is kind of the same.
Actually, XML is the same.
So why is it, then, that it--
it seems pretty self-evident,
I think, that this--
both HTML and CSS feel like
they're pretty complete
and deep disciplines.
But again, I turned to some
of the questions that we got.
And I got this one,
which I thought
was kind of interesting.
Why is there still weirdness
between front end development
and back end development?
In my traditional organization,
back end development
still dominates tech
leadership in decision-making.
So I found that kind of
an interesting question,
and I think it kind
of speaks a little bit
to this idea of the
culture of maybe
engineering versus design.
I don't know.
But why is it so
hard to do that?
Is it economics?
I don't know.
I would guess that
the dominant force
in that particular
equation is going
to be more rooted in the history
of the organization, right?
It's going to be which was
the larger organization when
it got started and which
has paid off more, I guess,
or in more measurable
ways for the organization.
Like if the back end
development group has provably
made the company x number
of dollars and the front end
development people don't
have that even though they're
the ones who put a front
end up on the thing
that the backup people did,
then the back end development
people might dominate.
Flip it around if you're
a design shop or a design
agency, a web designer agency.
Front end's probably
going to in most cases
lead that conversation,
be the dominant force,
whereas back end will be
sort of support for them.
But I'm mostly guessing.
We should actually-- I should
have let Dan go first again.
No, I agree with that.
I think that in addition to
that, front end developers
and back end developers
have different things that
are important to them.
And unfortunately for
front end developers,
the hills that
they pick to die on
are things that aren't
important to people
who don't understand it.
So I've been part of
many a conversation--
I've caused many a
discrepancy about should we
use a section tag here or an
article tag here, and argue
about that for days, just days.
And people are like, yeah,
but I can't log in, right?
And that's the purview
of a back end developer.
So I think that a lot
of the things that
are important to
front end developers
are things that unfortunately
are not important to people
in other parts of the business.
And the thing that
they relate to
are the things that they tend
to look to for all right,
well, let's let that drive.
If I can't log in,
it doesn't matter
if we're using a mark tag here.
It doesn't matter if
we use an OL or a UL.
Semantic arguments are literally
that, semantic arguments.
And sometimes they don't
affect the bottom line.
And I think that generally,
front end developers,
they tend to be shy about that
and they tend to go, well,
that's not important to me.
What's important
to me is that we
have the right mark up in place
or that my CSS is OOCSS and not
BEM.
And those are things that are
very important to the process,
but people don't understand
it and a lot of developers
don't do a good job
of communicating
why that's important.
And so people go,
all right, I guess
you're just upset
about some nerdy thing.
Can we log in or not?
And so I feel like that's
where engineering and back end
development tend to drive
more, because it's results
that you can see as opposed
to results you can't see.
Right.
And I think it goes back to
that idea of the culture, too.
I mean, I think some of this
has to come from the top down,
right?
And it's kind of interesting how
we've seen over the last 10, 15
years, how Apple, for
example, has promoted
this idea of design as
being an important component
of their success.
And so you see other
organizations trying
to adopt, at least to different
degrees, the lip service
to that and they're
hiring designers
and they're hiring UX folks,
and content strategy folks
have kind of got a
seat at the table.
But it still feels like there
is this other trend that
comes back to JavaScript that--
and Dan, you kind
of mentioned this
I think in one of your
tweets for the event.
In a world where
JavaScript is kind of king,
there's this interesting
conflict happening.
And I feel like this is part
of-- this is an industry
wide thing, and it's a
business decision, as well.
So if you are an
engineer, let's say,
let's say just a
thought experiment.
If you were someone who was
in charge of setting up a team
to create a new web app for
whatever reason, what kind
of-- and I know, Dan,
you do some of this.
Your organization is
based around stuff you do,
but you kind of adopt your
teams based on the project.
So what kind of
things do you look
for when you're embarking
on a project like this,
and what are the roles
that are important to you?
It's complicated.
And I think that that's the
underlying pinning around all
of this is that it's complex.
There's a lot of
variables and they
change all the time,
project to project,
organization to organization.
And so one of the
variables is what
is the ratio of how
quickly we need to do this
to the expertise that is
in-house to the expertise
of the consultant to what's
important to the business.
So for example, one that our
industry talks about a lot
is accessibility wasn't
important to target
until they got sued,
and then all of a sudden
it became important.
And you could certainly
make the argument
that it was always important,
they just didn't realize that.
And I think that in
building teams or thinking
about projects, it's about
what really is important.
What is the-- as a
service provider,
one of the things I'll
always ask my client
is what is important to you.
And so I take stock in
what they say is important,
but then as a
professional who's been
who's done a lot
of these things,
I can also hopefully bring
some stuff to the table
and my team can bring some
stuff to the table to say,
here's some things that you
may not say is important
and you may not even
be thinking about,
but we think these
are important for you.
Let's have a
conversation about that
and let's have an education
process around those things,
things like if we build
this in Angular versus
if we build this in React versus
if we build this in something
else, what does that
mean for your team?
What does that mean about
performance for your users?
What does that mean about
who can maintain it?
So I try to let the practicality
drive a little bit more
than the philosophy
drive, but you know,
it's always a balance
between the two.
And where it falls on that
spectrum between philosophy
and pragmatism, I think it
varies greatly from project
to project.
Right
And I think one of the
things, as far as tying back
to the previous question,
one of the things
that front end can deliver on--
and there is growing
awareness of this--
is literal page
performance, right?
So there's how fast can you
get it out of the server
and across the wire to
the user, but then there's
how long is it going to take
for that to actually start,
for time to first
display or whatever
particular metric you're using?
I know of engineering teams--
I know they did this at
Etsy, maybe they still do,
where they would
constantly run--
they would run page speed
tests under various network
conditions.
And you know, they would
have literally monitors on
the wall of the
engineering offices
that would show here's what
this is like in broadband
in the USA, and here's what the
same page is like in dial up
in the USA, and in Europe, and
in Australia, which apparently
they nicknamed the
sorry Australia,
because Australia has really bad
links to the rest of the world.
And it show the videos.
It was like as of
midnight last night,
the last time we
took these videos,
it took two seconds to
render the page completely
on broadband and six seconds in
slower broadband or 3G speeds.
I said dial up earlier, I
didn't actually meant that.
And nine seconds in Australia.
So people could see, they
might come in in the morning
and look up and say like, why is
it suddenly taking five seconds
to render the page, right?
Which has nothing to do
with the network speed.
It's just what did
we do last night?
Did we add a super
huge web font,
or did we accidentally push
the absolute highest res
copy of all the
images out instead
of the responsive images
or whatever it is?
But that's-- back end certainly
has to do their part to get
stuff out fast, but then
front and has to do their part
to make sure the stuff renders
quickly and it isn't a 20
megabyte page because it's
all these huge images.
It's like how can
they shave that down,
because that really is--
it's a user experience problem,
not just in the sense of hey,
we have to not inconvenience
our users even a tiny bit, which
is OK, true, but
someone who's on 3G
and needs this information
for whatever reason,
and if the page is breaking
because there's just
too much data to
stuff down the pipe
or it takes 30 seconds to
render because of everything
that's coming at them.
Whatever the scenario is, right?
They're in the
basement of a building
and they have hardly any
bars on the LTE or 3G.
Can they still get this?
Is it going to take
forever to load?
Is it going to take
forever to render?
And that's an actual
measurable thing
that I think front end people,
if they're not focusing on,
probably should be.
Well, yeah.
And to me, that
almost speaks back
to the that article I
was mentioning earlier
from Brad, where again, there
is a risk where you should be
able to walk into any
sort of project or team
and basically say, who really
owns this front end experience?
And I think that that's
part of the danger
is the way I see it is
that if you are biasing
your group or your team towards
this kind of engineering,
JavaScript heavy experience--
because you know,
the truth is that this
stuff is difficult to learn.
And if you're expending
a lot of time and effort
to get up to date with
the latest framework,
whether it be Angular or React,
that that is a full time gig,
I guarantee you.
And that's why we
have classes in them.
We have classes in Node
and JavaScript and all
these things, because
this is the way
this is the way of
the world in the web.
My fear is I think that
there is this overvalue being
put on the JavaScript
and framework knowledge.
And the danger is
you lose things
like who's paying attention
to the user interface
and who's paying attention to
the performance stuff, which
again can fall under back
end, but do you really
have someone who is doing that?
Do you really have someone
measuring performance?
So Dan, like in
our talks earlier,
you had mentioned that
in fact that there
is another scenario, which
is that if you have someone
or people who are just
focused on back end,
that that can actually
almost damage a product
or damage a web app,
or whatever you have.
So can you expand on
that a little bit more?
What was your
thought behind that?
Yeah.
I mean, I think one of the
things that's really damaging
on teams is siloing work.
Because as I think about all
of the projects that I've done
that didn't go so well, where
everything falls through
the cracks is where hand-offs
didn't happen properly or where
oh, I thought you
were going to do--
no, I thought you
were going to do that.
And then someone forgot
and no one did it.
And so I find that the way
to correct that or the way
to help that is to create
more overlap between roles
rather than space between them.
And so when engineers are
like, well, I don't know,
the login is right, the
login's working, I go yeah,
but people want to be able
to see their password.
Oh, I mean, I just
installed the framework.
If they defer what might not be
their responsibility but they
might be accountable
for it or even
just thinking about it,
that leads to well, listen,
I did my work.
What more do I have to do?
And I think that that's
a toxic team member.
And if the culture
of your organization
is such that everyone is
expected to behave that way,
you're actually creating
a whole toxic team
without knowing it because
that's what everybody expects.
And so I find that
that's not just
exclusive to back
end developers.
It's all of the roles.
It's designers, developers,
content strategists,
information architects.
You know, if somebody builds
a site architecture that
doesn't work well with
an engineering structure,
that's a problem, too.
So it's not just the
back end developers
who are the only problem in
that scenario or front end
developers, or anybody.
I think it's the siloing thing
that is really dangerous.
And so one of the tools that
I use a lot is a RACI matrix.
At the beginning of a project
I'll put together a RACI matrix
of R-A-C-I, responsible,
accountable, consulted,
informed, so that everyone on
the project has to be at least
one of those things on
every task that we're doing.
So information architecture,
maybe the front end person
doesn't need to be responsible
for the information
architecture, but
they should at least
be informed about something.
There should be nothing
that's like oh, I didn't even
know that was going
on, because I think
that leads to unengaged
teams, and that means
something's going to
fall through the cracks.
So I think that by
eliminating those silos,
I think you start to
avoid that problem.
Interesting.
So that's kind of cool.
Is this matrix
something you came up
with or is this a known thing?
Oh, no.
This is like decades
old management practice.
I'm sure somebody
came up with it.
I just found it one day and I
was like, this is a great tool.
Nice, OK.
It's good to know.
Yeah, I mean, it
comes back to again,
I'll just share one of
these other questions, which
again hearkens back
to that original one
that I just mentioned.
Matt was asking,
what is the minimum
a front end designer
must know technically
to succeed in today's market?
Which again I know is a very
general question, but one
of the things that I think
where that ties in and one
of the things that we try
to teach with the courses
that we offer is like
you said, understanding--
like again, your
last presentation,
it was like, should
designers know how to--
and whatever that is, like code?
Well, that's another talk.
But being aware of the technical
underpinnings is important.
Understanding what's happening
with your Node server
is maybe not.
OK, so I guess one of
the other questions
is what can we do
about it, which
is a much harder question.
I think this is
part of what we're
trying to do here,
or at least for me
and for Gymnasium, is
trying to address that.
But what other things--
again I think you had
mentioned speaking out.
I think that was you,
Eric, who was talking about
if you're a front end designer
or developer, that taking
ownership or speaking
out is important.
But what other
things do you think?
I mean, this is where the
full stack anxiety kicks in.
There's so much, like,
what else is needed?
And everything and nothing--
it gets Taoist really quickly.
Right.
Well, it almost leads me to
think of a lot of the work
that you've been doing,
too, has to do with empathy
and trying to understand
real world design.
I mean, how does that tie in?
Because to me, again it
feels like there's like a--
if you're making
trade offs, you're
hiring a team who is
predominantly technical
and back end, are you
sacrificing something
like someone who is
really paying attention
to the user experience?
That has to play in at
some point too, right?
Yeah.
I mean-- I guess this is
organizational full stack
anxiety.
If they cover the stack, how
are they going to cover it?
And if they hire--
like you say, if you hire a
person who does X, Y, and Z,
you're not hiring someone
who does A, B, and C.
And hopefully you can
also hire somebody
who's doing A, B, and C,
but at a certain point,
I guess budgets run out.
Here's the thing
in organizations,
they have a limited
amount of money, I guess.
So yeah, you do have
to make those choices.
I think-- well,
I personally feel
that having a team that's
as diverse as possible
and like Dan was saying, as
overlapping as possible--
and when I say diverse, that
also means in terms of skills,
right?
So hiring six Node
developers is not
going to get you
as far as hiring
a couple of Node developers
and a couple of front end
people and UX and an IA,
right, which seems on its face
to be laughably obvious.
And yet, to think of
other ways in which
that you know that sort
of mix can be found,
whether it comes from
people's backgrounds,
their educational backgrounds,
or personal backgrounds,
the culture they come
from, where they grew up
all those sorts of things--
age, experience.
I personally think--
and again, easy
for me to say because I don't
have to manage a hiring budget.
But I think that if
we want to increase
that sort of
diverseness of the team,
you need to hire somebody who's
new and doesn't necessarily
know everything that you need
but seems capable of learning,
because someone in
that situation who
has more experienced
people to help them
and who is ready and
eager and able to learn
will probably actually
enrich the team quite
a bit more than somebody who's
been doing it for 30 years
and has become
set in their ways.
Right.
Yeah.
And again, I think it comes
back to that idea of burnout,
too, because again, if
you are in a position
and you're constantly having
to, again, learn the latest
and greatest framework and
everyone now on your team
is chasing that the
tech, almost goes back
to what you were saying, Dan.
There's a lot that can
fall through the gaps.
And so yeah, if there are
hiring managers and people
running teams out
there listening,
I think that this is
kind of a piece of advice
worth repeating, and
that diversity of teams
is really important.
Diversity of skills is
extremely important.
It tends to make projects
healthier in the long run.
And teams more productive,
according at least
to what research I've seen.
Yeah.
And that goes back
to here, let me--
so Dan, you had sent that study.
So this looks like a
really interesting article,
"What Google Learned
From Its Quest
to Build the Perfect Team."
So this is all good stuff.
We're heading into
that section where
we need to look at questions.
So for folks who are
listening, again,
you can feel free to throw some
questions into the questions
section of the go to
webinar control panel,
but we do have some here.
I'm looking at these
for the first time.
So we get one from Charles here.
And either Dan or Eric, either
one of you can take this one.
But can front end
be divided or split
into design versus interaction?
It's kind of an interesting one.
Dan, what you think about that?
Is there-- is the web
interactive by default,
or is there a design
versus an interaction?
So I think there's a lot of
different schools of thought
about that.
And I think that one of the
articles that you had teed up,
Jeremy, in the
beginning, is the article
by Brad Frost about the
full stack developer.
And one of the
things that I know
that Brad is keen on,
partially because he's
written a lot about it,
partially because I've talked
to him about it and we
work together a lot is
the idea of there's something
in the middle between design
and development called
a front end designer.
And so that's sort of saying
the person who is writing code
is somewhat responsible,
if not responsible,
then at least accountable for
some portion of the design.
And that might mean designing in
the browser, designing in code,
sitting with a designer,
being part of that process.
So that's one side of it.
One of the things that I'd
love, and I sort of set up
some of my projects to do
this-- not all of them,
because it's not
always the right thing.
But I sort of think
about it as a spectrum
but design to engineering, and
with different people occupying
different parts
of that spectrum.
And so on my teams,
it's less important
that people have titles.
So I think we get
away from that, right?
So rather it's more
about what are you
going to do as opposed
to what are you, right?
So it's not like--
I don't hire a
front end developer.
I'm just like some
projects I have somebody
who is writing the HTML and
CSS, and then another person
that's writing the JavaScript.
Other times, it might
be the same person.
So I think that just knowing
that the whole spectrum is
covered, and especially
that there's overlaps there,
I think that's another
approach to going about it.
So can you split it up?
Absolutely.
I feel like you can split
up any discipline as minute
as you can.
Whether or not that's
productive for the project
you're working on remains
to be seen, right?
I think that that's hard to say
globally that that will work.
But I think that it's
certainly worth a shot
to say, let's split
these into two parts
and actually see what happens.
And if that's
better than the way
that you were doing it
before, continue on with that
until it breaks.
And if it's not, then I
would try something else
or go back to the way that
you were doing it before.
I find it hard to
rationalize splitting design
from interaction on the web.
I mean, all design is
interaction, really.
All design has to consider
interaction, right?
The way our books are
designed, the ones
that are well-designed,
are designed
with the idea of turning the
page and what the spaces should
be.
That's a relatively constrained
problem space, right?
And how many times
have you driven
down the interstate or the road
and passed a billboard that
had like a wall of text on it.
You're like, the only
way anyone could ever
read that is by
causing an accident,
because somebody didn't
design for the interaction
necessary for that medium.
The web is more interactive
than either of those.
It's more interactive than
any medium there's ever been,
even down to the
minimum of you got to--
I mean, I assume you're going
to scroll a page sooner or later
and you're going to click
from one link to another,
or link from one
page to another.
Those things have
to be considered.
And you could try
to say all right,
the visual designers are here
and the interaction designers
are over there, but I feel
like that's counterproductive.
I feel like you're sabotaging
the process because the web is
a fundamentally interactive
and fluid medium,
and to try to design
as though it's not
strikes me as a bad idea.
Yeah.
Well, it's
interesting, because--
yeah, go ahead, Dan.
Sometimes I coach agency teams.
And a few of them
that I've actually
coached on process
and roles and things
like that, I've
actually encouraged
them to get rid of the
front end developer role
altogether, that they
only have designers
and they have engineers.
And within the
design discipline,
there's all sorts of designers.
There are some designers that
are primarily illustrators,
but they're called designers,
and some that are 3D designers,
and some that are--
and some of those
include people that
can write code.
And then on the
engineering side,
there are people that do all
sorts of things up and down
the engineering scale, which is
setting up servers or database
architecture, or whatever.
But also, some of the
engineers are also writing
front end code, too.
So I think that trying to find
an artificial split is tough.
But I think the developer role
is a particularly tricky one,
because it's squarely in the
middle of a lot of places.
It's squarely in the middle
of design and engineering.
So I find that for
some organizations,
it's actually valuable
to say, there's
no such thing as
developers here,
because we don't
know what that means.
There's engineers and
there's designers.
Some people that write
code are engineers,
and some people that
write code are designers,
depending on where they'd
prefer to spend their time.
Right.
Well, I find it interesting
that there is, again,
a lot of some of these
other questions--
there's a question
by John, which
is what's the line between user
interface and front end web
development?
And I almost feel like that's
kind of a similar question,
in the sense that a lot
of what we're trying to do
is define these
divisions, right?
And And again, it almost leads
into a discussion of like
the generalist versus
the specialist.
And at some point you have to
make some sort of definition,
or you have to put yourself
in some box, I guess.
So can I push back
on that a little?
Yeah, yeah.
Please, please.
Because I wonder
where that comes from,
where the idea comes
from that well,
I've got to be in
some sort of box.
And maybe because I
need to know how people
are going to interact with me or
what they would expect from me.
So I get that a little bit.
But why not learn it, right?
It's happening
already, and I think
maybe it's happening because
it feels more-- it's actually
more natural to do it
that way, and we've just
been fighting it so long that
we think it's the opposite.
And so to the question
that was asked,
I think it's a good one, where's
the line between interface
and front end?
And I would pose a
question back to that.
It's like, well, what
happens if there's not?
How does that affect the
way that you do things?
Yeah.
And I can imagine
in some contexts,
these questions arise
because what you do governs
what kind of title you have, and
therefore what kind of salary
you get paid.
I remember when I
worked at a university,
it was like engineering
level 1, 2, 3, 4.
And if you're this level,
you have this much vacation.
And if you're this level,
you get this much salary,
things like that.
But when it comes to
the actual discipline
that we're practicing
here, yeah, I'm with Dan.
Don't put yourself in a box.
There are enough
things in this world
to try to shove you into a box.
Don't get in one voluntarily.
Nice.
I like that.
Yeah.
And I think this is
probably-- you know,
it cuts to the
struggle of what--
I mean, all of us here, I've
been in the web business
for 15, 20 years.
And both of you guys have been
in there for a while, as well.
And you know, I wonder again
if you're starting out--
and we run into
this all the time,
that the entry point for a
web developer, web designer
is getting harder and
harder for us to define.
Even when I'm creating courses
and trying to figure out
where is that entry
level point, the amount
of stuff you have to learn
is extremely forbidding.
And so I think some of
this reflects where we are
as the state of the web, right?
The web is still
extremely young,
in the scope of other things.
So--
The article that
the agency Sparkbox,
which is in Dayton, Ohio, they
wrote this great article called
"The Hammer and the Chisel."
And I love what they're
doing, because I think what's
tough about what
we're talking about is
we're trying to come up with
these global rules, right?
Let's define what designer
and developer are, and then
everybody can follow
that and it will
work for all organizations.
And that's just really
difficult to do.
And so I love what
they're doing.
And they're saying
here, we are changing
what our titles are here.
And it might not even be titles.
It might just be how we think
about the work that we do.
So they have this position
called front end designer,
and they say but our front
end designers are different.
Some of them are hammers
and some are chisels.
So hammers are
responsible for setting up
HTML and CSS and architecture
and things like that,
and chisels are the ones
in there getting animations
right and font spacing right
and font size, stuff like that.
And so I love that
they are thinking
about how to define those
roles a little bit differently,
and it works for them.
They're not saying, oh, everyone
should have hammers and chisels
now.
They're just saying this
is what works for us better
in our process, and so
this is kind of how--
and so we're going to stick
with this for a while.
One of the questions
that I'll often go over
with my apprentices
who are trying
to get their first
design or development job
is that exact question.
What's the minimum
that I need to know?
And again, it's the same thing.
It's like the minimum that
you need to know globally,
that's a tough
question to answer.
And so my response back to
them is always the minimum
to get into what job?
Do you want to go
work at Facebook,
or do you want to go
work at a local agency?
Because those are
very different jobs.
At Facebook, you can be really,
really specific about your job.
I mean, Nicole Sullivan
consulted with them
on refactoring their CSS.
That is a very specific job.
But if you go and work
for a local agency
and you're one of
five people there,
you have to wear many hats.
You have to do information
architecture and design.
And so I think
that the specialist
and general conversation
often gets to but where?
Where are you talking about?
Because it doesn't work
like that in the world,
at least not that I've seen.
But if you want to work
at a particular place,
being a generalist is better
than being a specialist.
You want to work at a different
place, then being a specialist
is better.
So I think that that's one
tool that has seemed to help.
It's like, once
you pick the place
that you want to work or the
places that you want to work,
you might say, oh, I want
to work at small places.
And in that case, I need
to be more of a generalist.
Or I'd look to go work for
a big engineering or other
or start up or a
Silicon Valley company,
and there they need
somebody who is hyper
focused at a particular thing.
Yeah, and we're seeing some
other similar questions here.
I'm summarizing some of
these, but there seems
to be there's a lag, as well.
So someone is mentioning here
that they work for a startup.
And when they're giving the
CSS part of the interview,
that the interview questions
are kind of out of outdated.
They're about
algorithms, or they're--
so that's also part of it.
It's the standardization.
So I think that
that's a very how
do we-- and I don't
know the answer to that.
I don't know if anyone
knows the answer,
but how do you balance this
need for standardization
versus someone's skill set?
And I think it goes back to
what you're saying, Eric, too.
Some of it is salary,
unfortunately.
Job titles, job descriptions,
all of those things
are important.
Yeah.
And the larger the organization,
the more that tends to matter.
I think-- because I
don't know what Facebook
is like when it comes
to this, but I'm
sure they have a
distinction between engineer
and senior engineer, just to
make a super simple example out
of it.
And there might be different
levels of senior engineer
and different levels
of non-senior engineer,
and entry level and so on.
And yeah, it starts
to get down to well,
if I can meet the requirements
that somebody wrote in order
to qualify for this
next level of title,
then I can increase my
salary by 10% or whatever.
And I would understand
wanting to, even if those--
even if those requirements
are arbitrary and were
written five years ago, and
don't really apply anymore.
It's, like, oh, it looks
like I have to go learn PHP2.
Right.
Because I've updated it.
Right.
So--
Right.
And we're seeing some of that.
So Heidi from Seattle, I'm
guessing, because she mentions
it in her question,
says, you know,
can I get a job writing
HTML, CSS, and JavaScript
without any training
in the back end,
because in Seattle the
answer I've been given is no.
Why would we hire you
when we can have both?
And then she goes on to ask, is
that true in all major cities?
So-- I think that's kind
of like a similar tack of--
you know, it speaks
to the fact that there
is this perception out there.
I don't think that that's
true in all major cities.
And I think that it
might be hard to find.
I think that's
definitely the case.
But I also think that there is--
I've seen enough of two-person,
three-person design studios
that are looking for
their first developer.
And you know what they'll do?
They'll take somebody who
can write HTML and CSS,
at a good price, over trying
to poach a Silicon Valley
engineer for $250,000 a year.
So I think that they
may be hard to find,
because maybe they don't
publicize as well as, you
know, Facebook's recruiting
group or something like that.
But I think that, you
know, they're in there.
They're buried, you know.
They're not at the surface,
because the Amazons
and the Microsofts
and the Googles,
they have a lot of press
power and, you know,
for good reason, a lot of them.
So I think it's just
a bit harder to find.
But I do think that
they're out there.
I've seen them out there.
Yeah, and, again, that comes
back to what Dan was saying.
What kind of-- where
do you want to work?
Right.
If you're OK with
working at a small firm,
then that skill set is OK.
But if you're
really dead set on,
I want to work-- you know,
I want the golden handcuffs
of a large organization
with the great benefits,
then you're going to have
to come up to whatever level
they're looking for.
And, unfortunately, I
think a lot of businesses,
a lot of tech businesses,
much like we ourselves,
have sold ourselves on
a why that we, you know,
you have to always know
the latest and greatest.
And in the programming
world, to some degree,
that makes sense, right?
If you're learning PHP2, like,
why are you learning that.
Nobody-- we're on PHP5 now.
Or, you know--
Yeah.
I'm, you know, see your
ruby, or whatever it is.
Right, like, learning the
version of the language
two major versions
ago makes no sense,
because the code
that you learned
might not even,
like, work today.
Right.
So, therefore, you must know
the latest and greatest.
But, again, you know, we're
talking about a medium
where the first web page
that was ever made, right,
Tim Berners-Lee's literal
first web page still
renders perfectly fine
in current browsers.
And, for that matter, is
responsive, by nature.
Right.
Not in the like media query
way, but it completely flexes.
And this is a medium where
there's much more value
placed on backwards
compatibility
than on latest and greatest.
But a lot of these
requirements come
from people who work in a world
where latest and greatest is
all that matters.
Yeah, exactly.
That's a great point.
Yeah, and I think
that, because--
yeah, there is this
notion that, again,
that just because the web
is constantly evolving,
which it is, I mean, there's
no doubt that this is the case,
but it's-- you know, you
can't throw the baby out with
the bathwater, right?
So there's-- there's important--
important fundamental
concepts that haven't changed,
that will always
remain the same.
And accessibility
is one of them.
Performance is
another one of those.
So, we're almost
at the end of this.
Let me just see--
these kind of last
questions here.
OK.
So-- yeah-- so one of the
last questions we have here
is, again, there's an
emphasis on computer science
fundamentals that a lot of
organizations are looking for,
do you see a lack of
HTML and CSS skills
in companies that emphasize
hiring full stack developers?
Well, it's hard to kind of--
yeah-- Eric, what do you
think about that one?
That's an interesting question.
I'm not sure about that.
What do you think, Dan?
That is a tough one.
I remember, the way I grew
up on learning HTML and CSS--
and this goes a little bit
back to your question, Jeremy,
about standardization--
I think one of the
things that we can better
standardize and have better
interviews and things like that
is to open source and to block.
I learned a lot that way.
And I remember reading
blogs, and reading books,
and reading, and just seeing
how people are doing things.
And I remember
launching web sites,
and people commenting on my
blog, on the blog post-launch,
hey, I wonder why you use an
H1 there instead of an H2,
having full discussions
in the comment threads
about that stuff.
And I don't see that
happening as much.
And I get why, the
internet is flooded
with much more of that stuff,
and comment threads are tough.
But I think that we've lost
those kinds of discussions.
You know, now
everything's an empty div.
And--
You are right.
And, yeah-- I think an
answer to the question
is, to a large degree, yes,
companies that are, like,
hyper-focused on must have
full stacked developer,
are really thinking JavaScript.
And we'll do it-- we'll do
the front end in a framework,
right?
And like Dan says,
everything ends up
being an empty div, and--
or even worse, an empty div that
literally has all of the CSS
meant just for that div
attached to that div,
and like trying to ignore
the fact that CSS starts
with the word cascade, which is
what a lot of these frameworks
do.
Yes.
And-- and so they--
right, because they're
so focused on that work
in that framework,
and doing that,
yeah, they don't value HTML and
CSS as much as probably they
should.
And what's interesting
is that some of those
framework developers--
I'm not going to
name names here--
but I've heard that one of the
frameworks where they like took
all the CSS and inlined it--
and that was the
whole point, right,
like, they did that on purpose.
The people who did
that have since
realized that there are reasons
they shouldn't have done that.
And they kind of
wish they hadn't,
right, because
eventually you start
to realize there are reasons
that the technology is
the way that it is.
And when you try to
hack your way around it,
you often end up falling
prey to the problems
that those technologies
had already solved.
Just to play the other
side a little bit.
I think that part of
the responsibility
falls on the developer to prove
the value of HTML and CSS,
right?
Because what we often
hear is people, you know,
the rallying cry is
progressive enhancement,
progressive enhancement.
And people don't
know what that means.
And what they actually
should be crying,
which is the same argument, but
just a different spin on it,
is more people can
use our website.
You know, that's what
progressive enhancement means.
Yeah.
But we often think of
progressive enhancement, right,
as a means to an end, as the
end, not a means to an end.
And I think that
that's on us to solve.
We have to change
our rhetoric in order
to get people to listen to it
in the way that we want them to.
So I think that, certainly,
like, the industry
is traveling that way,
but we're not helping.
So I think that one
way that we can help
is to say, like, how do we
speak the language of the people
that this is important to?
Accessibility is a
vague rallying cry.
But more people using
our web site, more people
being able to access our
content, that's way more--
that resonates more.
So I feel like we
have-- you know,
we can take that on as
part of what we can do,
is to say, here's why
HTML and CSS is valuable,
not just on its own, but because
it gives us these benefits.
Nice.
Nice wrap-up.
I could not have said
it better myself.
Well, we, believe it or not,
are at the end of our hour.
So, before we head off,
this is the chance--
anything that either of you are
doing in the near or short term
that you want to talk about?
Eric, I know you have your
CSS book that just came out.
An Event Apart, Denver
is coming up in December.
Anything else ?
For me, it's the 2018
Event Apart schedule,
which we announced.
And, also, I'm about to--
now that the fourth edition is
done for the Definitive Guide--
I'm actually going to now do
a fifth edition of the pocket
reference, and
update it to reflect
what's in the-- what's in the
fourth edition of the guide,
and correct some--
correct some things
that were true
when the fourth edition
of the pocket reference
came out, but are
no longer true.
I was flipping through
it the other day,
and I was, like, what
is this property?
I don't even-- what, what?
That's next on my plate.
Nice, and you get to do a
full plate, because CSS, as we
have said, is a big language.
Yes, well, that and
I'm actually going
to get in some time playing
Kerbal Space Program again.
Oh, nice, nice.
Looking forward to
seeing that orbit.
Yes.
Excellent.
And, Dan, how about you?
Anything on the horizon?
The next thing on my list
is to read the fifth edition
of the CSS Definitive Guide.
So there you go.
Well said.
That will keep you busy awhile.
Sorry.
Well, thank you, again,
gentlemen, for joining me.
This was very cool.
And thanks, everyone,
for attending.
There will be a link to
this recording sent out
to everyone who registered.
Even if you didn't
register, we'll
be making the link
available for free online.
You can check out--
we do have a site on YouTube,
or channel on YouTube,
I should say, where
you can see this stuff.
So a lot of our past
webinars are up there.
So, feel free to look
for Aquent Gymnasium
where this webinar will
end up, eventually.
Having said that, I
bid everyone adieu.
And, again, thanks a lot.
And thank you,
gentlemen, once again.
Thank you.
Take care.
Bye bye.
