►
Description
If you build it, they will come -- but only if they know how. Building a robust developer experience represents a deciding factor in the success of any organization aiming to increase the use of its products and services among developers. This Kong Summit 2019 panel of leading developers and developer evangelists as they discussed strategies and tactics for creating a developer experience that boosts engagement, increases satisfaction and inspires innovation.
Stephanie Kalacis | Tien Mimi Nguyen | Adam Zimman | Erin McKean | Greg Schier
Learn more about Kong: https://konghq.com/
A
Hello,
everyone
day,
two
of
Kong's
summit,
so
today
we're
here
to
talk
about
developer
experience
as
Chuck
sort
of
mentioned.
Our
users
of
products
and
services
are
really
the
core
of
everything
that
we
do
and
ensuring
they
have.
A
positive
experience
is
really
integral
to
the
success
of
any
organization.
So,
as
mentioned
I'm
UX
designer
here
at
Kong,
anything
experience
design
is
very
near
and
dear
to
my
heart.
So
we
have
some
really
excellent
panelists
today
to
come
and
talk
about
how
best
to
empower
our
users.
A
A
B
C
A
C
For
me,
I
am
constantly
looking
at
open
source
projects
and
wondering
where
I'm
gonna
give.
You
know
my
free
work,
I'm
in
a
volunteer,
and
the
first
thing
I
always
look
at
is
the
code
of
conduct
cuz
for
me
as
a
developer.
I'm
like
I'm
gonna
help
you
out,
but
I
need
to
know
that
you're
gonna
make
sure
I'm,
comfortable
and
safe,
so
I
think
baseline.
A
E
D
B
And
they
generally
have
excellent
docs,
but
I
couldn't
find
the
answer
to
my
question
in
their
Docs.
So
I
hit
up
their
chat,
and
this
was
like
a
Sunday
afternoon
and
I
didn't
get
my
answer
right
away,
but
what
I
did
get?
What,
which
was
amazing
for
my
experience,
was
straight-up
validation
that
the
question
I
had
was
not
in
the
docs
and
just
like
letting
developers
know
and
not
giving
them
the
runaround
when
they
find
a
problem.
E
Exactly
I
think
that
you
know,
from
my
perspective,
some
of
the
best
experiences
that
I've
had
as
a
developer
are,
along
the
same
lines
its.
How
am
I
you
know,
engaged
as
an
individual
both
by
the
product
by
the
documentation,
by
that
kind
of
you
know,
overall,
like
engagement
from
initial
awareness,
all
the
way
through
to
use
of
the
technology,
to
make
sure
that,
if
I
have
any
challenges,
there's
a
very
obvious
way
for
me
to
get
assistance
and
when
I'm
using
it,
it
feels
organ
mcclee,
thoughtful
right.
A
A
A
C
Sure
so
kind
of
like
what
everyone
was
saying
earlier,
I
am
often
advocating
for
beginners
or
people
who
just
haven't
even
really
thought
about
our
project
before
and
it's
funny
because
most
of
the
people
who
helped
me
with
writing
the
documentation
are
engineers,
and
so
there's
a
lot
of
assumed
knowledge
or
just
like
kind
of
almost
forgetting
what
it's
like
to
be
a
beginner.
So
most
of
my
time
is
saying
things
like
listen.
C
I
know
how
to
make
your
job
easier,
and
it's
if
you
help
me
help
the
people
that
you're
kind
of
forgetting
right
now
and
so
far
it's
been
great,
like
I.
Think
in
general,
everybody
wants
to
bring
in
more
people
to
read
the
documentation
and
consume
the
documentation,
but
just
like
any
startup
being
a
department
of
one
has.
B
That's
a
really
excellent
point,
because
the
absence
of
beginner
information
shuts
out
beginners,
the
presence
of
beginner
information,
does
not
dissuade
advanced
people.
Nobody
ever
looks
at
a
recipe
and
says:
oh,
my
goodness,
you're
gonna
tell
me
how
to
separate
an
egg
white
and
egg
yolk.
This
is
garbage
right
and
moves
on,
like
you
have
to
start
where
people
are
I
like.
D
To
I
there's
a
term
progressive
enhancement
which
I
think
I
really
love,
and
it
reminds
me
of
that
because
yeah
you
provide
people
with
the
basics
and
the
people
who
want
to
be
more
advanced
can
do
that
on
their
own.
Almost
but
yeah.
Providing
that
beginning.
Our
experience
is
really
crucial
and
so
for
I.
Think
for
open-source.
A
Comments
or
sad
truth
is
important,
god
that
you
brought
up
open
source,
of
course,
very
important,
building
a
community,
it's
very
core
to
the
success
of
any
sort
of
open
source
product.
Adam
I
would
love
to
hear
from
you
if
you
have
any
tips
or
learnings
on
building
a
diverse
and
inclusive
community,
absolutely.
E
I
think
this
is
something
that
is
especially
valuable
and
open
source,
but
extends
to
you
know
other
software
communities
as
well.
Is
you
really
need
to
think
has
the
individual
or
group
that
is
managing
the
community
about
how
you
can
be
extraordinarily
open
to
any
and
all
comments
that
are
coming
in,
especially
those
that
are
asking
questions?
You
know
if
you
approach
it
from
the
perspective
of
telling
people
to
go
away
because
they
don't
have
context
when
they
come.
E
You
know
to
you
or
you
feel,
like
you
are
getting
a
question
that
is
so
obvious
to
you
that
it
is
already
answered
it.
It's
already
part
of
your
program
and
you
kind
of
retort
or
respond
with
that
kind
of
flippant
remark.
Not
only
are
you
going
to
limit,
you
know
the
participation,
because
those
individuals
will
most
likely
go
someplace
else
or
do
something
else
with
their
time,
if
they're
not
feeling
welcomed,
but
also
what
I've
found,
especially
thinking
about
things
from
a
product
perspective,
or
you
know,
from
a
project
perspective
and
open-source.
E
Is
that
oftentimes,
when
someone's
asking
a
question
that
may
already
be
part
of
your
existing
project
or
platform,
there's
something
else
there
right,
and
so,
if
you
actually
respond
with
a
little
bit
more
probing,
you
know
an
understanding
of
what
are
you
trying
to
do?
You
know
like
what
is
it
that
you're
trying
to
you
know
understand
a
little
bit
better?
E
It
gives
you
the
opportunity
to
potentially
look
at
a
new
use
case
that,
maybe
somebody
is
you
know,
coming
from
a
different
starting
point
than
your
existing
community
and
that's
how
you
look
at
building
and
expanding
out
right
if
you
initially,
your
response
is
to
close
off
and
say:
go
away.
I
don't
want
to
you
know:
you're
you're,
not
smart
enough
to
be
a
developer
on
my
project.
Then
you're
gonna
have
a
really
hard
time
actually
expanding
that
community
and
making
your
overall
project
or
program
successful.
A
And
that's
sort
of
ties
in
a
bit
too.
You
know
one
of
the
major
UX
principles
is
you
are
not
your
user
and
getting
down
to
the
how
before
what,
before
jumping
straight
to
a
solution,
and
one
of
the
ways
of
doing
that
is
jobs
to
be
done?
You
mentioned
that
Aaron
a
little
bit.
I
would
love
to
hear
your
experience
with
that.
That's
something
that
we've
been
looking
to
try
and
get
a
bit
more
into
I
I.
B
Love
the
jobs
to
be
done,
framework
and
I'm
completely
blanking
on
the
name
of
the
person
who
came
up
with
it.
So
you
all
have
to
promise
me
you're
gonna,
go!
Look
it
up
immediately
after
so
thread
that
can
go
where
credit
is
due,
but
it's
kind
of
like
people
don't
come
like
people,
don't
necessarily
want
a
car.
They
want
to
get
from
point
A
to
point
B.
The
job
to
be
done
is
not
I
need
to
own
a
car.
B
The
job
to
be
done
is
I
need
transportation,
and
so
we
can
see
like
recently,
a
lot
of
people
have
said
decided,
I,
don't
need
to
own
a
car
because
other
things
get
the
job
done,
and
so
sometimes
when
people
come
to
your
product
or
your
project,
you
know
you
think
that
they
need
this
thing.
Nobody
ever
needs
the
thing
they
need
to
do
something,
and
it
can
be
really
hard
when
you've
invested
a
lot
of
time
and
like
building
a
thing
to
reframe
it
as
but.
D
A
D
D
I'll
I'll
like
follow
up
and
say
like
thanks
for
answering
that
that's
really
good
and
maybe
add
a
few
more
details
that
were
missed,
mm-hmm
just
to
help
open
that
up,
but
I
think
in
general,
the
community,
if
you
do,
if
you
got
it
in
the
right
direction,
the
community
can
sort
of
filter
on
its
own
almost
and
the
bigger
issues
will
bubble
up
to
the
top
right.
A
B
Think
curiosity
is
like
the
developer
experience.
Superpower
right,
if
you
can
just
keep
in
that,
tell
me
more
tell
me
more
mindset
without
jumping
into
I'm
gonna
solve
your
problem
for
you.
Then
you
eventually
get
to
the
point
where
either
they're
probably
miss
solved,
or
everyone
involved
realizes
that
you
know
they're
trying
to
drive
a
nail
in
with
a
screwdriver,
and
you
can
send
them
to
your
friends
over
at
hammer
project,
but
just
if
you're
not
curious
about
what
people
are
doing
with
what
you've
built.
E
C
I
feel,
like
often
those
questions
are
already
answered
to
in
the
workplace,
like
I
love,
the
support
team
that
I
work
with,
and
they
are
literally
the
front
line
for
documentation
like
people
like
to
look
at
me
as
the
expert
and
I'm
like
that's
great,
and
it
makes
me
feel
really
good.
But
actually
people
who
know
how
our
customers
are
interacting
with
our
documentation
are
the
support
and
they
know
the
questions
that
our
customers
are
asking
on
a
regular
basis,
which
are
the
problems
we
need
to
be
solving
so
like.
C
A
E
That's
how
your
product
is
going
to
get
better
is
when
you
start
to
solicit.
You
know:
feedback
from
individuals
that
are
using
it
differently
and
bringing
new
things
to
the
table.
Otherwise,
you
end
up
with
just
the
hammer
project,
and
it's
really
good
at
you
know,
hitting
nails
but
doesn't
do
much
else.
No.
E
A
C
B
To
you
with
a
problem
they're,
giving
you
their
trust
that
they
think
that
you
can
make
it
better,
and
even
when
my
reply
is
no
I'm,
sorry,
we
don't
actually
have
this
kind
of
etymological
information
at
the
granularity
that
you
would
like.
They're
like
okay,
great
thank
you
for
answering
my
question
at
least
now.
I
you
know
know,
and
the
thing
is,
is
that
it's
never
the
users
fault
whatever
question
they
have
no
matter
how
obvious
you
think
it
is.
You
know
you
didn't,
make
it
clear
in
your
documentation.
B
You
didn't
make
it
clear
in
your
implementation.
You
didn't
make
it
clear
somewhere
and
that's
not
on
them.
That's
on
you
and
every
time
they
ask
you
a
question.
It's
an
opportunity
for
you
to
make
things
better
and
then
that
scales,
because
hopefully
the
next
person
will
find
the
answer
on
their
own,
also
I
like
to
send
people
stickers
any
time.
Somebody
brings
any
kind
of
bug
or
question
to
me.
I'm,
like
we
like
to
send
stickers
to
people.
You.
B
A
Let
me
look
at
my
notes:
everybody!
Oh
yes!
So
you
know
there
has
been
a
lot
of
conversation
about
tools
and
software's
and
and
how
we're
all
using
a
ton
of
them
and
they're
all
different.
You
Greg
have
an
incredible
tool
that
you
know,
helps
people
debug,
stuff,
I'm,
I'm,
curious
about
any
other
tools
that
you
all
might
recommend.
That
would
improve
sort
of
a
developer
experience
if
there
are
any
and
if
not
that's
totally
fine.
If
your
own
pen
and
paper
is
all
you
need,
that's
great
can.
B
D
B
B
E
That's
the
new
commercial
I
think
for
me,
the
you
know
there
are
a
lot
of
different
tools
that
I've
enjoyed
working
with
as
a
developer.
I
think
that
the
thing
that
I've
found
to
be
most
impactful
from
a
developer
engagement
perspective
personally,
as
well
as
what
we've
seen
at
launch
Darkly,
he
is
solid
documentation.
E
There
are
a
lot
of
companies
that
do
this
extraordinarily
well,
that
we
try
to
pattern
match
off.
Of
you
know.
I
think
of
stripe
is
one
that
does
this
extraordinarily
well.
Twilio
is
another
that
really
have
said.
You
know
what
we're
going
to
take.
This
idea
that
we've
all
been
talking
about
of
engaging
with
the
individual,
who
literally
has
never
done
this
before,
has
no
context
and
start
from
there
and
then
we'll
go
all
the
way
up
to
the
most
advanced
use
case
that
we've
ever
seen
and
make
it
something
that
somebody
can.
B
E
D
Actually
Twilio
I
I
was
trying
to
use
it
a
while
ago
to
hook
up
something
to
my
doorbell
and
I.
I
was
looking
at
docks
and
then
I
did
a
google
search
and
they
had
an
article
for
almost
the
exact
thing
that
I
was
trying
to
do
step
by
step
right
like
even
though
the
docks
existed
and
I
could
have
used
them.
They
went
one
step
further
and
just
showed
me
how.
B
E
B
E
Medical
yeah
sample
code,
or
you
know
public
repos
that
you,
you
know
put
up
on
github.
You
know
I'm
I
still
remember
when
you
know
documentation
was
you
know,
oh
well,
I
will
deliver
you
this.
You
know
15
volume
set
of
paper
books
that
will
just
sit
on
your
shelf
or
directly
go
into
the
recycling
bin,
and
that's
why
no
one
ever
read
them
because
it
was
really
complex
to
search.
You
were
never
gonna.
Read
them
recover
as
much
as
I.
E
You
know
have
many
friends
who
were
documentation,
writers
and
would
write
beautiful
prose
in
the
documentation
that
just
wasn't
what
people
use
them
for,
but
nowadays
you
know,
like
combination
of
Google
and
well
thought
out
and
well
structured
documentation
sites.
It's
amazing
how
useful
that
can
be
for
a
developer,
yeah.
C
E
C
B
E
E
D
E
C
Kind
of
fun
to
like
I,
really
love
it.
When
grammarly
will
point
out
that
I
used
an
idiom,
you
know
and
I'm
like.
Oh
that's,
oh
it's
an
idiom
and
we
shouldn't
be
using
that,
even
though
our
Docs
are
in
English
because
our
Docs
are
actually
international
and
idioms
are
culturally
basting
or
like
one
of
the
ones
that
I
saw
in
some
documentation
not
too
long
ago
said
roll
your
own.
This
thing
right
and
I
was
like:
where
does
that
come
from?
It
comes
from
rolling
your
own
cigarettes,
but
not
all
cultures.
B
C
E
B
You
want,
you
could
say
a
dictionary.
Editor
personally
told
me
write.
Writing,
isn't
good
enough.
If
you
need
that
appeal
to
Authority
go
for
it
because
you
know,
if
something
really
isn't
clear,
people
will
let
you
know,
and
there
are
plenty
of
people
out
there
who
get
an
enormous
amount
of
personal
satisfaction
and
joy
from
telling
you
that
you've
misused
a
comma
and
you
are
bringing
such
light
into
their
lives
by
giving
them
the
opportunity
to
tell
you
that
I.
C
D
B
D
B
D
D
A
A
E
B
D
E
It
launched
darkly,
we
have
a
team
of
developer
advocates
who
are
traveling
regularly
going
to
conferences
and
they're,
not
doing
it
for
the
purpose
of
selling
more
launch
Darkly
all
right.
What
they're
doing
is
they're
trying
to
engage
and
really
have
the
primary
goal
of
gathering
feedback
from
how
the
community
is
thinking
about
some
of
the
problems
base.
Some
of
the
problems
that
we're
solving
as
well
as
you
know
how
they
feel
about
our
solution
and
other
solutions
that
are
out
there
to
be
able
to
understand
what
is
it
that
they
need.