►
From YouTube: Keynote: What it Takes to Achieve Production Exce... Charity Majors, James Governor, & Tracy Miranda
Description
Keynote Session: What it Takes to Achieve Production Excellence: A Fireside Chat - Charity Majors, Honeycomb.io & James Governor, RedMonk; Moderated by Tracy Miranda, The Linux Foundation
Many teams are burned out from spending too much time debugging and fixing production issues instead of shipping new features—and they risk falling behind competitors that ship faster and manage production better. James Governor (Redmonk co-founder) and Charity Majors (Honeycomb CTO and co-founder) will discuss what it takes to achieve production excellence and the best practices that lead to:
Fewer production issues
Faster release cycles
Less developer frustration and burnout
Happier customers
Better business outcomes
This session will help you adopt the production excellence mindset and come away with tactics around implementing modern software practices like progressive delivery, observability, and service-level objectives (SLOs).
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Okay,
hello
and
welcome
everybody
for
this
keynote
on
what
it
takes
to
achieve
production
excellence,
and
we
have
two
amazing
folks
who
live
in
the
future
and
we're
really
thrilled
about
them
coming
here
and
sharing
how
they
see
things
shaping
out
in
the
industry.
So
please
go
ahead
and
introduce
yourself.
Let's
start
with
the
charity,.
A
Great,
thank
you
both
for
being
here,
so
I'm
gonna
start
first
with
the
continuous
delivery
foundation,
and
you
know
we
want
to
help
people
get
better
at
delivering
software
and
charity.
Lately,
you've
been
sharing
lots
of
views
on
that.
So
what
would
you
say
is
sort
of
your
idealized
vision
of
cinc?
That
team
should
aspire
to.
B
Whenever
you
write
some
code
within
a
few
minutes,
it
should
be
in
production
without
any
without
any
manual
stuff.
Without
any
you
know
gates
without
any
you
know,
without
a
long
period
of
time
it
should
be,
it
should
be,
you
know,
bundled
up,
you
have
a
single
artifact
per
per
developers,
you
know,
merge
set
and
it
just
automatically
goes
live
so
that
you
can
basically
keep
one
open
one
window
open
with
your
ide
right
as
you're
writing
a
code
and
another
window
open
with
your
observability
tool
and
you're
instrumenting.
B
If
you
write
your
code
with
with
the
eye
to
your
future
self,
how
am
I
gonna
know
if
this
is
working
or
not
right
and
then
you
merge,
it
gets
it
gets
published,
and
then
you
look
at
it
and
you
and
you
and
you
ask,
is
it
doing
what
I
expected
it
to
do?
Does
anything
else?
Look
weird
and
then
you
go
along
with
your
day.
A
B
I
think
that
you
know
there
are
some
industries
where
this
is.
This
is
made
more
difficult
than
others,
but
I
don't
think
that
should
be
used
as
an
excuse
not
to
try.
I
think
that
it
should
be
used.
As
you
know
this,
this
is
the
ideal.
Now,
if
you
have
you
know
regulatory
things
or
or
if
you
have,
you
know,
if
you're
a
mobile
developer
and
you
can't
just
publish
automatically
to
apple's
itunes,
you
know
every
few
minutes
look
for
ways
you
can
approximate
it.
B
You
know
if
you
have
like
an
internal
version
of
your
of
your
itunes,
app
that
you
can
just
publish
to
automatically
so
that
your
internal
users
are
using
it
automatically
or
if
you
have
you
know
whatever
it
is.
The
the
key
is
to
get
real
users
using
it
in
as
short
as
a
time
as
possible,
and
I
didn't
mention
code
review
in
there
code
review
is
absolutely
important,
but
in
my
mind
that
that
counts.
That's
outside
of
that
loop
right.
B
You
have
the
you,
have
the
code
view
conversation
you
go
back
and
forth
and
then,
as
soon
as
you're
ready
to
merge.
That's
when
the
timer
starts
and
it
should
be
like
15
minutes
or
less,
and
the
reason
for
this
is
that
if
it
gets
to
be
like
you
know,
an
hour
or
two
or
more
you're,
gonna
start
munching
together,
multiple
developers,
changes
and
shipping
them
in
a
single
artifact
right
and
as
soon
as
you've
done
that
you
have
decoupled
you've
like
blown
apart,
the
entire
software
ownership
ideal.
B
You
know,
if
you
know
your
code
is
going
to
be
live
within
10
or
15
minutes.
You're
going
to
look
at
it.
It's
going
to
be
muscle
memory
right,
it's
reasonable
to
ask
developers
to
do
with
that.
If
you
know
that
your
code
is
going
to
be
probably
live
at
some
point
in
the
next
six
to
24
hours,
along
with
you
know,
one
to
ten
other
developers,
you're,
never
gonna
go
look
at
it
like.
Why
would
you
like
it's?
It's
it's
you
know
it's.
A
B
See
so
a
lot
of
people
talk
about
this
like
it's,
it's
like
this
impossible
idea,
like
it's
only
the
best
of
the
best
who
can
do
this
when
actually
this
is
the
easy
way
to
write
code
right
is
when
you
can
see
what's
happening
and
when
you've
just
written
it,
you
know
what
you're
trying
to
do.
You
know
what
trade-offs
you
made.
You
know
know
what
the
variables
are
named.
It
gets
harder
and
harder
the
longer
that
interval
is
and
it
gets
harder
and
harder.
The
more
changes
you're
bunching
up
at
once.
B
C
Yeah
I
mean,
I
think
part
of
the
issues
is
that
there
are
a
set
of
associated
disciplines
in
order
to
be
able
to
do
this
stuff.
So
you
know
you
don't
you're,
not
an
organization
that
you
know
on
friday
is
afraid
to
ship
anything
before
the
weekend
and
then
on
monday
you're,
an
organization
that
is
going
to
be
like.
Oh
now,
we're
ready
and
in
fact
we
are
going
to
ship
this
friday,
the
the
the
the
the
set
of
of
things
that
you
need
to
do,
and
I
think
this
gets.
C
C
You
know
if
you're
gonna
be
in
a
position
where
you
know
you're,
gonna,
you're
gonna
deploy,
look
what's
happening,
you're
in
an
environment
where
you've
got
an
amazing
test,
suite
you've
done
a
whole
range
of
different
kinds
of
tests,
and
I
think
that
that's
you
know
very
important.
Obviously,
are
you
an
organization
that
is
is
is
do
you
have
the
the
the
staff
to
do
it?
I
mean
charity
is
saying
that's
the
easy
way,
but,
of
course,
people
that
are
able
to
you
know,
build
and
manage
their
systems.
C
You
need
to
make
sure
that
they
fully
understand
the
domains
in
which
they're
working,
not
every
organization,
is
set
up
in
that
way.
So
I
think
that
there,
you
know,
even
you
know,
look
we're
talking
about
as
charities
pointing
out
you
know,
keep
the
keep
the
changes
small
and
make
make
a
lot
of
them
rather
than
you
know.
C
We
certainly,
as
an
industry
historically
have
have
been
making
rather
larger
changes
and
having
a
culture
where
you
you
you've
understood
the
value
of
of
breaking
things
up
into
small
pieces
and
those
workflows.
These
are
a
lot
of
different
things
that
need
to
be
done
and
a
lot
of
organizations
aren't
ready
there.
I
mean
automation,
you
know
how
strong
is
it?
How
strong
is
your?
C
There
are
people
still
out
there
doing.
Manual
builds
so
clearly
for
them.
This
is
probably
not
the
first
step
they
make,
but
so
they're
a
lot
you
know
is,
is
you
is
your
route
in
through
automation?
You
know,
is
it
through
rethinking
you
know
how
you're
going
to
observe.
Look
at
the
systems
you
know
are,
we,
you
know,
are
we
frankly
doing
agile
development?
C
B
Yeah,
this
is
where,
when
we
were
coming
up
with
the
observability
maturity
model
like
this,
which
is
kind
of
it's
a
little
bit,
unlike
other
maturity
models
that
I've
read
and-
and
we
tried
to
focus
in
on-
you
know,
you
should
be
able
to
recognize
yourself
and
the
pathologies
that
you're
dealing
with
right
is.
It
is
lack
of
tests.
Is
it
you
know,
lack
of
instrumentation
is
it.
B
You
know
you
should
be
able
to
recognize
yourself
and
then
start
with
that
right
start
with
that,
and
then
you
know
address
it
in
the
ways
that
we're
like
we
tried
to
lay
out
which
steps
that
you
need
to
get
better
at
each
in
each
in
each
case.
So
it's
kind
of
like
a
choose
your
own
adventure
of
like
how
is
my
organization
broken
that
way?
Let's
start
there
right,
and
you
know
james
is
absolutely
right.
B
You
can't
just
like
jump
to
the
end,
although
in
some
ways
you
kind
of
can
in
that
you
know
when
you're
starting
out
fresh,
that's
the
best
time
to
just
start.
You
know
build
your
ci
cd
pipeline
and
have
auto
deploy,
because
if
you
grow
up
that
way,
you
don't
have
to
go
over
that
huge
hump
of
like
digging
yourself
out
of
all
that
technical
debt.
To
achieve
that,
you
know
if
everybody
grows
up
with
those
assumptions,
it's
a
lot
easier.
So.
C
It's
like
it's
like
the
tree
thing.
You
know
the
best
time
to
plant
a
tree
was
20
years
ago.
The
second
best
part
is
right
now
yeah,
so
yeah
I
mean
I.
I
can
definitely
see
that
and
of
course
there
are
different
teams
working
on
different
things,
so
you
might
have
one
team.
You
know
you've
got
banks,
they
got.
You
know
like
400
million
lives
of
java
code,
and
they
don't
know
you
know
the
logs
suck,
and
you
know
it's
it's.
It's
really.
C
So-
and
I
think
that's
one
of
the
things
in
the
when
we
think
about
maturity
and
you're,
like
you
know,
ten
percent
of
folks
say
they're
doing
this.
One
of
the
questions
I'm
always
interested
in
is
almost
any
large
company
that
I
talk
to
has
pockets
where
they
are
able
to
to
your
point,
live
in
the
future
and
they're
showing
your
future
state
and-
and
very
often
that's-
that's.
C
As
I
say,
it's
been
sort
of
mobile
web
development
because
yeah
there
are,
I
think,
that's
one
of
the
other
things
I
didn't
even
mention
like
test
coverage
across
these
old
apps.
That's
a
whole
sort
of
question
in
in
its
own
right.
So
not
all
code
bases
might
be
ready
to
be
treated
like
this,
but
but
but
charity's
point
because
new
patient
build
out.
Maybe
that's
the
time
to
be
like
okay,
let's
try
and
really
establish
best
practice
here.
B
One
one
of
the
key
things
is
like
I
said
is:
is
you
know
decoupling
that
you
know
software
ownership?
You
know
you
want
to
have
ownership
over
your
changes,
another
another
change
that
goes
along
with
this
almost
in
lockstep
is
you
know,
decoupling
releases
from
deploys
making
it
so
that
you
can
deploy
constantly,
but
you
can
release
software
through
a
different
process
right
using
future.
C
C
Yeah,
it's
just
you
know,
being
able
to
to
do
a
dark
launch
to
be
able
to
look
at
a
system
in
production,
but
then
you're
not
actually
turning
it
on
for
the
user,
and
then
you
can
do
that
to
manage
cohorts.
That's
a
really
exciting
idea,
and-
and
definitely
I
mean
you
know,
charity,
you
know
well,
for
obvious
reasons-
thinks
that
observability
is
rather
important
in
in
any
of
the
things
we're
talking
about.
C
But
definitely
if
you
want
to
do
product
progressive
delivery,
you
absolutely
need
to
be
thinking
about
it
from
an
observability
first
perspective.
So
I'm
I'm
holding
you
know,
deploying
some
and
and-
and
you
know
the
bit
one
of
the
things
will
prevent
anything
from
happening
in
it.
Is
business
freaking
out
and
being
like
wait,
we're
not
comfortable
with
that,
and
so
the
idea
that
you
can
not
get
in
the
way
of
developers
and
allow
them
to
work
in
the
way
that
charity
is
talking
about.
C
B
It's
so
true,
and
you
and
you
don't
even
like
when
you,
when
you're
using
feature
flags,
you
don't
even
have
to
like
think
about
the
speed
of
your
deploy.
You
just
flip
it
on
flip
it
off
flip
it
on
flip
it
off
like
it's.
It's
a
really
great
way
to
make
your
business
partners
feel
a
lot
more
comfortable
with
all
these
somewhat
radical
changes.
C
Because
when
I
first
started
talking
about
progressive
delivery-
and
I
thought
it
would
be
like
you
know-
nerds
that
were
like-
I
can
see
that,
but
when
I
started
talking
to
cios
and
they
were
like.
Oh,
this
is
about
de-risking
yeah.
I
was.
It
was
kind
of
a
profound
moment
because
yeah,
if
you
can
yeah,
if
you
can
have
flow
and
the
business
is,
is
comfortable.
That's.
B
I
feel
like
you
know,
the
the
gravitational
center
is
moving
finally
from
pre-production.
To
actual
you
know,
production
software,
which
is
where
it
needs
to
be
all
along,
but
I
do
feel
like
like
encouraging
people
to
do
all
these
fancy
things
around
deploys
and
stuff
without
putting
equally
as
much
focus
on
observability
is
just
going
to
set
people
up
for
terror
and
failure,
because
if
you
can
deploy
a
small
change
whatever
or
deploy
a
bunch
of
stuff
dark
launch,
but
then
when
something
goes
wrong,
you
actually
have
no
idea.
B
What's
going
wrong
and
you
can't
compare
like
dip
over
diff,
you
can't
compare
like
change
over
you
can't.
You
can't
see
exactly
what
is
happening.
You
can't
even
pinpoint
like
like
in
the
traditional
metrics
world.
You
know
you
might
see
a
spike
of
errors,
but
then
you
have
to
jump
into
a
logs
world
and
try
and
visually
correlate
to
figure
out
if
it's
the
same
problems,
what
like
you
actually
need
real
observability,
where,
which
is
you
know,
comes
down
to
these
arbitrarily
wide
structured
data
blobs
spans.
B
You
know
if
it's
not
built
on
those,
it's
not
observability
for
now
and
and
and
that
that's
what
really
helps
you
put
your
glasses
on
as
you're
driving
down
the
road
and
needing
to
look
because
you
need
to
you
need
to
be
very
user
oriented
in
in
your
telemetry
right.
It's
not
enough
to
just
be
able
to
see.
If
there's
a
spike,
you
have
to
be
able
to
see
exactly
which
users
and
and
why
this
this
aerospike
is
for.
A
B
From
the
perspective
of
you
know
the
the
user
who's
eating
the
burrito
first
right,
it's
not
thinking
about
well,
we
need
to
do
progressive
delivery,
because
that's
what
you
know,
james
and
charity
say-
and
it's
cool
on
hackers
news
this
week,
but
it's
like
okay,
where
are
we
hurting
and
and
where
do
we
need
to
apply
these
these
techniques
and
tools?
Most.
B
A
C
Well,
I
think
that
the
testing
and
automation
we
sort
of
spoke
a
bit
about
that
as
as
we,
I
think
we
may
have
secretly
slid
in
this
notion
of
production
excellence
like
in
what
we
were
talking
about,
but
it
is
a
set
of
associated
disciplines
and,
frankly,
a
really
good
focus.
I
I
just
can't
sort
of
iterate
enough
on
the
idea
that
that
testing
and
and
automation,
that's
something
to
invest
heavily
in
liberating
and
and
what
the
other
thing.
I
think
that-
and
this
is
maybe
something
for
the
continuous
delivery
foundation.
C
Certainly
one
of
the
patterns
that
I'm
now
seeing
and-
and
it's
one
thing-
you
know-
charity
talks
about.
Okay,
you
know
observability,
you
know
you
need
to,
but
we
are
definitely
seeing
a
merging
of
pipelines
and
observability
and
and
the
pipeline
should
be
absolutely
something
that
you
are
instrumented
as
a
production
system,
because
you're
talking
about
it
being
the
heart
of
of
that
rubber
meeting
the
road.
C
So
I
think
that
some
of
the
really
interesting
stories
that
I've
seen
in
talking
to
leading
organizations
recently
have
been
about
that,
where
the
the
the
the
pipelines
and
observability
are
coming
together
in
in
really
interesting
ways
and
and
helping
to
make
organizations
more
effective
because
here's
the
thing
if
we
say
you
know
ten
percent
of
orgs
could
do
this.
What
if
it
was
only
five
or
whatever
it
doesn't
really
matter.
But
how
do
we?
How
do
we
get
people
to
do
things?
I
think
that
you've
got
you.
C
You've
got
to
have
great
tools
everyone's
like,
oh,
you
know
devops,
it's
it's
not
tools.
Well,
there
were
some
tools
that
pushed
us
forward
in
order
to
be
able
to
do
what
is
now
described
as
devops.
So
you
know
if,
if,
if
you
know
if
like,
if
we
think
about
you,
know
andrew
clay,
schaefer
and
patrick
coming
up
with
the
term
devops-
and
I
don't
think,
there's
any
accident
that
that
then
andrew
andrew's
going
and
building
configuration,
automation,
platforms,
right
and
so
at
any
given
time
in
tech.
C
We're,
hopefully
we're
we're
understanding
a
working
set
of
working
practices
and
building
tools
that
will
enable
us
to
to
do
those
practices
and
then
hopefully,
more
people
will
be
able
to
use
them.
So
it's
hard
to
do
observability
in
the
way
that
charity
is
advocating
if
you're
running
around
trying
to
look.
Oh,
my
god,
I'm
you
know
I'm
looking
at
this
log
management
system.
Now
now
I'm
looking
at
my
metrics-
and
you
know
my
hair
is
on
fire.
You
know
I'm
trying
to
look
at
okay
or
what
about?
C
Oh,
it's
microservices
or
distributed
traces
like
putting
everything
together
in
a
way
that
is
meaningful
to
the
practitioner
and
enables
new
ways
of
working.
I
think
that
yeah
we
get
a
bit
carried
away
with
the
idea
that
the
tools
can't
help
support
process
and
culture
change,
and
at
the
moment
I
think
we
are
seeing
some
really
interesting,
tooling,
being
provided
to
help
people
become
more
effective.
A
C
But
if
you
can
make
the
right
way
the
easy
way-
and
that
gets
to
some
of
what
charity
was
saying-
then
we're
we're,
really,
you
know
moving
forward
and
I
think
that's
that's
actually,
as
an
industry
like
I'm,
really
interested
at
the
moment
about
the
sort
of
the
the
golden
pathways.
So
how
do
you
make
the
right
thing?
The
easy
thing
so
like?
How
do
you
have
constraints
and
guidelines
so
that
the
developers
can
be
extremely
productive
and
be
in
flow,
but
also
understand
the
environment?
B
I
mean
it's,
it's
it's
it's
all
of
us
really,
but
but
I
mean
I
mean
the
way
that
I
I've,
always
I
recommend
is
I
I
have
a
blog
post
about
about.
This
is
just
that.
You
know
you.
You
pull
together,
some
of
your
senior
folks
and-
and
you
make
you
know
you
have
like
a
council
and-
and
there
has
to
be
a
way
of
you-
know
constantly
like
recommending
changes
to
the
the
the
golden
path
that
you've
defined.
There
has
to
be
a
way.
B
You
know
cycling,
people
in
and
out
of
the
council,
but
you
know
the
software
systems
are
always
in
flux
and
you
have
to
have
you
have
to
make
agreements
about
how
much
you're
willing
to
staff
right.
So
if
you're
like
okay,
our
golden
path,
is
you
know
going
ubuntu,
you
know,
containers
whatever,
etc.
Then
you
know
adding
rest
to
the
mix
requires.
You
know.
C
C
If,
if
there
is
not
because
we've
got
product
owners,
they
have
to
know
any
bit
of
infrastructure
that
supports
the
the
applications
that
they're
building
and
so
they're
like
we're
gonna
turn
stuff
off.
If
nobody
knows
what
it's
for,
like,
let's,
let's
move
to
having
more
ownership
and
and
yeah
no
there's
yeah,
I
think
anna
shipman
wrote
really
good,
really
good,
blog
post
about
that,
and
that's
an
organization
like
the
ft
that
you
know
it's
been
around
a
while.
C
But
it's
doing
a
lot
of
these
things
that
we're
talking
about
it's
a
really
sophisticated
it
organization
now
and
and
yeah.
I
think
that
that
product
ownership
is
one
of
the
other
linked
disciplines
linked
disciplines
having
a
product
rather
than
a
project
focus,
for
it
helps
you
to
become
more
effective
with
things
like
production,
excellence.
A
B
I
don't
know.
I.
I
think
that
one
anti-pattern
that
I
that
I've
seen
a
lot
of
is,
is
just
the
ctos
who
are
are
very
prone
to
believing
vendors
when
they're
like
give
us
lots
of
money
and
we'll
make
it
so
that
your
people
don't
have
to
understand.
What's
going
on,
you
know
just
like
give
me
tens
of
billions
of
dollars
and
we'll
give
you
a
dashboard
that
tells
you
what
the
problem
is.
You
know
you,
your
people
won't
have
to
you
know
and-
and
that's
just
always
going
to
be
a
lie.
B
A
C
I
think
that
yeah
no
I
mean
I
I
think
the
role
of
of
cto
is
for
grabs.
I
mean
one
of
the
interesting
things
I've
been
seeing
is
sort
of
field
ctos
get
this
get
the
cto
out
with
the
customers
and
seeing
like
dealing
with
customer
problems,
and
then
you
know
have
that
as
a
point
of
advocacy
within
the
org,
for
you
know
serving
those
those
customers
with
better
products.
C
So
so
yeah
I
mean,
I
think
the
the.
But
if,
if
you
are,
if
it's,
if
we're
talking
about
you
know,
look
you
you're
coming
at
this
from
a
somewhat
top-down
perspective.
Yeah,
I
think,
as
charity
said
it
is.
You
know,
people
matter
and
make
sure
that
you've
got
some
people
in
the
organization
that
are
empowered
to
make
the
changes
that
you've
got
them
already.
You
you
just
need
to
find
and
support
them.
C
I
think
that
adrian
coccraft
used
to
say
you
know
and
obviously
he's
one
of
the
great
sort
of
rhetoricians
in
this
industry,
in
fact,
but
he
he
would
give
as
part
of
his
talk.
He
would
say:
look
when
I
go
out
and
talk
to
yeah
like
ctos
or
whatever,
and
I'm
you
know
here.
I
am
I'm
like
you
know,
mr
microservices,
I'm
like
you
know,
netflix,
lately,
aws,
you
know
people
would
say.
Oh
how
you
know,
how
do
you
hire
those
people?
C
C
It's
not
just
a
technology
thing
like
making
sure
it's
not
about,
and
maybe
it's
about
hiring
some
new
blood
to
drive
some
change,
but
also
there
are
always
change
makers
in
any
org
that
are
just
waiting
to
like
be
unleashed
and
do
things
in
new
cool
ways
and
so
leaning
into
that
a
bit
would
be.
That
would
be
my
advice
for
everybody.
B
A
So
for
those
teams
they're
like
one
of
the
things
we
hear,
is
that
there's
just
so
much
happening
and
it
does
feel
like
we're
in
a
bit
of
a
software
delivery
renaissance,
but
at
the
same
time
we've
all
got
these
different
terms
and
people
will
hear
talks
at
cdcon
and
it
will
be
like
okay,
devops
and
agile
and
githubs
and
devsecops
and
observability
progressive
delivery
production.
Excellent.
You
know,
there's
just
so
much
to
contend
with
so.
B
B
C
Yeah
I
mean
I
can
definitely
I
couldn't
have
said
it
any
better.
I
mean
that's
how
I
see
it.
I
I
like
it.
I
I'm
not
I'm
not
like
a
I'm,
not
like
a
tech
language
comedian.
You
know,
I'm
not
I'm
not
like.
We
wrote
the
book
10
years
ago
and
everything
must
have
that
name.
You
know,
I
think
it's
it's
there's
some
fashion
in
the
industry.
C
It
is
tribal,
it's
fun!
You
know
one
hopes
that
we
like
to
learn
new
things,
yeah
describing
things
a
set
of
practices
that
you
see
is
just
a
brilliant
way
to
get
other
people
to
to
to
latch
on,
and
also
we
spoke
about
the
culture
change.
Okay,
look.
We've
still
got
a
long
way
to
go
in
any
of
these
areas,
but
without
having
a
working
language
for
that
that
excited
people
we're
not
going
to
make
the
changes.
So
I
I'm.
I
know
it
might
seem
a
bit
like.
C
Oh
my
god,
you
know
why.
Why
is
there
another
term
here,
but
I
guarantee
that
there
are
a
bunch
of
other
people
that
again
you
could
tap
into
as
a
resource
that
are
profoundly
excited
by
that
thing.
That
you're
like?
Oh
what
you
know.
Why
is
it
a
new
thing?
You
know
there
are
a
lot
of
people
doing
interesting
work
there.