►
Description
2:15 - Program Start
5:23 - Why developer productivity matters
9:14 - A developer-first approach to productivity
13:56 - The SPACE of developer productivity http://aka.ms/spacepaper
22:46 - Developer productivity myths
26:35 - Q&A 1
31:28 - The Good Day Project first hand
38:26 - Results and sentiment from this approach
45:56 - Implementation via Slack
53:22 - Q&A 2
Measuring productivity by your PRs? We’ll stop you right there :hand: With experiments like The Good Day Project Eirini Kalliamvakou found better ways to stay focused on code and know where work is making an impact.
blog post: https://github.blog/2021-05-25-octoverse-spotlight-good-day-project/
papers: https://aka.ms/spacepaper
https://aka.ms/spacetalk
https://aka.ms/dvl
A
A
Hello,
hello,
hello.
Everyone
welcome
nice
to
see
everyone
in
the
chat,
hello,
france,
hello
from
all
over
the
place.
I
I
can't
even
see
just
how
many
countries
are
represented
here
today,
but
it's
always
nice
to
see
everyone
so
good
morning,
good
afternoon,
good
evening,
happy
thursday
or
friday,
wherever
you
are,
and
today
welcome
to
demo
days
and
we're
going
to
talk
about
developer
productivity
in
this
age
of
measure.
B
A
B
B
So
yes,
my
name
is
irini.
I'm
a
senior
researcher
at
github,
I
kind
of
describe
what
I
do
as
I
do
research
to
try
to
find
ways
to
help
developers
be
more
productive,
more
efficient,
happier,
healthier
and
I
get
to
work
on
a
lot
of
very
cool
stuff.
While
I
do
that,
so
that's
the
thing
that
I
want
to
talk
about
today.
B
It's
called
the
good
day
project.
This
is
a
kind
of
like
an
internal
experiment.
We
run
at
github
about
like
six
months
ago.
We
wrote
it
up,
so
we
have
shared
some
of
the
information
on
the
github
blog
about
two
months
ago
and
you
can
find
a
lot
of
information
there.
I
did
want
to
take
the
time
to
talk
about
some
of
the
parts
that
I
think
are
pretty
pretty
cool
and
pretty
important
that
have
to
do
with
a
good
day
project.
B
So
today
I'm
going
to
talk
about
what
is
it
that
we
did
why
we
did
it,
how
it
went,
and
I'm
also
going
to
leave
you
with
some
takeaways
kind
of
plant
seeds
in
people's
brains
and
and
like
ways
that
you
can
use
some
of
the
information
in
your
day-to-day
too.
So
I
like
to
start
things
with
why
so
I'm
I'm
here
saying:
let's
reimagine
productivity
or
like,
let's
rethink
it,
let's
get
it
right.
Why
are
we
even
doing
that?
Why
are
we
even
talking
about
developer
productivity
in
the
first
place?
B
I
put
some
here
on
the
slide
and
these
might
represent
things
that
you're
thinking
about
as
well,
so
you're
concerned
about
making
higher
quality
software
or
making
software
faster
or
improving
your
developers,
well-being,
their
retention,
their
satisfaction.
These
are
all
things
that
are
underlined
by
developer
productivity
and
we
actually
find
companies
that
do
pay
attention
to
developer
productivity
and
supported
well
end
up
doing
better.
So
that's
reason,
number
one
why
we're
talking
about
reimagining
productivity
is
because
it's
very
very
important.
B
Unfortunately,
reason
number
two
is
that
important,
as
it
is
a
lot
of
the
time
we
kind
of
get
it
wrong,
and
so
that's
not
the
place
where
we
want
to
be
when
something
is
important.
We
want
to
make
sure
we
get
it
right.
What
do
I
mean
by
getting
it
wrong?
You
may
have
seen
developer
productivity
or
really
productivity
tracking
tools
out
there
a
lot
of
the
times.
The
the
approach
is
an
approach
that
we
call
kind
of
like
counting
beans.
B
They
find
that
it
doesn't
really
do
justice
to
how
multi-faceted
and
complex
their
work
is.
They
have
seen
it
in
the
past
kind
of
used
against
them
that
simplification
of
their
work,
it
doesn't
really
work
in
their
favor
and
to
them.
It
feels
a
lot
like
spying
like
somebody's
watching
how
much
of
a
thing
they're
doing
or
how
long
it
took
them
to
do
the
thing
and
they're
capturing
information
about
them
from
that.
B
So
over
time,
developers
have
become
a
little
bit
suspicious
when
it
comes
to
productivity.
When
it
comes
to
productivity
tools
or
productivity
track
tracking.
We
have
lost
a
lot
of
developer
trust
there,
so
they've
come
to
kind
of
distrust
the
word
and
distrust
the
tools
that
come
with
it,
which
is
unfortunate
because
at
the
same
time,
developers
really
do
care
about
their
productivity.
It's
just
that.
B
What
they
have
in
mind
is
slightly
different
from
what
the
tools
are
giving
them
developers
go
around
and
are
thinking
about
their
experience
of
productivity
in
their
day-to-day,
and
that's
more
like
thinking
about
having
a
good
day
than
anything
else.
So
they
definitely
want
better
insight
into
their
work
habits
and
what
works
for
them.
And
what
doesn't?
What
is
it
that
they
can
change?
They
are
quite
a
bit
data
driven
and
a
lot
of
the
time.
B
They're
also
data
literate,
so
they
are
very
much
interested
in
getting
numerical
information
that
has
to
do
with
their
habits
and
what
they
can
change
and
they
definitely
are
interested
in
having
more
of
the
good
days.
They
want
to
be
more
satisfied
with
the
days
that
they
have
and
that's
a
little
bit
of
a
gap
right.
That's
what
developers
need
and
want
when
it
comes
to
productivity?
B
B
What
is
the
right
information
to
surface
to
developers
to
help
them
improve
to
help
them
understand
their
days
and
potentially
improve
them?
How
can
we
do
that
without
breaking
anything
for
them
like
without
disrupting
their
workflow,
and
how
can
we
do
that,
while
safeguarding
and
respecting
their
privacy
every
step
of
the
way,
because
we
know
that
they
are
suspicious?
We
know
that
they're,
you
know
they
they
kind
of
distrust
productivity
in
different
approaches.
How
do
we
make
sure
we
don't
repeat
the
same
mistakes?
B
We
grabbed
40
engineers
at
github,
and
these
are
individual
contributors,
so
no
managers
at
this
point,
we
were
only
in
interested
in,
like
the
individual
developers
experience,
we
had
40
40
people
sign
up
and
then
for
two
weeks
every
day.
At
the
end
of
the
day,
we
sent
them
a
two-minute
survey
that
we
wanted
them
to
fill
out,
and
then
we
asked
them
questions
about
their
day,
such
as.
How
much
did
they
work
with
others?
How
much
did
they
help
others
today?
B
How
many
breaks
they
took,
how
many
meetings
they
had?
What
was
their
emotion
for
the
day?
So
these
are
all
things
that
are
important,
that
are
part
of
a
developer's
workday
but
are
never
captured
in
any
telemetry
or
at
least
not
in
any
telemetry
that
we
have,
but
typically
they're,
not
captured
in
an
automated
way
through
telemetry.
We
asked
them.
The
first
question
we
asked
in
every
survey
was
a
very,
very
simple
one,
which
was
how
was
your
workday
and
we
gave
people
options
from
one.
It
was
terrible
to
five.
B
It
was
awesome,
and
just
by
that
very
simple
question
and
very
simple
way
to
answer
that
question.
We
were
able
to
classify
what
type
of
day
this
person
is
having
and
then
start
building
patterns
about
these
different
types
of
days.
A
person
is
having,
and
the
information
for
the
the
patterns
came
from
two
places:
telemetry,
because
we
had
it
and,
of
course,
we're
going
to
use
it
and
also
all
the
information,
perhaps
for
me,
more
importantly,
all
the
rich
information
we
were
getting
from
the
surveys
every
single
day.
That's
what
we
used.
B
We
combined
that
information
and
we
started
creating
patterns
for
each
person
individually
and
at
the
end
of
the
two
weeks
we
sent
every
person
their
own
good
day
report.
I
had
a
summary
and
a
set
of
charts
and
texts
to
help,
read
the
charts
and
see
what
to
get
out
of
them.
That
specifically
was
tailored
to
their
data.
Their
patterns.
This
was
only
applicable
to
them
and
they
were
also
the
only
person
that
had
access
to
that.
That's
not
the
only
thing
we
gave
them.
B
Okay,
all
right.
Well,
then,
I'm
gonna
go
back
to
the
slides
okay,
so
taking
a
little
bit
of
a
step
back
so
far,
I've
been
giving
information.
That
is
mostly,
you
know.
How
did
we
do
this,
which
is
cool,
but
it's
also,
I
think,
important,
to
have
an
idea
of
like
what
were
we
thinking
the
whole
time
we're
doing
this?
How
did
we
design
this?
For
example,
I
mentioned
sending
people
surveys
every
day.
B
What
were
the
questions
in
the
survey
and
where
did
they
come
from
so
what
we
used
here,
because
we
didn't
want
to
go
with
the
current
thinking
about
productivity
is
activity.
We
used
a
new
framework
of
developer
productivity
called
space.
This
was
published
earlier
this
year
by
nicole
forsgren
and
colleagues
from
the
university
of
victoria
and
from
microsoft.
B
Research
and
I
put
a
short
link
here-
absolutely
encourage
everyone
to
read
that
it's
a
little
bit
of
a
you
know
a
longer
article,
because
it
is
detailed,
but
it
explains
very
well
the
the
kind
of
thinking
that
went
into
creating
this
framework.
So
what
is
space?
What
is
special
about
it,
and
why
did
we
choose
it?
The
short
answer
is,
we
chose
it
because
it's
more
holistic
than
any
other
approach
that
was
available
to
us.
So
I
mentioned
that
kind
of
the
pitfall
that
we
we
see.
B
A
lot
of
the
time
is
like
just
counting
activities
right,
pull,
requests
that
are
open,
pull
requests
that
are
closed
or
the
time
to
merge
a
pull
request
and
so
on,
and
it
seems
to
be
very
restricted
to
that.
But
we
were
thinking
no,
no.
We
need
something
that
is
broader
so
that
we
can
capture
a
lot
more
aspects
of
what
goes
into
developer
productivity,
so
space
does
that
and
it's
an
acronym.
It
stands
for
five
things:
five
dimensions,
s
is
for
satisfaction
and
well-being.
B
P
is
for
performance,
a
is
for
activity,
c
is
for
communication,
and
collaboration
and
e
is
for
efficiency
and
flow.
So
already
you
can
see
there's
a
lot
more
going
into
it
than
just
activity.
Activity
is
still
there
right.
It's
not
nothing,
but
it's
not
everything
so
there's
other
other
things
that
go
into
it.
So
I
want
to
say
a
very
like
a
little
bit
about
each
dimension
so
that
we
make
sure
that
we
all
understand
what
goes
into
it.
B
I'm
gonna
throw
some,
like
example,
metrics
that
potentially
you
are
looking
at
or
you're
interested
at
or
you
might
want
to
be
interested
in
capturing
just
as
a
as
an
example,
and
then
if
people
have
questions
and
so
on,
we
can
we
can
get
into
that
too.
So
the
first
dimension
of
satisfaction
and
well-being
is
really
about
how
happy
and
satisfied
and
fulfilled
developers
are
with
what
they're
doing,
and
that
can
include
the
work
that
they're
doing
can
include
the
tools
that
they're
using
to
do
their
work
and
so
on.
B
This
is
very
important
to
capture
because
it
directly
impacts,
developer
productivity
and,
at
the
same
time,
it's
very
hard
to
capture
this
sort
of
thing.
Satisfaction,
well-being,
just
doesn't
live
in
telemetry,
so
it's
not
automatically
grabbed
and
stored
somewhere
as
information.
So
what
ways
do
we
have
to
get
it
at
scale?
Really
surveys
you
have
to
ask
developers
themselves
how
satisfied
they
are.
You
have
to
ask
them
questions
that
capture
their
well-being.
B
You
know
metrics
to
capture
it
like,
for
example,
any
any
metric
that
has
to
do
with
employee
satisfaction,
engagement,
retention,
burnout.
If
you
can
get
a
sense
of
that,
those
would
all
fall
under
satisfaction
will
be
you
don't
have
to
track
all
of
those.
In
fact,
you
don't
have
to
track
all
of
the
five
dimensions
of
the
space
framework.
A
B
Goals
are
your
goals
right,
your
competitor
goals
might
be
completely
different
and
therefore
the
metrics
that
they're
using
and
what
their
dashboard
looks
like
might
be
completely
different
to
yours
and
that's
fine
examples
for
performance.
So
say
your
goal
is
ultimate
software
quality.
You
probably
want
to
be
thinking
something
like
number
of
bugs
in
your
code
or
the
absence
of
bugs
in
your
code,
maybe
you're
thinking
more
the
impact
of
code
rather
than
the
quality
of
code,
and
then
you
might
be
thinking
about
metrics
such
as
employee.
B
I'm
sorry
customer
satisfaction,
for
example,
so
just
giving
examples
so
that
we
understand
what
goes
under
performance,
but
the
important
point
there
is
performance
and
the
metrics
that
go
with
it
is
going
to
look
very
different
depending
on
your
situation
and
your
organization
activity
don't
feel
like
we
need
to
say
much
there
just
because
this
is
the
most
common
dimension.
This
is
the
one
that
people
automatically
think
about
when
they
think
about
productivity.
B
So
it's
count
of
things.
Number
of
tickets,
number
of
closed,
pull
requests,
and
so
on.
Only
thing
to
point
out
here
is
that
developers
engage
in
a
lot
more
activities
than
we
think,
and
so
only
looking
at
coding
activities
might
not
be
giving
us
the
whole
picture
right
so
think
about
my
favorite
example
at
least
is
doing
things
like
mentorship,
which
developers
do
more
and
more
of
as
they
go
through
their
career
and
they
become
more
senior
and
it's
an
incredibly
valuable
activity,
because
it
makes
them
better.
C
B
But
I
think
we
can
put
a
lot
more
under
communication
and
collaboration
because,
like,
for
example,
how
easy
is
it
for,
especially
as
we're
thinking
about
working
in
a
distributed
way
or
in
a
remote
way?
How
easy
is
it
for
a
team
to
locate
the
right
information
or
for
someone
on
the
team
to
locate
the
right
person
to
ask
a
question
to
right,
so
the
effectiveness
of
communication
and
collaboration
is
decided
on
many
things.
I
would
put
the
quality
of
the
documentation.
B
How
fresh
the
documentation
is,
how
easy
it
is
to
find
documentation
and
so
on.
Those
are
all
things
that
could
go
under
this
dimension
and
finally,
efficiency
and
flow,
which
ended
up
being,
especially
with
a
good
day
project.
We
definitely
saw
it
being
very
pervasive
for
developers
and
very
dominant
in
in
how
important
it
is
for
them
efficiency
and
flow.
We
can
see
a
couple
of
ways
we
can
see
it
as
efficiency
in
terms
of
our
engineering
systems.
B
B
So
that
means
like
misconceptions
that
we
have
in
our
heads
about
what
productivity
is.
So
I
put
some
here.
We
tend
to
think
the
productivity
is
all
about
developer
activity.
You
already
heard
me
talk
about
that.
We
find
more
and
more
that
activity
explains
very
little
and
it
relates
very
little
to
successful
outcomes.
B
Second,
myth
is
that
productivity
is
only
about
individual
performance.
Certainly
not
the
case
is
teams
are
very
important.
Teams
is
where
software
development
happens.
Most
of
the
time
those
things
are
linked:
individual
performance
and
a
team's
performance
and
or
productivity
in
an
organization's
productivity.
These
are
all
linked,
they're,
not
entirely
the
same,
but
we
can't
have
a
productive
organization
without
having
productive
teams,
we
can't
have
productive
teams
without
having
productive
individuals.
B
B
I
feel
pretty
confident
that,
after
so
many
years
of
research
and
productive,
not
not
just
my
research
but
like
the
research,
communities,
research
and
productivity,
if
one
metric
like
a
single
metric
hasn't
surfaced,
yet
it's
probably
because
it
doesn't
exist
and
it
makes
sense
it's
it's
too
complex,
like
software
development,
is
so
complex
of
an
endeavor
that
you
can't
really
reduce
it
to
one
metric.
It
would
be
awesome,
but
not
true,
and
then
productivity
measures
are
only
useful
for
managers.
Another
thing
that
we
hear
quite
a
bit.
B
We
have
certainly
been
thinking
or
designing
tools
with
managers
more
in
mind
and,
as
I
mentioned
at
the
beginning,
the
manager's
need,
when
it
comes
to
tracking
productivity
is
not
the
same
as
the
individual
developers
needs.
So
there
is
this
mismatch
and
I
think
that's
kind
of
what
fuels
the
myth.
But
productivity
measures
are
extremely
useful
for
individual
developers
too,
and
they
help
them
self-improve
and
they
can
improve
their
well-being.
B
Last
one
productivity
comes
down
to
engineering
systems
and
developer
tools.
Those
are
very
important,
not
the
most
important
thing,
and
let's
also
remember
that
this
is
not
where
developers
spent
all
of
their
time.
It's
not
in
the
developer
tools
in
the
engineering
systems,
they're
doing
other
things
a
lot
of
the
time
they
work
with
design,
for
example,
and
so
on.
So
just
focusing
on
the
engineering
systems
and
developer
tools
does
not
give
us
the
whole
picture.
B
A
B
That
is
a
very
good
question.
I
don't
believe
that
we
have
like
data
to
back
it
up,
because
when
we
did
the
project
we
were
in
the
thick
of
it
right.
We
didn't.
We
didn't
have
it
before
and
after
to
to
be
able
to
compare
so
everything
we
have
collected
as
information
is.
While
we
have
all
been
in
this
difficult
situation
that
we've
been
in.
A
B
B
B
So
I
would
consider
it
brand
new,
like
as
a
research
artifact,
it
came
up
like
at
the
beginning
of
the
year.
Companies
always
want
to
take
their
time
a
little
bit
before
they
take
something
else
on
something
new
on.
So
we
do
have.
I
don't
believe
we
can
say
much
and
we
can
share
much
information,
but
we
do
have
a
few
companies
that
are
we're
working
with
that
are
adopting
the
framework
and
we're
going
to
have
case
studies
off
to
share
with
everyone.
But
it's
still
a
little
bit
early
days.
A
B
As
I
talk
about
the
satisfaction
survey,
but
one
thing,
I
think
that
we
were
very
mindful
about
how
we
shared
the
survey
we
asked
we
sent
it
to
people
at
the
end
of
their
day.
I
actually
asked
them
what
time
in
your
time
zone.
Do
you
want
to
get
the
survey
to
make
sure
that
it's
not
interrupting
their
day
at
all,
and
it
only
took
two
minutes
and
that
combination
plus
a
secret
ingredient
which
I'm
going
to
reveal
next
is
seem
to
have
done
the
trick.
A
B
Yes-
and
you
know
it's
a
seminal
book
for
a
reason
and
at
the
same
time
with
things
have
progressed
right,
things
have
moved
on.
I
I
am
aware
that
a
lot
of
of
companies
are
using
that
as
their
guide,
and
it
is
you
know
like
it.
It
plays
into
this
concept
that
I
mentioned
at
the
beginning
of
measuring
output
and
measuring
input.
Input
is
usually
time.
B
Output
is
usually
units
of
you
know,
code
in
some
sense
and
that's
great,
but
it's
not
all
of
it
and
that's
what
we're
trying
to
say
with
the
space
framework
with
a
good
day
project
and
so
on.
We
try
to
exemplify
here's,
how
you
could
be
thinking
about
it
in
a
more
broad
way
and
here's
how
you
could
be
using
it.
Nice
did
I,
hopefully
that
helped
a
little
bit.
B
Yes,
yes,
I
do
want
to
share
my
screen
again
and
this
time
I
am
going
to
share
something
different
all
right,
so
hopefully
everybody
can
see
this
pdf.
I
wanted
to
show
you
what
the
report
looked
like.
I
gave
you
all
the
theory
I
gave
you
the
you
know
how
we
did
the
things
and
so
on.
I
mentioned
that
at
the
end
of
two
weeks,
we
sent
each
person
that
participated
got
their
own
good
day
report,
so
I
want
to
show
you
what
that
looked
like
and
what
the
information
was
there.
B
This
is
simulated,
it's
all
fake
data,
so
it's
not
a
particular
individual's
information
that
you're
looking
at
so
first
thing
we
showed
people
was
a
rough
breakdown
of
the
types
of
dates
that
they
had
right.
They
they
had
given
us
10
days
worth
of
data,
so
it
was
five
work
days
times
two
weeks
and
we
gave
them
a
rough
breakdown
of
how
many
of
these
were
goods,
not
so
good.
So
if
they
said
that
a
day
was
awesome
or
good,
we
counted
as
good
if
they
said
it
was
okay,
bad
or
terrible.
B
We
count
it
as
not
so
good.
Then
we
started
giving
people
graphs
and
for
every
chart
we
also
gave
them
some
some
text,
some
supporting
text
so
that
they
they
know
what
they're
reading
first
graph
we
we
gave
them
was
really
towards
kind
of
the
bean
counting
approach
that
I
was
mentioning
earlier.
So
here
we
have
on
the
horizontal
axis.
We
have
the
days
that
they
reported
and
then
at
the
vertical
axis.
B
We
have
a
count
like
a
total
of
the
count
of
activities
that
they
did
each
day
so
like
three
issues
that
they
closed,
plus
five
comments,
that
they
wrote,
plus
two
prs
that
they
merged
that
sort
of
thing
I'm
oversimplifying,
but
but
really
was
not
much
more
than
that,
and
so
and
and
on
that
we
have
overlaid
information
of
what
was
the
sentiment
for
each
day.
Was
this
the
day
that
they
said
was
good
or
bad
or
okay,
and
so
on
and
we're
showing
those
two
together
and
the
text
we're
asking
people
to
see?
B
Are
these
things
moving
together
or
not
because
if
they
are
moving
together,
that
means
that
activity
is
important
for
this
person
right.
It
seems
to
be
correlated,
it
seems
to
be
associated
with
their
sentiment
every
day
if
they're
not
moving
in
the
same
direction,
which
40
out
of
40
people,
their
bars
and
lines
did
not
move
in
the
same
direction
means
that
activity
is
not
the
driver
for
your
days,
and
this
goes
together
with
everything
else.
B
I've
been
saying
so
far,
there's
definitely
a
little
bit
of
a
theme
right
activity
is
not
everything,
it's
not
even
the
most
important
thing
and
and
like
on
the
research
side
of
things.
Maybe
we
know
this
for
years,
but
this
was
our
opportunity
to
actually
start
educating
people
and
planting
seeds
in
their
heads
that
look
for
your
data
for
your
days,
activity
doesn't
seem
to
be
the
driver.
B
So
if
you're
going
to
be
focusing
on
improving
something,
maybe
it's
not
increasing
the
amount
of
things
that
you
do
every
day
next
chart
we
gave
people
was
a
chart
based
on
two
questions
that
we
had
in
a
survey.
Every
day
we
asked
people
to
say
what
time
of
the
day
they
felt
most
productive
and
least
productive,
and
we
gave
them
like
two
hour
time
windows
throughout
the
day,
so
like
9,
11,
11
to
1
and
so
on,
and
we
plotted
what
they
said,
and
so
a
person
here.
B
If
you
are
low
energy
or
you
feel
like
you're
least
productive,
consistently,
some
time
of
the
day,
maybe
that's
a
time
to
have
you
know,
meetings
or
take
a
break
even
after
that
we
gave
people
charts
one
chart
for
every
one
of
the
space
dimensions.
So
here
we
have
satisfaction
and
well-being.
And
yes,
I
was.
B
I
was
saying
that
what
were
the
questions
that
we
we
were
asking
in
satisfaction
and
well-being,
so
we
had
the
level
of
stress
and
the
number
of
breaks
that
people
took,
and
so
this
is
a
chart
that
has
for
every
day
that
people
reported
their
if
we
kind
of
simplified
to
low
medium
high,
their
stress
level,
the
the
breaks
that
they
took
and
their
level
of
activity.
We
we
kind
of
used
activity
everywhere,
because
we
wanted
to
show
people
that
it's
not
necessarily
like
related
to
everything
else.
B
Honestly,
because
you
know,
maybe
you
know
what
what
works
for
your
good
days
and
then
you
follow
that
or
you
know
what
doesn't
work
for
your
not
purple
days
and
then
you
can
continue
like
you
can
do
things
to
avoid
that
same
thing
with
performance.
The
questions
here
were
about
how
much
progress
people
felt
that
they
made
that
day
and
what's
the
quality
of
the
work
that
they
did,
I'm
gonna
pause
here
and
I'm
gonna
say
since
people
sorry
just
popped
into
my
head.
B
I
am
gonna
go
back
to
my
slides
now
that
I
showed
you
that
this
is
what
we
gave
people
after
two
weeks
of
asking
them
of
asking
them
to
fill
out
surveys
for
us
every
day,
and
we
also
gave
them
a
satisfaction
survey,
because
we
wanted
to
see
how
we
did
with
everything.
Is
there
things
from
this
approach
to
continue?
B
If
we're
doing
this,
this
experiment
again?
If
we
want
to
scale
this
experiment,
what
what
did
we
learn
from
it?
We
asked
a
lot
of
questions
in
the
satisfaction
survey
and
I
would
say
that
the
short
conclusion
is
that
people
really
like
this
really
loved
the
good
day
project,
which
was
awesome
to
see.
I
mentioned
high
response
and
completion
rates
for
the
survey
we've
had
90
as
a
person
who
has
been
interviewing
and
survey
developers
for
a
long
time.
B
They
even
said
that
they
were
excited
to
do
this
every
day
to
fill
out
the
surveys.
Every
day
we
found
that
this
is
something
that
had
value
for
developers.
It
helped
them
meet
their
goals
and
their
goals
were
to
start
self-reflecting
to
understand
their
own
patterns,
to
identify
areas
to
improve
and
ideas.
Like
concrete
ideas
on
what
to
change
moving
forward,
we
found
that
this
was
not
disruptive
to
their
day,
which
I
feel
is
part
of
the
success
of
this,
but
it
happened
in
a
way
that
it
didn't
disrupt
them.
B
It
didn't
interrupt
them
during
their
day
and
they
didn't
share
any
data
privacy
concerns.
Of
course,
we
had
been
very
diligent
about
that
part,
because
we
knew
that
it's
it's
an
area
that
is
sensitive,
so
we
made
sure
that
we
tell
developers
those
who
participated
ahead
of
time
that
the
research
team
is
the
only
team
or
the
only
individuals
that
have
access
to
their
data.
It's
not
shared
with
any
of
their
colleagues
or
their
manager
or
anyone
really.
B
We
were
the
only
ones
that
had
access
to
that
and
we
made
sure
that
that
remained
throughout
the
whole
process
and
we
even
had
a
pretty
long
consent
form
where
we
explained
exactly
like
the
lengths
that
we
would
go
through
to
protect
their
information,
and
so
it
doesn't
surprise
me
that
that
we
didn't
get
any
signal
that
they
were
data.
Privacy
concerns.
I
would
say
this
is
one
of
the
top
priorities.
B
If
someone
was
to
do
it
again,
that's
one
of
the
things
that
you
want
to
make
sure
that
you
get
right
and
so
yes,
not
disruptive
meets
developers,
goals,
no
data
privacy
concerns.
So
as
far
as
we're
concerned,
we
definitely
hit
our
goals.
We
found
the
information
to
service
developers,
we
didn't
break
their
day.
We
safeguarded
their
privacy,
so
you
know
all
goals
met
and
then
we
found
a
couple
of
things:
that's
the
secret
ingredient,
that's
where
that
comes
in.
B
We
found
a
couple
of
things
that
we're
not
expecting
to
find
in
the
satisfaction
survey.
We
asked
people
how
long
and
how
often
they
would
do
this,
given
the
results
that
they're
getting
and
they
said
that
they
were
glad
to
do
it
for
twice
as
long
as
we
asked
them.
So
we
asked
them
to
fill
out
surveys
for
two
weeks.
They
said
they
would
gladly
do
it
for
four
weeks.
B
Yes,
we
gave
them
data
and
reports
and
all
the
cool
stuff,
but
in
addition
to
that,
they
also
got
benefit
just
by
taking
two
minutes
at
the
end
of
the
day,
to
reflect
on
what
had
happened
and
fill
out
that
survey,
it
helped
them
in
two
ways.
They
said
one:
it
made
them
more
mindful
during
the
day,
so
they
were
already
thinking
they
were
getting
in
this
habit
of
self-reflection.
B
So
now
they
were
not
only
reflecting
at
the
end
of
the
day.
It
actually
made
them
more
mindful
about
what
was
happening
in
their
day
as
it
was
happening,
and
the
second
way
was
it
helped.
Them
was
a
very
clear,
tangible
way
to
close
out
their
day.
I
know
that
this
is
a
challenge
that
people
have
had,
especially
in
the
last
year
and
a
half
a
week.
B
But
a
lot
of
people
have
been
talking
about
this,
even
when
we
were
in
the
offices
that
it's
it's
hard
to
disconnect
from
work,
and
there
are
a
lot
of
like
really
good
books
and
approaches
on
how
like
trying
to
find
tangible,
vocal,
sometimes
very
clear
ways
to
signal
to
yourself
that
the
day
the
work
day
is
done,
and
this
ended
up
being
one
of
those
things.
So
people
were
saying
that
it
was
a
very
clear
way.
My
day
is
done.
B
I
filled
out
the
survey
now
it's
me
time
and
that
they
found
benefit
in
just
just
taking
those
two
minutes.
So
I
think
that
that's
the
the
secret
ingredient-
yes,
we
try
to
not
disrupt
anyone
by
sending
it
at
the
end
of
their
work
day.
Yes,
we
kept
it
very
short
just
two
minutes
and
then,
in
addition
to
that,
they
seem
to
get
benefit
just
by
doing
the
self-reflection
itself.
B
Everything
I
said
so
far
has
been
on
the
individual
developer
bases,
so
every
individual
is
getting
the
data
and
it's
giving
us
their
satisfaction
and
responses.
We
also
did
analysis
across
the
board.
We
shared
that
in
the
blog
post
as
well,
and
here
we
found
things
that
we
were
kind
of
expecting
to
find,
but
it's
good
to
put
numbers
on
it
and
be
able
to
talk
about
it
with
like
something
more
solid.
B
We
found
just
how
important
being
in
that
sense
set
a
state
of
flow
and
state
of
concentration
is
to
developers
because
it
can
take
them
from
like
82
chance
of
having
a
good
day.
If
you
only
have
mild
interruptions
or
no
interruptions,
all
the
way
down
to
7
chance
of
having
a
good
day
if
you're
having
interruptions
throughout
the
day.
B
It
was
eye-opening
for
us
as
the
research
team
that
it
had
such
an
impact,
and
then
we
found,
of
course,
that
there's
a
lot
of
really
good
research
that
has
been
done
in
other
domains
about
the
value
of
reflection,
there's
also
work
that
has
happened
in
like
software
development
that
has
to
do
with
kind
of.
In
retrospect,
looking
at
the
goals
you
had
and
the
practices
you
did
and
revising
your
work
habits
and
so
on.
So
it
seems
to
be
a
very
persistent
theme.
B
B
Okay,
I
will
show-
let's
see
yes,
I
will
show
do.
Can
you
see
my
slack
yep?
Okay,
all
right.
So
what
I
wanted
to
show
here
is
like
an
idea
we're
playing
with,
because
the
the
good
day
project
was
like
cool
and
everybody
loved
it
and
so
on
with
the
40
people
that
we
had,
and
it
was
very,
very
manual.
So
it
was
like
me
behind
the
scenes,
like
writing
up
emails
and
sending
surveyed
links
to
people
every
day
and
putting
things
in
spreadsheets
and
so
on.
B
B
They
build
like
prototypes
of
tools
that
are
amazing
and
get
a
lot
of
value
for
developers
and
partnering
with
them,
and
they
created
a
slack
bot
for
us
called
the
good
day
slackbot,
and
they
came
up
with
a
very
simple
and
very
elegant
solution
about
how
to
do
the
whole
good
day.
You
know
process
it
starts
with
creating
a
github
repo
and
I'm
not
gonna,
I'm
not
gonna
demo.
It
necessarily
because
I've
set
all
mine
up
and
I
don't
want
to
break
it
and
I
didn't
create
extra
accounts
or
anything.
B
But
I
did
want
to
to
say
a
couple
of
things
about
the
process.
This
is
to
be
able
to
in
a
simple
way,
deliver
the
daily
surveys
to
people
and
then
collect
the
responses
and
park
them
somewhere
and
and
that
somewhere
it
can
be
anywhere
because
we're
really
interested
and
we
want
to
safeguard
the
privacy.
So
the
octo
team
said
basically
okay,
so
why
don't
we
use
github
private
repos
for
that?
B
So
when
you
set
up
the
slack
bot
to
work
for
you
like
the
good
day
slack
bot,
the
first
thing
it
asks
you
to
do
is
to
create
a
new
private,
github
repo
and
then
to
invite
the
good
day
bought
as
a
collaborator
in
that
repo,
and
that
gives
it
right
access
and
every
time
it
collects
information
from
you
through
a
slack
form,
which
I
will
show
you
and
it
just
like,
goes
and
puts
it
in
in
in
that
repository.
So,
for
example,
you
can
see
mine
is
like
my
handle
and
good
day.
B
B
Is
that
every
day
at
that
time,
you'll
get
a
ping?
Yes,
I
have
two
days
here,
although
it's
not
5
pm,
because
I
wanted
to
demonstrate
with
today's
date
and
it
gives
you
this
form
to
to
fill
out,
especially
essentially
and
so
you'll
see.
This
has
all
the
questions
from
the
survey.
These
questions
are
the
questions
that
we
have
at
the
bottom
of
the
blog
post.
B
So
you
all
have
like
access
to
what
those
questions
are
and
also
the
options,
and
so
what
I
would
do
is
to
say:
okay,
my
work
day
today
was
awesome
because
I'm
here
talking
to
you
and
everything
else,
I'm
just
gonna
put
random
stuff
in
and
once
we're
done
with
all
of
that,
wow
I'm
not
inspired
at
all.
I
feel
no,
I
feel
so
excited
come
on
all
right
and
late
afternoon
and,
let's
say
outside
of
typical
work
hours,
and
I
save
my
responses
until
that.
I
have
my
little
rebo
here.
B
That
delivers
the
information
that
collects
the
information
and
puts
it
somewhere,
but
the
the
the
main
effort
or
the
main.
I
guess
new
thing
here
was:
what
is
it
that
you
ask
people
and
how
often
do
you
ask
them?
So
it
was
the
mechanics
of
the
of
the
approach,
and
that's
something
that
is
one
of
my
takeaways
for
everyone
here
is
that
this
is
something
that
anyone
can
do,
and
I
mean
literally
anyone
can
do.
You
need
the
questions
which
you
have
and
you
need
a
place
to
collect
your
information.
B
Sure
it's
better
to
do
it
with
the
tool,
because
then
you
don't
have
to
spend
the
energy
and
the
time
to
collect
the
data.
But
if
you
wanted
to
get
started
with
this
today,
you
could
you
can
take
the
questions
you
can
open.
You
know
you
can
write
it
on
your
notepad
or
you
can
open
a
spreadsheet
and
you
can
start
entering
the
information.
Then
you
rinse
and
repeat,
and
you
do
it
every
day
for
a
while
and
then
you
you
go
back
and
you
look
through
the
data.
B
That
is
also
one
of
the
takeaways
that
the
self-reflection
is
the
key.
Here.
That's
the
key
to
the
success
of
this.
It's
that
it
gets
you
in
a
habit
of
self-reflection,
and
that
brings
benefit
in
itself
because
it
makes
you
aware
of
things
that
you
were
not
made
aware
of
before,
and
you
can
you
start
getting
ideas
of
what
to
improve
in
your
days
or
what
to
to
start
avoiding
in
your
days.
B
So
for
me,
as
I
said,
you
want
to
get
started
with
this
today,
you
can
and
that's
that's
pretty
powerful
when
it
comes
to
thinking
about
productivity
and
how
to
improve
your
productivity,
and
it
also
plays
into
the
last
part.
I'm
a
firm
believer
like
metrics
are
not
an
end
in
the
in
themselves.
They're
they're
a
means
to
an
end
and
they
are
used.
They
are
supposed
to
be
used
to
support,
self-improvement
and
that's
what
we
did
here.
B
So
it's
important
to
say
what
the
data
and
the
metrics
and
everything
I
showed
you
today
is
good
for
and
what
it
is
not
good
for.
I
would
never
use
this
information
or
ask
anyone
to
use
this
information
to
do
any
sort
of,
for
example,
performance
evaluation,
a
performance
review
or
decide
whether
they're
going
to
you
know,
give
someone
a
promotion
or
something
like
that.
It's
not
meant
for
that.
What
it
is
meant
for
is
for
self-improvement
for
showing
someone
how
they're
doing
and
prompting
them
to
action
and
finding
ideas
to
self-improve.
B
B
That's
all
I
have
today
I've
put
a
few
resources
here
on
the
slide
in
terms
of
like
the
the
paper
that
talks
about
space,
then
there's
nicole
foursquare
has
given
a
talk
recently
about
it,
so
you
can
find
more
information
about
that
and
we
can
do
questions.
I
don't
know
how
much
time
we
have,
but
whatever
time
we
have
is
yours,
I'm
just
gonna.
Stop
sharing.
A
A
B
We
structured
so
the
surveys
are
for
every
individual
person
right.
So
it's
not.
It
doesn't
really
matter
if
you're
working
with
people
in
other
time
zones,
you
are
going
to
get
this
survey
in
your
time
zone
and
the
questions
that
you
are
asked
every
day
are
questions
about.
Did
you
work
with
others,
or
did
you
help
others
today
and
so
on?
But
it's
based
on
your
view
of
how
much
that
happened
in
your
day.
B
A
A
How
do
we
use
this
to
measure
how
we're
doing
and
what
can
we
do
to
improve,
whereas
it's
more
of
a
the
value
of
self-reflection
and
awareness
of
your
own
workflows
and
kind
of
making
the
productivity
change
from
within,
rather
than
it
being
a
looking
at
a
scoreboard
and
saying
okay,
we're
behind
in
these
areas?
Now?
What
do
we
need
to
do
to
to
affect
change.
B
Yeah,
I
I
see
it
a
little
bit
as
kind
of
like
looking
in
the
mirror,
in
the
literal
sense,
like
someone
like
brought
a
mirror
in
front
of
you,
like
imagine,
trying
to
get
dressed
every
day
and,
like
you
have
no
idea
what
you
look
like
in
the
end,
because
you
don't
you
don't
have
any
like
feedback
on
what
you
look
like
and
it's
obviously
an
overly
simplified
example.
But
the
principle
is
the
same:
you
don't
really
we're
not
aware
of
our
patterns
until
we
see
them
in
front
of
us.
B
B
That's
the
time
that
I
need
to
be
very
defensive
about,
and
then
they
get
the
information
based
on
their
10
days
of
survey-
and
I
was
like,
oh,
I
guess
late
afternoon-
is
the
time
that
I
most
consistently
I'm
feel
most
productive
right
and
that's
very
powerful
to
know
you
don't
know
it
until
you
see
it
in
this
aggregated
way
in
front
of
you
and
then
you
can
use
it
right
away
now.
I
know
how
to
structure
my
day,
given
that's
where
my
energy
is
going
to
go.
A
B
Yes,
that's
an
excellent
question
and
I
think
that
the
the
fact
that
this
is
individual
to
the
person
takes
away
some
of
the
pressure
of
defining
good
or
awesome
or
any
of
these
characterizations
in
kind
of
like
a
global
way.
It
doesn't
matter
if
my
awesome,
if
someone
else
is
good
or
someone
else,
is
bad,
because
I'm
only
answering
questions
about
myself.
So
as
long
as
I
know
what
awesome
means
to
me
we're
good
like
there's.
No,
you
know
contamination
of
the
data
or
anything
like
that.
B
It
also
takes
the
pressure
of
trying
to
define
it
for
everyone
right,
because
who
am
I
to
say
what
is
an
awesome
day
or
is
what
is
an
awesome
feeling?
It
is
asking
for
the
sentiment.
So
yes,
it's
very
much
based
on
like
the
emotional
aspect
of
what
did
today
feel
like
to
you
and
then
we
have
all
the
other
questions
in
the
survey
that
prompts
about
progress,
quality
amount
of
doing
things
and
so
on,
but
that
one
question
is
asking
about
their
emotion
and
it's
particular
to
them.
B
A
B
Not
public,
it's
not
publicly
available
already,
because
it's
we're
working
through
a
few
bugs.
Then
we
have
to
release
it
to
our
own
engineers
at
github,
and
then
we
would
have
someone
that
owns
it
as
a
product
or
we
open
sources
which,
which
is
the
also
part
of
the
current
thinking
so
charge.
Is
it's
a
pretty
fun
idea
to
play
with
and
we're
still
experimenting
with
it
and
would
love
to
get
it
to
people
that
would
be
super
fun.
C
A
B
A
Oh
no
thank
you.
You
really
raised
a
lot
of
curiosity
in
the
chat
and
it
was
awesome
to
see
people
really
trying
to
dig
in
and
understand
this,
and
it's
it's
important
to
point
out
like
these
are
definitely
novel,
notions
and
ways
of
thinking
about
things,
and
it
also
involves
a
lot
of
overcoming
what
are
kind
of
our
conditioned
ways
of
looking
at
surveys,
data,
metrics
productivity
and
all
that.