►
Description
Gatekeeping and the DevOps Revolution - Kat Cosgrove, Independent
There are more computer science graduates than ever, and the number keeps rising. Include coding bootcamp graduates, and the number of junior engineers out there is staggering. Sounds great, right? More engineers means larger communities and more help for our projects, and the whole world benefits because we’re solving harder problems faster. That's what DevOps is about, yeah?
It’s not quite that simple. Tech is advancing quickly, becoming more and more specialized. We frequently assume that the people reading our documentation and using our tools already have context and peripheral knowledge specific to our corner of tech, and we forget about all of those junior engineers with fresh ideas who are hungry to learn but don’t understand our jargon. We don't mean to do it, but we're gatekeeping them and it's slowing our progress. In order to really accelerate DevOps adoption, WE need a cultural change, too.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
So
my
name
is
kat
cosgrove
and
I'm
a
developer
advocate.
That
is
my
cat
espresso,
who
you
might
hear
at
some
point
she
likes
to
climb
up
into
my
lap
while
I'm
talking,
but
before
I
was
a
developer
advocate.
I
was
an
embedded
linux
engineer
when
I
started.
I
was
fresh
out
of
a
coding
bootcamp
and
I
was
suddenly
thrust
into
a
very
unfamiliar
and
fast-paced
environment.
A
Where
I
needed
to
quickly
become
functional
in
quite
a
lot
of
different
tools
and
technologies
and
workflows
that
I
had
just
never
been
exposed
to
before
I
I
wasn't
a
complete
newbie.
I
had
freelance,
as
a
web
developer
for
a
couple
of
years
before
that,
but
this
was
nothing
like
building
wordpress
or
joomla
sites
for
small
businesses
anyway,
before
I
go
any
further,
if
you
would
like
to
get
a
hold
of
me
later,
that
is
easy
to
do.
You
can
find
me
on
twitter
at
dixie3flatline.
A
If
you
miss
me
or
come
up
with
a
question
later
on,
don't
hesitate
to
reach
out
so
here's
what
we
were
doing
when
I
was
on
that
team.
As
an
embedded
engineer,
we
were
building
a
proof
of
concept
trying
to
demonstrate
fast,
over-the-air
updates
for
cars,
rather
than
the
manual
updates
in
a
service
center
that
most
cars
use.
Now
you
may
be
thinking
my
tesla.
I
know
your
tesla.
However,
most
cars
can't
do
that.
A
A
A
A
A
Your
code
has
to
be
written
in
a
way,
that's
more
modular,
so
that
it's
easy
for
other
people
to
maintain.
You
should
be
merging
with
your
source
repository
and
pulling
from
main
often
sometimes
multiple
times
a
day
and
making
much
smaller
changes.
Every
time
and
unit
tests
need
to
run
with
every
single
commit,
and
that
process
needs
to
be
automated.
A
A
The
point
I'm
trying
to
make
here
is
that
an
understanding
of
devops
practices
and
tooling
is
not
the
exclusive
domain
of
people
with
the
word
devops
in
their
job
title.
It's
everyone
who
touches
either
side
of
this
equation,
or
else
it
doesn't
work.
It's
not
just
devops
engineers
or
sres,
or
release
managers.
It's
not
just
whoever
is
taking
care
of
your
infrastructure.
A
A
Some
pieces
of
devops
have
been
around
since
the
early
90s,
but
they've
changed
so
radically
that
they're
nearly
unrecognizable.
At
this
point,
our
industry
and
our
technology,
it
rapidly
evolves.
We've
got
layers
and
layers
of
abstraction
between
us
and
our
code,
and
more
and
more
teams
across
an
organization
are
expected
to
have
some
level
of
familiarity
with
these
things.
A
A
You
have
the
context
and
the
adjacent
domain
specific
knowledge
to
make
picking
up
a
new
tool
like
one
of
these
easier,
because
you
understand
the
why,
behind
it,
you've
done
without
them
and
you've
personally
experienced
the
very
specific
ways
in
which
things
were
harder
than
so.
A
high
level
definition
of
something
like
a
service
mesh
is
enough
for
you.
A
They
don't
have
that
context
and
there
are
a
lot
of
them
and
we
really
need
them.
Here's
some
numbers
to
convince
you.
I
like
numbers
in
the
u.s
about
65
000
people
graduate
from
a
degree
program
in
computer
science
each
year
and
rising
when
you
add
coding
boot
camp
grads,
you
get
around
another
23
000,
and
that
number
is
rising
much
more
rapidly
than
the
traditional
degree
program
year
over
year.
That's
almost
90
000
juniors
each
year,
it's
a
lot
of
new
talent
and
a
lot
of
new
ideas,
and
we
want
that
right.
A
A
Now
I
don't
know
what
these
new
grads
are
good
at
or
what
they
like,
but
we
mostly
agree
that
devops
is
a
full
spectrum,
all
or
nothing
thing.
If
it's
gonna
work
out
to
its
greatest
potential,
your
junior
devs
are
going
to
touch
some
of
this
stuff
at
some
point
and
it's
better
for
all
of
us
if
they
actually
understand
it,
but
we
aren't
really
making
that
easy,
whether
we
realize
it
or
not,
the
way
we're
doing
things
now
is
gatekeeping,
it's
unintentional
and
it's
not
malicious,
but
it
is
gatekeeping.
A
Let's
talk
about
that.
Gatekeeping
is
the
act
of
preventing
access
to
something
like
a
career
community
or
a
fandom
unless
specific
and
usually
unreasonable
requirements
are
first
met.
For
example,
consider
a
woman
me
perhaps
going
to
the
card
store
to
play
magic,
the
gathering
on
a
friday
night,
if
you
don't
know
what
magic
the
gathering
is.
That's,
okay,
it's
a
competitive
trading
card
game.
That's
been
popular
since
the
90s.
A
Passive
gatekeeping
accomplishes
the
same
thing.
We
keep
somebody
out
of
a
community
or
make
it
much
harder
to
get
in
by
requiring
them
to
meet
some
bizarre
standard,
but
instead
of
making
an
active
choice,
this
happens
unintentionally,
whether
it's
out
of
laziness
or
bad
culture
or
habit
or
ignorance.
A
To
illustrate
this
point,
I
present
to
you
two
pieces
of
jargon
from
things
the
majority
of
you
are
probably
not
experts
with
so
fencing
is
an
olympic
sport
with
three
different
styles.
All
of
them
have
different
rules,
foil,
epee
and
saber.
This
is
an
actual
sport.
It's
not
a
martial
art
and
it's
been
around
for
a
long
time.
Now.
You've
probably
seen
it
at
the
olympics,
regardless
of
which
weapon
you
fence.
The
definition
of
attack
is
always
the
same,
and
people
who
don't
fence
are
almost
never
able
to
define
it
correctly.
A
A
A
It
makes
sense
kind
of
even
if
you
don't
know
anything
about
fencing
the
words
go
together.
You
understand
that
it's
the
first
offensive
action,
a
fencer
takes
so
maybe
they're
like
sticking
their
arm
out
and
they're
aggressively,
threatening
their
opponent
and
they're
not
going
backwards
or
doing
any
hedging
or
making
any
defensive
motions
before.
Finally,
what
you
can
guess
at
what
a
lunge
is
right,
a
lunge
is
a
lunge.
What
does
flesh
mean?
A
A
A
This
is
virtual,
so
I
can't
make
eye
contact
with
the
crowd,
but
I'm
going
to
pretend
that
a
couple
of
you
do
know
what
I'm
referring
to
and
have
indicated
that
with
a
smirk
and
a
nod.
Just
for
my
own
entertainment,
I
want
to
talk
to
the
people
who
don't
overwatch
is
a
first-person
shooter
by
blizzard
with
a
robust,
competitive
professional
scene
in
overwatch.
A
However,
it
actually
refers
to
the
name
of
a
team
by
the
same
name
who
first
popularized
that
composition
and
made
a
run
through
the
bracket
of
overwatch
contenders,
blizzard's
semi-professional
league.
It
was
unstoppable
at
the
time,
and
so
the
composition
was
named
after
the
team.
Now
this
is
not
user
friendly.
This
has
layers
it's
jargon.
Onion,
unlike
the
example
from
fencing,
goats
gives
you
zero
indication
of
what
it
could
possibly
mean.
A
So,
when
blizzard
wanted
to
expand
viewership
of
overwatch
league
to
a
more
casual
audience
through
streaming,
partnerships
with
espn
and
disney,
they
had
to
do
away
with
the
term.
Goats
shoutcasters
for
the
matches
were
instructed
to
call
the
composition
3-3
instead,
because
it
means
what
it
says:
three
tanks
and
three
healers,
rather
than
viewers
needing
a
whole
bunch
of
lore
about
semi-professional
overwatch
competitions
from
now
like
three
years
ago
to
know
what
it
means.
When
somebody
says:
hey,
let's
go
goats
now:
mainstream
esports
is
in
its
infancy.
A
The
term
was
a
barrier
for
entry
that
didn't
need
to
be
there,
so
they
got
rid
of
it.
The
same
goes
for
devops,
like
blizzard
in
the
overwatch
league.
If
we
want
people
to
use
our
tools
or
move
towards
a
more
devops
way
of
doing
things
at
their
companies,
we
have
to
make
it
involve
fewer
hurdles
just
using
more
descriptive
words
or
going
out
of
our
way
a
little
to
clearly
define
the
domain.
A
This
is
especially
true
when
it
comes
to
your
technical
documentation.
Have
a
quick
start
guide
that
quick
start
guide
should
be
written
as
if
it's
directed
at
someone
with
zero
understanding
of
your
tool.
That
means
you
need
to
give
your
reader
the.
Why,
for
each
thing,
don't
just
tell
me
that
your
product
facilitates
service
to
service
communications
between
microservices,
usually
using
a
sidecar
proxy.
Tell
me
why
that's
useful
in
practical
terms.
A
What
problem
specifically?
Are
you
solving?
I
know
this
seems
really
obvious,
but
a
lot
of
people
are
still
making
this
mistake.
Linker
d
is
particularly
good
at
this.
Actually,
their
docs
include
links
out
to
explanations
of
relevant
concepts
and
terms.
There's
a
step-by-step
guide
and
every
single
command
you
run
is
explained
in
painstaking
detail.
A
Easy
can
be
a
very
alienating
term
if
you
use
that
word
in
your
technical
documentation,
you
need
to
be
damn
sure
that
it's
really
actually
easy,
not
just
easy
for
you,
and
it
almost
certainly
isn't.
If
this
new
talent
we
want
to
be
using
our
stuff,
doesn't
find
it
easy.
When
your
docs
repeatedly
say
it
is
they're
going
to
be
discouraged,
and
I
don't
need
to
be
struggling
with
imposter
syndrome
more
than
I
already
do.
A
A
So
you
can
google
every
third
word
in
a
tutorial
that
was
supposed
to
be
for
beginners
only
to
get
seven
steps
into
it
and
find
out
that
you
also
need
to
have
a
functional
understanding
of
three
different
aws
services
to
follow
the
rest
of
the
now.
Not
so
quick
start
guide
considered
normal
and
acceptable
that
sucks,
it's
not
fun,
it's
a
waste
of
time,
it's
a
waste
of
resources
and
we
can
fix
it
until
devops
trade,
schools
and
boot
camps
become
a
thing
or
until
universities
start
teaching
these
technologies
too,
which
will
take
longer.
A
I
think
we
have
to
take
teaching
this
stuff
into
our
own
hands,
those
90
000
new
grads
a
year.
They
need
our
help
so
that
we
can
take
advantage
of
their
energy
and
their
insight.
Some
people
already
have.
There
are
some
great
books
out
there
workshops
and
a
ton
of
content
creators
writing
on
sites
like
dev.2
for
products
they
don't
even
own.
I
do
this
a
lot
just
because
I
remember
how
frustrating
it
was
to
learn
myself.
A
It's
ubiquitous
to
us,
but
not
everyone
knows
what
the
hell
ansible
is
proactively
teach
them
the
way
they
want
to
be
taught
not
the
way
you
learned
make
it
a
junior
on
another
team
at
your
company,
a
new
grad
from
a
local
college
or
somebody
from
a
boot
camp.
Some
random
person
you
found
on
twitter,
whatever
seniors
and
team,
leads
I'm
especially
talking
to
you
here.
If
you
let
your
junior
teammates
struggle
longer
than
necessary,
not
only
are
you
being
kind
of
a
crappy
teammate
you're,
actively
detrimental
to
your
organization?
A
A
Excellence
and
on
hiring
hiring
managers-
this
is
on
y'all
as
well.
You
are
not
going
to
get
a
junior
devops
engineer
with
five
years
of
experience
with
kubernetes
aco,
artifactory,
golang,
helm,
jenkins,
prometheus,
core
dns,
hyper-v,
pearl
network
administration
and
azure,
all
of
it
no
specific
service
listed.
First
of
all,
that's
a
senior
engineer.
Second,
it's
probably
more
than
one
senior
engineer.
A
You
might
think
I'm
exaggerating
here
and
I
am
but
barely
I
combed
through
a
bunch
of
job
postings
when
I
was
originally
writing
this
talk
and
some
of
the
requirements
were
absolutely
wild
for
a
junior
title.
This
is
a
screenshot
of
an
actual
job
listing
with
a
title
of
junior
devops,
engineer
junior.
A
This
was
in
the
first
page
of
results
on
indeed
for
the
seattle
area,
I
did
not
have
to
look
hard
to
find
an
example
for
this
slide,
which
is
upsetting
right
reading.
All
of
these,
I
wonder
if
anyone
actually
knows
what
it
means
to
be
a
junior,
I
wouldn't
qualify
for
this
lots
of
people.
You
look
up
to
wouldn't
qualify
for
this.
The
difference
is
that
we
know
it's
absurd,
but
remember
we
have
context,
imagine
how
this
looks
to
an
actual
junior.
A
A
This
is
awful
and
it's
discouraging
and
you're
pushing
away
good
people
with
a
drive
to
learn
who
could
be
an
asset
to
your
organization,
because
your
expectations
are
unrealistic
or
you
had
somebody
who
doesn't
know
anything
about
this
actual
job
right.
This
requirement,
inexperienced
people
are
going
to
look
at
this
and
think
wow,
I'm
not
even
qualified
for
a
junior
position
in
this
industry.
A
Consider,
instead,
that
the
landscape
for
devops
and
for
cloud
native
is
so
outrageously
large
at
this
point
that
unless
your
job
requirements
are
very
narrow,
anyone
you
hire
is
going
to
have
to
learn
some
new
tooling
on
the
job.
I
know
you
can't
really
see
what's
going
on
in
this
slide,
and
that
helps
illustrate
my
point.
A
The
experts
we're
more
likely
to
try
new
things.
First,
each
of
the
things
I've
talked
about
here,
the
rampant
use
of
jargon,
documentation
written
like
the
user's
already
an
expert,
a
lack
of
mentorship
and
unrealistic
hiring
expectations
is
preventing
us
from
getting
access
to
the
90
000
exceptional
new
talents
available
to
us
each
year
and
from
making
the
best
of
the
people
we
already
have
individually.
A
These
things
are
barriers
together,
they're
catastrophic.
This
is
a
cultural
problem
within
devops
that
absolutely
needs
to
be
addressed.
If
we
want
to
live
up
to
our
goals
of
delivering
better
software
faster,
we
can't
claim
to
be
a
culture
of
collaboration,
caring
and
cooperation
if
we're
excluding
anyone
or
forcing
them
to
jump
through
a
bunch
of
hoops
to
participate,
devops
exists
so
that
we
don't
have
to
suffer
through
the
same
problems
with
writing
and
delivering
software
that
we
did
before
every
new
tool.
Technique
and
strategy
exists
to
solve
a
pain
point.
A
A
Thank
you
for
coming
to
my
session.
I
would
also
like
to
thank
the
organizers
for
having
me
and
all
the
sponsors
that
helped
this
event
happen,
you're
all
so
sweet.
I
will
be
around
to
answer
questions
for
a
get
bit,
but
again
you
can
always
get
a
hold
of
me
on
twitter
at
dixie3.
Flatline,
bye,
hello,
everybody
thanks
for
coming.
A
A
A
A
A
Yes,
they
also
definitely
may
be
more
familiar
with
new
tech
and
new
tools.
We
we
do
kind
of
get
stuck
in
our
ways.
That's
that's
totally
a
thing
we
do.
We
get
stuck
on
our
ways
and
we
use
a
tool
longer
than
its
actual
relevance,
because
it's
what
we're
comfortable
with
it's,
what
we're
used
to
and
it
takes
less
effort
to
spin
it
up
or
plug
it
in
or
integrate
it
or
whatever,
but
somebody
who's
like
brand
new
may
have
experience
with
something
that's
way
better
suited
to
whatever
you're
trying
to
do.
A
With
documentation
writing
other
than
mixing
easy,
a
lot
of
it
is
like
making
sure
that
you
give
like
like
practical
examples
for
me
and
for
a
lot
of
the
juniors
I
work
with
through
boot
camps,
a
hello
world
application
needs
to
actually
do
something
like
I.
I
know
that
it
takes
more
effort
to
put
together
a
sample
application
or
pipeline
or
whatever
that
actually
does
something.
A
But
it's
much
harder
to
adapt
like
a
quick
start
guides
starter
code
to
your
actual
project
when
all
it
does
is
like
it
has
one
endpoint
that
prints
hello
world
or
it's
a
pipeline.
That
has
only
one
step,
and
it
says
hi.
This
is
your
pipeline
like
it
needs
to
actually
do
something
so
that
they
can
start
the
quick
start
like
run
the
demo
and
then
kind
of
pick
it
up
and
move
it
into
their
side
project
or
whatever,
and
make
it
actually
useful
to
them
in
their
own
code
base
and
then
extend
it.
A
It's
that's.
That's
helpful.
The
hello
world
thing.
That's
only
really
helpful
for
people
who
already
kind
of
know
what
they're
doing,
who
already
kind
of
know,
how
to
extend
whatever
your
tool
is
or
make
it
do
more
than
just
say
hi
to
you.
You
know
that
is
a
that
is
a
big
one,
for
me
is
actual
practical
examples
in
your
documentation.
A
A
I
don't
find
them
helpful
at
all
as
a
learning
tool,
but
that's
that's
me
personally,
so
I
think
that
often
comes
down
to
like
a
generational
thing,
whether
or
not
you
prefer
like
youtube
learning
content
versus
like
text
based
hands-on
written
type
thing
see.
Is
there
anything
in
the
q
a
trying
to
bounce
back
and
forth
here?
A
Okay,
so
my
session
is
ending
in
one
minute.
Thank
you,
everyone
for
coming
and
thank
you
for
the
questions.
If
you
have
more
that
I
couldn't
get
to
you
can
dm
me
on
twitter
at
dixie3flatline,
I
usually
respond
within
a
day
or
two.
I
get
a
lot
of
twitter
dms
and
twitter's
not
great
at
organizing
dms,
but
thank
you
again.
Thanks
to
the
organizers,
bye.