►
From YouTube: Keynote Session: The SPACE of Developer Productivity: A Fireside... Tara Hernandez & Nicole Forsgren
Description
Keynote Session: The SPACE of Developer Productivity: A Fireside Chat - Tara Hernandez, Google & Nicole Forsgren, GitHub
Tara Hernandez hosts this fireside chat on developer productivity featuring Nicole Forsgren, author of Accelerate and the new SPACE framework. SPACE is an acronym for satisfaction, performance, activity, communication, and efficiency - each a dimension of measuring developer productivity. Join us for this insightful session to learn what the research tells us about how to evaluate and improve developer productivity, recognize the common myths and antipatterns to avoid, and figure out a path to enabling high developer productivity for your team no matter what shifts happen in the global workplace.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
All
right
welcome
everyone
to
cdcon.
I
am
tara,
hernandez
senior
engineering
manager
at
google
cloud,
and
I
am
incredibly
incredibly
pleased
to
be
able
to
have
this
amazing
conversation
with
nicole
foursquare
author
of
accelerate
that,
if
you
all
haven't
read
it
yet
go
read.
It
now
also
recently
the
author
of
a
new
research
paper
that
we're
about
to
start
talking
about,
and
she
is
a
partner
research
manager
at
microsoft.
Research
welcome,
nicole.
B
A
B
B
I
love
this
question
and
it's
it's
interesting
because
it's
something
that
I've
been
thinking
about
for
a
few
years
right,
so
it
and
I
love
that
you
kind
of
mentioned-
you
know,
say
devops
and
dora
and
we've
been
thinking
about
a
bunch
of
this
for
years
and
and
how
do
we
think
about
metrics?
How
do
we
think
about
measurement?
How
do
we
think
about
best
practices?
B
If
we
want
to,
you
know,
dig
up
some
of
my
old
talks.
I've
been
thinking
about
or,
and
I've
been
talking
about,
metrics
and
frameworks
and
using
metrics
and
tension.
You
know
if
we
think
about
the
four
key
metrics.
These
are
speed
and
stability
and
we
use
metrics
and
tension
and
many
times
people
ask
me
for
guidance
and
best
practices.
And
how
do
we
measure
things
and
now,
especially
now,
you
know
that
I've
been
doing
more
work
and
when
I
joined
github
we
started
digging
into
more
things
around
productivity
and
say
well.
B
Given
that
framework.
Given
that
context,
when
I
was
at
github,
I
reached
out
to
a
handful
of
my
colleagues
at
msr-
and
I
said
you
know-
I've
been
I've
been
thinking
about
this.
I've
got
this
in
my
head,
I
know
they're,
I
know,
there's
more
than
activity
just
counts
right,
because
everyone's
thinking
about
light,
we
all
know
lines
of
goodness
trash
right,
but
we're,
like
everyone,
thinks
about
lines
of
code
or
number
of
commits
or
number
of
pr's
number
number
number.
That's
an
activity
metric,
I
said,
but
I
know
there's
going
to
be
more
right.
B
B
We
also
know
there's
communication
and
collaboration,
because
there's
so
much
great
work
around
invisible
work,
going
back
to
lucy
suchman's
work,
and
I
said
you
know,
satisfaction
well-being,
so
I
kind
of
walked
into
it
with
at
least
kind
of
a
rough
idea,
and
I
reached
out
to
people
who've
been
studying
this
for
at
least
a
decade
reached
out
to
two
or
three
a
couple
of
them
said:
oh,
but
then
there's
this
person,
I've
been
working
with.
Can
we
also
pull
this
person
I'm?
So
I
think
we're
going.
A
B
A
party-
oh
my
gosh,
it
was
like
the
best
nerd
party.
Ever
we
ended
up
having
this
weekly
meeting
where
we
kind
of
pulled
together
this
paper
and
this
wealth
of
experience
and
expertise,
and
we
ended
up
coming
up
with
the
five
right.
It
was
satisfaction
and
well-being,
performance
kind
of
fl
through
the
system.
What
are
the
outcomes
through
the
system,
activity,
communication,
collaboration
and
efficiency
and
flow?
And
then
you
know
the
structure
of
the
paper
came
out
where
we're
like.
Well,
let's
make
sure
we
discuss
myths
and
misconceptions
to
help
motivate
this
paper.
B
A
Well,
you
know,
let's
talk
a
little
bit
about
the
myths
and
misconceptions,
I
think
one
of
the
things
that
really
taught
you
about
accelerate.
I
was
talking
about
the
capabilities
and
then
seeing
out
of
that.
What
are
their
anti-patterns
that
you
want
to
try
to
avoid,
because
there's
so
much
data
to
kind
of
show
that
so
can
we
talk
a
little
bit
about
of
the
myths
and
misconceptions
that
you
talk
about
in
your
paper?
B
Know
I
already
talked
about
it
that
there's
one
metric
that
matters
and
that's
that
one's
really
problematic
and
we
end
up
seeing
it
so
often
in
terms
of
activity
right,
like
I'm
gonna,
look
at
at
least
by
now.
Most
people
like
lines
of
code
is
trash
right
or
very
problematic,
but
then
people
will
say
well
number
of
commits
or
number
of
pull
requests
or
a
number
of
something.
But
what
ends
up
happening
is
not
only
do
you
miss
the
complexity
of
what
is
development
and
also
not
just
development
check
out
the
bottom
of
the
paper.
B
We
have
a
sidebar
on
sre
right
because
productivity,
this
framework
in
discussing
it
and
developing
it.
The
framework
captures
many
different
types
of
productivity,
which
is,
I
think,
the
superpower
behind
it.
I
love
it
so
much,
but
when
we
only
talk
about
one
thing,
we
miss
the
complexity.
We
miss
the
nuance.
We
miss.
We
miss
several
other
things
that
contribute
to
other
things
that
are
important.
B
We
have
early
data
showing
that
one-on-ones
are
predictive
of
active
time
coding,
because
we
need
this
with
brain
power.
We
need
discussion
time.
We
need
communication
time.
We
also
know
things
like
time
spent
in
design
review
makes
for
better
code
because
otherwise
you're
just
piling
on
technical
debt
right.
So
if
we
don't
think
very
carefully
about
how
we
want
to
guide
and
create
better
decisions,
this
can
be
problematic
right.
B
That's
the
other
thing
right
like
what's
the
decision
you're
aiming
for,
if
you
just
pick
a
random
number
out
of
the
air
that
doesn't
give
you
actionable
advice
that
doesn't
help
you
guide
decisions.
There's
also
this.
This
idea
that
you
can
buy
productivity,
you
can
just
purchase
something
and
it's
I
want
to
say
that
it's
I'm
going
to
say
it
and
someone's
going
to
take
this
out
of
context,
and
when
you
do
I'm
going
to
find
you
on
twitter
and
I'm
going
to
yell
at
you.
B
So
I
the
thing
that
I
will
say
is
a
yes
is
that
we
can
make
smart
purchase
decisions
to
help
productivity,
but
I'm
not
going
to
call
it
productivity,
I'm
going
to
say
the
developer
experience
a
superior
developer.
Experience
can
be
helped
with
good,
tooling
and
good
automation,
and
by
that
I
mean
how
can
we
reduce
friction?
How
can
we
make
it
easier
to
code?
How
can
we
make
it
easier
to
spin
up
or
provision
environments?
How
can
we
make
it
easier
to
search
and
find
code
subject
matter,
experts,
information?
B
B
Listen
if
we
can
throw
money
at
that
problem,
those
problems
absolutely
do
it,
but
that's
developer
experience,
that's
not
just
like.
I
can
buy
a
thing
and
it
clicks
and
it's
done,
and
then
I
expect
to
like
squeeze
blood
out
of
a
rook.
No,
that's
not
a
thing,
because
that's
one
portion
of
it
and
then
we
also
need
to
be
thinking
about
creating
and
curating
and
fostering
the
rest
of
the
developer
experience.
How
do
we
help
and
surface
communication?
B
A
Well,
this
brings
up
a
great
point.
You
know
the
corresponding
anti-pattern
about.
Can
you
buy
a
solution
that
does
all
of
this?
No,
so
when,
when
they,
when
someone
tries
to
sell
you
that
you
know
be
suspicious,
it
kind
of
goes
along
with
you
know,
do
you
do
devops
by
hiring
a
devops
team
right?
That's
what
you
know,
schools
of
thought,
but
it's
the
same
kind
of
thing.
It's
like
you're,
throwing
money
in
the
wrong
direction
right
in
this
case
resources
and
overall
there's,
I
think,
also
productivity
myths.
B
Yeah
when
you're,
you
know
a
reasonable
rule
of
thumb,
is
that
in
a
in
a
good
scenario,
50
50
is
nice
right,
because
you've
got
design
reviews,
you've
got
code,
reviews
you're,
dealing
with
technical
debt
and
keep
the
lights
on
work
also
realize
every
time
you
ship
something
you're,
also
going
to
be
thinking
about,
maintaining
it,
whether
you're,
maintaining
that
or
you're
dealing
with
additional
technical
debt
or
you're
dealing
with
additional
architectural
considerations
right.
How
many
supplements
are
there
right?
How
many
support
tails
are
there
in
just
to
keep
the
lights
on
situation?
B
A
Obviously,
right
yeah,
okay
cool
you
know
and
then
going
back
to
I
was
actually
this
is
a
thought
exercise
I
think
about
you
know.
Devops
engineer
is
an
anti-pattern,
I
mean
I
know
I
don't
know
what
they
mean
when
they
say
that,
but
there's
also
like
all
of
that
invisible
work.
If
you
can
offload
all
that
invisible
word,
what
would
that?
What
would
that
job
description
be
sustaining
engineer.
B
Well,
so
it's
interesting
right
because
there
are,
there
are
a
few
pieces
to
think
about
here,
because
if
you
could
offload
all
of
that
invisible
work,
what
would
that?
What
would
that
job
description
look
like,
but
at
the
same
time,
when
we
think
about
some
of
the
core
devops
principles
and
processes,
it's
all
about
speeding
up
those
feedback
loops
because
we
want.
We
want
faster
feedback.
We
want
those
tests
to
fail
as
quickly
as
possible,
because
then
we
retain
that
context
in
our
head.
B
B
The
second
time
we
solve
a
problem
might
be
a
manual
process,
and
then
we
automate
it
away
and
then
it's
a
brand
new
problem
again,
it's
a
brand
new
process
right,
but
if,
if
we
just
offload
everything
we're
actually
very
bad
developers,
because
suddenly
we
have
no
idea
about
how
our
systems
react,
respond
context
is
everything.
It's
all.
It's
all
gone
yeah,
and
it's
also
really
interesting
that
you
have
mentioned
a
couple
times:
a
devops
team.
B
Can
we
just
hire
a
devops
team
of
devops
engineers
to
handle
things,
because
there
are
some
places
and
some
situations
where
I
hear
people
say
I
just
want
to
buy
a
devops
tool
set
or
tool
chain.
So
sometimes
people
will
just
throw
they
want
to
try
to
throw
money
at
different
sets
of
the
problem,
but
either
way
it
kind
of
requires
everything
in
both
yup.
A
B
B
Interestingly,
I've
already
had
people
try
to
nerd
snipe
me
on
twitter,
and
I
am
a
pro
now,
so
I
just
ignore
them,
but
in
some
of
the
nerd
sniping
they
have
tried
to
say
or
claim
that
I
am
redefining
productivity
to
include
satisfaction
and
well-being,
but
I
will
say
that
much
of
the
prior
research
and
data
doesn't
support
that
assertion
that
we're
redefining
or
we're
re-scoping
productivity
and
here's.
Why
re
rediscovering
it
to
include
satisfaction,
well-being
and
here's?
B
The
productivity
involving
is
predictive
is,
is
in
turn
predictive
of
higher
productivity,
so
when
it
is
so
highly
intertwined
in
a
related
intercorrelated
with
many
other
productivity
measures,
including
communication
collaboration,
I
mentioned
earlier
that
that
one-on-ones
end
up
being
predictive
of
more
coding
time.
In
many
situations,
when
so
many
of
these
different
dimensions
and
factors
end
up
being
so
highly
correlated,
I
don't
think
you
could
say
that
one
is
more
or
less
weighted.
What
I
would
say
is,
as
we
recommend
in
the
paper,
having
at
least
definitely
at
least
two.
We
recommend
three.
B
I
could
maybe
see
a
case
where
you'd
have
two.
It
would
be
a
stretch,
but
I
would
say
at
least
have
three
and
pick
them
based
on
what
the
decision
is
you're
trying
to
make.
What's
your
goal,
what's
your
decision
what's
the
context
in
which
you're
operating
now,
this
isn't
like
bingo,
where
you
have
to
hit
every
possible
square
in
like
like
bingo
blackout,
where
you're
trying
to
like
cover
the
card
in
order
to
win
now,
why
not?
B
Listen
people
get
overwhelmed
right
like
if
someone,
if
you
tell
someone
they
have
to
have
472
measures
in
order
to
make
a
good
decision
they're
going
to
like
walk
away
like
they're
going
to
be
done,
but
if
you
can
give
them
a
handful
of
measures
across
at
least
three
dimensions,
and
you
can
say
this
will
help
us
make
a
better
decision
and
here's
why
they
will
do
better.
So
can
I
give
an
example:
I've
been
ranting
for
medics.
I
care
deeply.
B
B
Here's
a
good
example
that
I
have
seen
practically
at
least
two
or
three
times
so
people
want
more
time
and
code.
People
also
want
fast
turnaround.
Peer
review,
turnaround
preview
turn
around
the
interesting
thing
is
many
times
they're
like
why
I'm
being
blocked
on
code.
I
need
good
turnaround.
So
when
I
say,
let's
have
some
kind
of
balance.
B
Oh
my
gosh,
it's
the
worst,
except
unless
you
have
a
new
eager
designer
or
product
manager
in
charge
of
prs,
then
it
sounds
amazing
or
someone
who's
just
in
charge
of
that
metric
in
isolation,
then
that
sounds
amazing,
and
so,
if
we
think
about
balancing
pr
turnaround
and
it's
very
important
right,
because
if
those
prs
are
blocking
someone
else,
so
let's
balance
that
with
time
and
code
right,
because
ide
time
and
ide
has
been
shown
to
be
highly
correlated
with
developer.
Satisfaction,
so
if
we
want,
we
can
pull
in
a
developer
satisfaction
metric.
B
If
it's
going
to
be
too
hard
to
collect
that
now,
I
would
suggest,
including
both
telemetry
and
perception
measures,
but
whatever,
let's
save
that
fight
for
another
day,
another
minute.
So
let's
look
at
coding,
time
or
number
of
commits.
Let's
say
you
don't
have
ide
time
number
of
commits
or
pushes
or
something
like
that
with
turnaround
time,
and
then
let's
also
look
at
something
like
batching
or
flow.
A
A
Do
you
have
data
that
shows
that
you
know
some
companies
will
do
no
meeting
fridays
or
no
meeting
mondays
or
you
know
pick
a
day
of
the
week,
other
companies
less
less,
so
I
think
but
may
try
like
no
meeting
mornings
on
an
ongoing
basis.
Is
there
any
data
that
kind
of
shows
how
how
batching
that
sort
of
thing
can
be
effective?
Presumably
you
need
to
have
a
single
system.
If
you
have
some
people
that
have
no
meeting
fridays
and
other
people
have
no
idea
warnings,
there's
going
to
be
bad
intersection,
availability.
B
Again
I'll
say
it
depends
and-
and
it's
it's
it's
kind
of
unique
and
particular
to
the
team
and
to
the
person
right,
because,
especially
as
we've
seen
over
the
last
year,
when
everything
came
home,
we
did
see
some
teams
that
thrived
with
no
meeting
tuesdays
or
no
meeting
friday.
You
know
no
eating
full
days
because
they
were
really
able
to
focus.
B
However,
it
was
very,
very
disruptive
to
other
folks,
depending,
for
example,
if
they
had
to
provide
child
care
right.
It
was
actually
very
difficult
because
suddenly
people
expected
that
this
would
be,
they
would
be
available
for
everything
right
or
they
had
days
off
and
like
forced
days
off,
but
it
was
actually
pretty
difficult
for
them,
because
when
you
had
these
days
off,
there
were
then
even
implied,
if
not
expected,
implied
expectations
about
additional
work
being
done
or
additional.
B
You
know,
deliverables
or
turnarounds,
so
balancing
it,
at
least
within
the
team
level,
can
be
really
helpful.
Now,
speaking
of
that,
productivity
is
personal.
Some
wonderful
work
by
ford
at
all,
coming
out
of
msr
has
found
that
indeed,
productivity
is
personal.
For
some
people,
work
from
home
has
been
wonderful.
B
B
On
the
other
hand,
for
some
people,
work
from
home
really
has
been
a
struggle.
They
see
more
interruptions,
they're
really
missing
that
interaction
with
teams.
It's
really
been
kind
of
tough,
and
so
there
really
isn't
just
one.
It
depends
just
one
answer:
it
depends
on
what
your
work
style
is
like.
It
depends
on
what
your
personal
situation
is
like.
A
A
So
when
you
think
about
that
process
and
metrics
how
much
to
something
like
okrs
or
kpis
really
tie
in
effectively,
you
know
so
often
we
see
those
applied
kind
of
in
letter
of
the
law
rather
than
spiritual
law
applications
and
they
just
become
kind
of
a
check
box
and
not
necessarily
informative.
Do
you
have
any
sort
of
thoughts
or
research
around
that
within
the
context
of
this
framework.
B
Within
the
context
of
this
framework,
I
would
say
this
frame:
articus
is
really
meant
for
things
like
productivity,
but
it
can
roll
up
very
well
into
things
like
okrs
okrs
can
be
a
really
wonderful
organizational
alignment
technique
and
there's
actually
some
really
exciting
research
happening
right
now
out
of
some
msr
folks
so
stay
tuned,
because
I
think
they're
writing
it
up
right
now,
but
in
terms
of
organizational
alignment,
I
think
it's
wonderful.
I
do
love
your
point
that
it's
very
easy
to
be
gamed.
B
Honestly,
any
metrics
can
be
gained
right,
anything
can
be
gained.
So
I
think
that
the
goal
is
to
think
about
organizational
alignment
communication
goals,
and
how
can
we
think
about
communicating
those
goals
both
within
our
teams
up
and
down
the
organization
and
across
teams?
And
what
is
it
that
we're
trying
to
communicate
and
what
is
it
that
we're
trying
to
do?
If
the
point
is
to
make
sure
that
we
can
just
like
nail
that
metric?
It's
it's
easy
to
measure
it's
easy
to
hit.
It's
fine!
B
A
Right,
you
don't
want
to
be
a
check
box,
you
want
to
be
incentive
yep.
So
let's
talk
a
little
bit
more
about
you
touched
on
this
a
little
bit.
I
want
to
dig
into
it
and
the
idea
of
like
proxies
to
measure
collaboration
and
communication.
We
talked
about,
like
you
know,
one-on-one
time
like
like
a
pair
programming
or
or
an
in-person
code
review,
or
an
active
code
review
rather
than
just
you
know,
kicking
pr's
back
and
forth
for
github.
A
You
know
that
could
include
things
all
the
way
down
to
like
monitoring
network
traffic,
just
to
see
those
connections,
but
that
starts
to
kind
of
feel
a
little
bit
big
brothery,
perhaps-
and
you
know,
are
we
being
tracked
and
particularly
in
times
of
covid,
there's
been
companies?
Horrifyingly
who've,
you
know
required
employees
to
install
software
that
you
know
you
know
how
much
keyboard
time
are
you
spending
that
kind
of
stuff?
A
So
what's
the
balance
between
being
able
to
have
important
insights
into
your
development
organization,
into
your
engineer's
productivity
versus
being
overly
intrusive,
from
the
perspective
of
like
job
satisfaction
and
psychological
safety
and
all
those
other
things
that
are
so
important?
Yeah
I
love.
B
B
I
don't
I
don't
honestly,
I
don't
think
that's
the
best
way
to
misuse
it
right
in
terms
of
communication
collaboration.
I
think
that
has
better
interesting
uses
to
help
us
discover
and
surface
and
identify
new
folks
that
we
might
be
working
with
or
new
folks
that
are
just
just
past
our
known
collaboration
network
that
we
may
not
realize
right
like
how
can
we?
How
can
we
discover
new
subject
matter
experts?
B
Who
could
we
discover
kilometers
that
we
may
not
understand
or
even
realize
that
are
just
past
right
like
if
I
always
work
with
the
same
three
or
four
people,
and
they
maybe
work
with
the
same
two
or
three?
I
may
have
just
like
a
like
a
a
work
cousin
network
that
I
just
don't
quite
know
about.
I
think
those
opportunities
are
great
and
even
in
terms
of
like
the
communication
collaboration,
it
also
extends
to
things
like
discoverability.
B
B
It
really
boils
down
to
an
organization's
culture,
does
an
organization
empower
and
trust
its
employees,
or
are
they
doing
things
like
stock
ranking
and
if,
if
they
empower
and
trust
their
employees,
you
will
largely
see
an
organization
that
generally
tr
uses
data
to
try
to
answer
questions
to
help?
Whether
or
not
those
questions
are
well
formulated
or
well
structured,
you
don't
know,
and
that's
one
of
the
underlying
motivations
for
writing.
This
paper
is
to
say
I
keep
seeing
you
use
these.
You
use
these
words.
B
I
don't
think
you
understand
these
words
right
so
like
we
want
to
help.
You
do
the
better
thing.
If
it's
a
stack
rank
situation,
listen
they're
going
to
pull
whatever
data
they
can
pull
and,
like
you
can't
yeah.
No
data
is
going
to
fix
that.
What
you
have
to
do
is
help
motivate,
communicate
and
and
articulate.
A
So
in
theory,
if
you
were
looking
at,
for
example,
a
network
traffic
proxy
in
a
healthy
organization,
you
would
see
kind
of
a
big,
a
big
lit
up
blob
where
there's
many
points
across
multiple
or
many
connections
across
points.
But
we
probably
often
see
in
organizations
there's
little
clusters
of
connections
within
a
single
team
and
then
maybe
a
couple
of
connections
across
right.
Yes,.
B
In
healthy
orgs,
you
see
that
and
what
you
often
do
is
you'll
notice,
key
people
that
are
connectors
and
you
find
ways
to
both
leverage,
those
people
to
maximize
and
accelerate
and
amplify
connections
and
make
sure
that
they
they
don't
get
burned
out
that
you
make
sure
that
they're
happy
that
you
make
sure
and
you
you
figure
out
you
find
out.
You
ask
questions
like
why.
Why
does
everyone
talk
to
this
person
either
they're?
Incredibly
helpful,
they're?
Incredibly,
happy
they're!
Incredibly,
wonderful!
B
A
Let's
talk
about
another
kind
of
key
element
of
this,
which
is
the
code
review
and
we
talk
about
it
in
the
paper.
You
speak
touch
on
a
couple
of
different
ways
from
a
building,
an
inclusive
culture
which
is
increasingly
important,
and
lord
knows,
there's
a
decades
worth
of
data
that
says
that
inclusive
organizations
are
generally
more
successful
both
for
longevity
and
financial
reasons.
There's
there's
a
lot
of
data
that
shows
that
certain
types
of
people
will
get
will
give
and
receive
code
reviews
better
than
others.
A
I
think
there's
a
number
of
studies
that
talk
about
how,
for
example,
women
may
be
reviewed
more
harshly
than
men.
If
you
know
the
gender
of
the
code
of
the
code
author,
that
sort
of
thing,
maybe
a
person
of
color
might
get
reviewed
more
harshly,
and
this
can
be
exacerbated
if
you
have
certain
sets
of
people
who
are
responsible
for
the
majority
of
your
reviews.
Maybe
you
know
your
senior
team.
A
So
what
do
you
think
about
going
back
to
tooling
and-
and
you
know,
opportunities
to
throw
money
at
a
problem
in
useful
ways?
What
about
tooling,
to
try
and
smooth
out
those
types
of
frictions,
for
example,
anonymizing,
authors
of
pr
requests
or
somehow
making
the
display
of
of
technical
progression
more
anonymous
as
a
way
of
reducing
bias
and
and
also
providing
more
opportunities
for
people
to
participate
in
a
safe
way?
Is
there
any
data
that
shows
that
those
types
of
efforts
are
worth
investigating
for
for
organizational
help.
B
B
It's
really
kind
of
an
interesting
and
complex
situation
and
complex
space
where
women
and
underrepresented
minorities
both
receive
more
harsh
reviews
and
they
receive
less
positive
reviews,
positive
language
in
their
reviews,
which
makes
it
pretty
difficult
from
a
review
standpoint
and
from
a
performance
management
standpoint.
So
from
a
review
standpoint,
it's
difficult
in
the
open
source
space
from
performance
management.
B
B
B
Investments
and
and
efforts
to
increase
inclusion
broadly
in
terms
of
work,
that
kind
of
raised
the
bar
or
or
allowed
more
inclusion
and
more
participation
for
underrepresented
groups,
actually
helped
everyone
in
general
right,
so
they
yeah
yeah.
It
was.
It
was
very,
very
cool
and
I
want
to
be
careful
because
I
haven't
I'm
not
as
familiar
with
this
paper.
B
They
helped
novices
across
the
board,
and
I
think
that's
particularly
interesting
to
think
about
because
many
times
you
I
at
least
I
personally
have
come
across
this
reflex
from
people
saying
like
well,
but
is
it
worth
or
or
what
do
we
think
about
devoting
this
many
resources
toward
a
group
that
is
underrepresented
right,
like
is
this
a
smart
use
of
resources?
And
I
don't
love
that
reflex,
but
at
least
from
a
from
a
perspective.
B
And
so,
when
we
think
about
creating
tools
and
creating
solutions
for
folks
who
are
not
well
served
by
our
tools,
for
example,
code
reviews,
we
can
actually
benefit
much
larger
groups
of
people
who
may
not
currently
be
served
well
and
who.
We
may
just
not
be
aware
that
they're
not
served
well.
And
so
I
think
it's
a
very,
very
good
opportunity.
A
To
kind
of
get
rid
of
that
tough,
it
out
mentality,
right,
yeah,
exactly
no
100
agree
all
right.
I
think
we're
about
out
of
time,
but
I
did
want
to
close
out
as
someone
who
has
a
long
been
in
the
industry
kind
of
watching
how
it
is
that
we
do
our
work.
I'd
love
to
close
out
with
a
sort
of
inside
the
actor's
studio
style
questionnaire.
Okay,
reflect
reflect
your
responses,
brief
responses.
A
A
I
could
see
that,
hopefully
you
would
have
a
lot
of
ice
cream
celebrating
successful
surgeries.
Yes,
yes,
all
right!
Thank
you!
So
much
nicole,
dr
nicole
forsgren,
for
joining
us
here
at
cdcon.
It
has
been
a
pleasure
looking
forward
to
seeing
the
next
round
of
research
that
you
produce
on
behalf
of
all
of
us
in
high
tech
industry.
I
look
forward
to
it.
Thank
you
thanks.
So
much
for
having
me.