►
Description
In late FY21Q3 we had a call to discuss and share tips on efficient shipping of work.
This video captured that call and the following document the agenda:
https://docs.google.com/document/d/e/2PACX-1vR0JtQDIA8C0wjH9J2AvEDmOqBB05ddIISNs6UNDcRO6xSmOO_H7VQkI2TifHc87BK0KmAQegKaNssQ/pub
A
So
the
way
that
we
have
this
sorted
out
is
the
call
will
be
split
into
five
sections
I'll
be
trying
my
best
to
keep
time
for
each
one
of
them
we'll
be
covering
them
well,
one
at
a
time,
and
the
idea
is
just
I'll,
throw
some
questions
around
and
you
please
pick
up
and
just
share
your
your
thoughts
or
tips
or
how
you
usually
handle
them.
How
you've
been
having
success
here,
we're
looking
for
examples
of
success.
Not
so
much
of
things
that
need
to
be
improved
is
like.
A
How
can
we
improve
them?
What's
the
things
that
we
can
do
on
a
daily
basis
to
not
just
succeed
on
ourselves,
but
also
helping
others
succeed
on
shipping?
That's
the
thing
the
focus
is
on
on
smooth
shipping
continuously
shipping
and
being
good
at
shipping,
so
yeah.
The
other
thing
I
would
ask
is
just
yeah:
try
try
your
best
to
speak
up
and
mention
your
things,
but
be
succinct
in
your
own
explanation,
so
that
we
have
time
for
everyone
else
to
go
and
yeah.
A
A
B
For
me,
when
I
go
through
like
manage
a
complexity,
it's
just
great
things,
breaking
things
apart,
keeping
things
in
smaller
scope
like,
for
example,
this
one's
going
to
be
focused
on
one
area
and
then
I'll
create
another
mr
to
manage
another
area.
Just
when
you
break
things
apart,
a
it's
smaller,
mr
and
b,
that
allows
people
to
review
it
very
quickly.
So,
instead
of
having
like
a
huge
amount
of
changes
to
review,
you
have
smaller,
mrs
faster
review
and
faster
shipping
time.
A
C
I
just
wanna
go
back
a
little
bit
on
technical
debt.
I
think
it's
good
to
understand
that
technology
is
sort
of
okay
as
long
as
it's
then
a
follow-up
to
fix
the
technical
debt
yeah.
I
think
sometimes
the
boring
solution
that
we
should
aim
for
and
nine
times
that
time
probably
has
some
technique
in
it,
because
it's
not
always
the
way
we
want
to
do
it.
A
A
A
Revising
questioning
our
approaches
and
rethinking
them
like
double
checking,
making
sure
that
we're
keeping
it
the
simplest,
acceptable
solution
and
not
letting
ourselves
go
too
much
on
the
oh
there's
a
great
way
of
doing
this,
but
I
need
to
clean
that
part.
So
let
me
see
how
we
can
summarize
this.
I
was
asking
you
all
to
be
six
cent
and
I'm
here,
rambling
yeah,
okay.
A
So
let's
put
it
that
way:
keeping
the
goal
on
shipping
a
solution
that
favors
the
user
like
having
the
user
in
mind
when
building
the
solution,
because
if
it's
something
that
is
invisible
to
the
user-
and
it's
only
for
me,
then
I
have
to
make
sure
that
I
have
time
for
it.
It
won't
impact
the
shipment
of
other
things.
A
A
A
A
A
A
If
you
have
have
something
that
you
want
to
work
on
to
improve
open
an
issue
like
technical
debt,
you
can
you
can
accept
some
technical
debt
going
in
as
long
as
you
have
an
issue
prepared
for
it,
and
you
can
argue
for
it
to
be
scheduled
right
after
that.
That's
the
the
gist
of
what
we
were
just
discussing,
yeah
anything
else
from
your
site
how
to
avoid
going
overly
complex-
and
I
know
this
is
something
that
we've
been
discussing
as
a
team,
because
our
code
base
is
very
complex.
A
E
We
we
say
we
avoid
complexity
by
just
sort
of
following
the
same
sort
of
patterns
that
we
already
have,
but
they
are
already
complex,
and
so
sometimes
I
I
question
whether
we're
not
just
adding
to
the
complexity
by
not
avoiding
the
complexities
so
like.
Sometimes
I'm
really
bad
at
this
is
what
I'm
kind
of
getting
at
is
I'm
always
I'm
trying
to
undo
some
complexity
that
we
already
have,
which
is
it
itself
complex?
That's.
A
E
A
E
A
Think
there's
one
thing
there,
thomas,
let
me
unpack
that
which
is
the
temptation
of
reusing,
something
that
it's
in
the
code
base,
just
because
it's
in
the
code
base
it's
high
because
it's
there
and
we
end
up
spreading
complexity
and
and
and
in
that
sense
we
end
up
just
spreading
complexity
around
now,
going
back
to
shipping
how
like,
what's
the
most,
the
most
productive
decision
there.
So,
let's
see
we
have
something
that
we
need
to
copy
like
a
behavior
or
something,
and
we
already
have
something
like
that
in
the
code
base.
A
C
Yeah,
I
don't
know,
I
don't
know
yeah,
I'm
just
so
used
to
the
leg
secret.
I
just
don't
even
think
about
it
anymore.
Really,
it's
just
becoming
the
legacy
is
just
part
of
my
brain.
Is
that
it's
just
I
figure
they'll
just
use
it.
It
works.
I
think
that's
what
we
need.
Some
sense.
That
is
the
complexity
effect
in
the
end
result.
A
So
but
I
think,
there's
value
there,
which
is
you
said
something
really
good,
which
is
to
keep
in
mind
whether
this
will
help
the
user
or
not
and
then
coming
back
later
to
fix
it,
which
it
kind
of
feels
against
avoiding
complexity
but
in
a
way
you're
keeping
in
mind
the
shipment
of
the
solution,
and
I
think
we
have
a
great
example
recently
where
samantha
was
doing
on
the
reviewers
and
we
were
just
like
hey.
We
have
the
drop
downs
for
the
assignees
they're
completely
like
it's
old.
A
But
that
example
to
me
speaks
to
this
that
you're
saying
like
it
was
old
code
base.
We
spread
it
around,
so
we've
made
the
product
more.
The
code
base
more
complex
in
the
complex
and
we
even
committed
the
the
the
sin
of
repeating
ourselves.
So
we
didn't,
if
I'm
not
mistaken,
please
correct
me
if
I'm
wrong
samantha,
but
we
accepted
that
cost
because
he
got
us
over
the
line
and
I
think
that's
a
good
example
right.
Anyone
disagrees.
C
Yeah
I
I
just
really
want
to
point
out
that
example,
I'm
pretty
certain
that
we
know
the
conversation
one-on-one
on
one
where
I
specifically
said
we
should
go
for
the
end
solution
of
the
drop
down,
and
that
was
like
a
super
complex
adam,
so
glad
that
we
didn't
go
that
way
and
we
reused
something
and
sort
of
reduced
the
complexity.
So
yeah
right.
That's
good
example.
Teeth.
A
Awesome,
that's
good
to
know
okay,
and
I
I
do
think
that
is
that
is
worthwhile
keeping
in
mind
when
you're
doing
these
sort
of
things,
which
it
feels
very
counter-intuitive
on
it.
Right,
if,
like
like
thomas,
was
saying
like
I'm
spreading
complexity,
I'm
making
it
worse
but
understanding
it
in
the
mind
of
the
road
map.
If
you
take
a
look
that
right
after
that,
we
have
another
issue
to
actually
build
the
right
thing.
A
It
allows
us
to
get
to
market
really
quickly,
and
that's
that's
what
we're
talking
about
here,
like
keeping
the
shipping
in
mind
and
having
that
as
the
the
number
one
priority,
and
I
think
one
of
the
things
that
I
would
add
here
is
the
engineers
by
nature.
Don't
like
throwing
away
code,
that's
something
like
I
I
took
so
long.
I
I
took
some
time
writing
this
code.
A
I
don't
want
to
trash
it,
but
if
that
gets
us
over
the
line
earlier
like
to
have
that
like
an
afternoon
of
coding
or
a
day
of
coding,
that
will
get
me
over
the
line.
Instead
of
spending
two
weeks
of
coding
a
feature,
that's
worthwhile,
it
will
get
the
feature
out
and
then
we
can
go
back,
throw
that
out
put
in
the
new
code
base.
A
I
think
this
is
a
harder
problem
for
ux,
because
users
will
see
different
things
like
very
very
quickly,
but
that's
something
that
we
can
live
with
with
our
own
product
approach,
so
yeah.
So
basically,
I
think
the
the
bottom
line
here
just
to
get
comfortable
with
throwing
away
code
if
it
gets
us
over
the
line
earlier
kind
of
thing.
C
It
would
be
good
so
know
where
the
complexity
comes
from.
Is
the
complexity
coming
from
the
product
side,
the
ux
side
or
the
code
sound,
because
the
kind
of
different
things
like
product
will
always
aim
to
get
the
best
solution?
First,
ux
are
sort
of
aimed
for
like
that
as
well,
and
then
really,
the
solution
that
we
can
go
for
is
probably
the
one
that
gets
us
there
quicker,
which
probably
doesn't
really
match
what
product
won't
waste.
The
time.
A
One
of
the
things
that
I
that
I
always
think
is
when
we're
looking
at
mock-ups
from
designs
from
designers,
see
that
as
the
intention,
but
not
necessarily
the
best
code
approach,
so
question
those
the
mockups
are
guidelines,
they're,
not
contracts
and
there's
there's
we
have
the
benefit
of
having
a
great
designer
on
our
team.
That
is
very
understanding
when
we
negotiate
with
them
about
hey.
A
We
can
do
this
in
like
two
weeks
or
we
can
ship
this
in
a
day
if
we
just
reuse
this
component,
it's
slightly
different,
it's
not
the
same
experience,
but
what
do
you
think
about
this
and
that's
a
conversation
that
we
can
totally
have
like
trying
to
negotiate
with
with
the
designers
and
with
product
too?
If
that's
the
case,
I
feel
like
that's
something
that
we
need
to
keep
in
mind
and
I
always
go
back
to.
A
John
gruber's
talk
on
the
author
theory
of
design
I'll
get
the
link
in
the
document
because
he
says
the
front-end
or
basically
the
developers
are
the
last
people
to
touch
the
code,
the
thing
that
would
be
shipping
and
we
have
not
just
the
opportunity,
but
we
have
the
responsibility
to
to
own
that
if
the
designers
are
sending
us
something
that
is
broken
or
we
experience
it
and
we
don't
like
it,
it's
totally
our
responsibility
to
bring
it
up
to
them
and
hey.
Look.
A
I
have
this
solution,
it's
far
better,
it's
quicker
so
that
conversation
needs
to
happen,
keeping
in
mind
always
the
time
to
shipping
like
if
it
if
it
decreases
the
time
to
ship,
definitely
invest
in
that
conversation,
if
it
increases,
try
to
find
other
ways
to
to
get
that
over
the
line.
But
just
keeping
that
in
mind
is
definitely
something
that
is
important.
We're
the
last
line
before
people
say:
users
don't
interact
with
mockups.
That's
why
I
use
that
line.
A
E
I
find
that
this
is.
This
is
hard
to
do
sometimes
because
at
least
at
least
in
my
interactions
like
with
pedro
he's,
always
pushing
for
like
the
next
best
thing,
and
it's
always
like
just
a
tiny
bit
more.
It's
like.
Oh
what,
if
there
was
like
one
other
click
interaction
here
or
something,
and
I
can
almost
always
accommodate
those.
But
it's
like
one
more
review
cycle
or
one
more
thing,
and
so
it's
just
like
yeah,
it's
totally
feasible.
A
Think
yeah,
you
bring
up
a
very
good
point
designers
when
they're
doing
the
review,
like
they'll,
always
have
a
few
things
that
they
would
like.
They
need
to
tweak
and
we
throwing.
I
think
you
you
bring
up
something
very
useful
on
the
retrospective
the
this
month.
Where,
like,
is
this
a
blocker
like
that
conversation
like-
and
I
remember
cement,
does
this
very
well
where
there
was
a?
A
That
conversation
needs
to
be
there
there
as
well.
So
in
your
situation,
what
I
would
say
is
just
see
if
we
can
bundle
them
up
into
a
separate
issue
like
oh
yeah,
that
that
that
that
okay,
can
we
do
that
right
after
this
a
separate,
mr,
but
yes,
it's
easy
to
follow
in
the
temptation
that
I'll
just
add
it.
There.
B
Definitely
I
just
want
to
add
it's.
It
was
so
challenging
when
I,
when
I
first
started
to
like
designer
love
to
add
that
one
more
thing,
one
more
thing,
one
more
thing
and
as
engineers
we
always
try
to
accommodate
that.
But
what
I
realized
that
that
one
more
thing
leads
to
a
longer
review
time
and
even
if
it's
tiny,
even
they
go.
Oh,
this
is
just
a
tiny
change.
I'm
like
this
is
out
of
the
original
scope.
I
go.
B
So
sometimes
it's
I
know
it's
challenging,
but
I
think
it's
as
engineers
like
understand,
focus
on
shipping
and
say:
hey.
Is
it
okay?
If
I
create
a
follow-up
for
this
and
if
they
say
no
they're
like
oh,
this
is
paramount,
then
we
can
address
it
and
then
you
can
always
go
about
hey.
This
is
why
the
review
time
got
delayed,
because
this
was
paramount
to
the
ship.
So
sometimes
you
can
ask
that
question.
Hey.
Is
this
necessary
for
this
iteration?
B
A
I'll
add
one
thing
there.
I
remember
doing
ux
reviews
that
were
very
detailed,
like
pixel
off
misalignment,
that
sort
of
thing
when
we
get
those
lists
with
screenshots,
we've
all
seen
them
jump
on
a
call.
I
know
that
sometimes
it's
hard
and
its
counter.
Our
value
is
to
be
synchronous,
but
in
those
cases
I've
had
really
productive
calls
with
designers
where
it's
like.
I'm
review,
they're
reviewing
my
code
and
they
have
a
bunch
of
like
pixel,
perfect
adjustments
and
stuff
like
hey.
Are
you
around?
A
Let's
jump
on
a
call,
and
we
just
blaze
through
them
in
like
10
minutes
and
like
we
tweak
them
share
the
screen.
We
fix
the
code
and
he's
like
far
more
productive.
I
know
that
time
time
zones
are
an
issue
here
with
our
team,
but
instead
of
like
taking
two
cycles
right,
you
doing
the
thing
and
then
sending
it
to
them.
You're
doing
it
right
away
there
and
you
can
work
on
other
stuff
in
the
meantime.
A
A
A
Right,
so,
if
you
do
remember
anything
else
later
on
the
complexity,
we
can
come
back
to
it,
moving
on
section
two,
so
juggling
parallel
work,
as
we
were
discussing
earlier.
The
time
that
we
take
on
one
deliverable
impacts
the
time
that
we
have
available
for
the
other,
that's
something
that
needs
to
be
on
our
minds
constantly!
That's
why
we
do
the
kickoff
early
we
set
up.
A
You
all
started
to
kind
of
like
forecast
the
plans
per
week
more
or
less
in
your
minds,
and
that's
because
we
need
to
prepare
for
the
capacity
that
we're
going
to
need
later
for
other
work
and
as
we're
waiting
for
reviews
from
the
current
deliverables.
That's
the
good
opportunity
for
us
to
jump
on
another
stuff
that
is
waiting,
but
how
do
you
avoid
being
overwhelmed
by
multiple
topics
in
flight?
Any
tips.
E
This
has
been
like
super
top
of
mind
for
me
recently.
Obviously,
so
I
can't
say
that
I'm
like
an
expert
at
this,
but
I
think
the
thing
that's
been
working
for
me
this
week,
at
least,
has
been.
I
have
lots
of
things
lingering
that
just
like
aren't
closing
out,
but
what
I'm
doing
is
like
anytime,
something
pops
up.
E
If,
if
the
oldest
one
takes
priorities
like
the
longest
running
thing
takes
priority-
and
I
just
I
work
on
that
until
it
is
until
it
is
out
of
my
court
again
and
then
it
like
gets,
I
shut
it
down
and
I
move
to
the
next
oldest
thing.
So
that's
that's
been
kind
of
my
tact
right
now
of
of
avoiding
like
having
to
work
on
multiple
things
at
once.
Unfortunately,
I
do
like
so
so,
if
something
pops
up
like
an
old
review
that
it
keeps
coming
back.
E
D
Okay,
I
didn't
want
to
interrupt
yeah
for
me.
I
have
a
hard
time
context.
Switching
and
I
found
that
when
I
divide
my
days
very
concretely,
that's
helped
me
a
bunch
so
first
thing
in
the
morning
I
check
email
and
do
all
of
my
reviews
and
things
that
kind
of
popped
up
overnight
and
that's
usually
when
I'll
handle
any
reviews
that
I
have
in
flight
and
usually
takes
me
through
to
lunch.
D
A
A
D
That's
an
excellent
point
because
my
day
is
structured.
That
way,
because
most
of
my
reviews
and
feedback
come
from
europe,
whereas
I
guess
never
does,
whereas
I'm
in
central
times
in
the
united
states.
That
way,
I
can
address
ideally
their
issues
before
they're
gone
for
the
day
and
let
them
without
blocking
them
too
much
so
yeah.
It's
an
excellent
point
to
keep
in
mind
is
where
you
are
in
relation
to
the
rest
of
your.
D
A
C
So
we're
kind
of
lucky,
maybe
a
bit
or
looking
the
fact
that
our
pipelines
kind
of
take
a
long
time
to
run
normally
when
the
pipelines
are
running.
We
sort
of
have
enough
down
time
to
then
go
to
the
next
one,
but
yeah
I
slipped
my
days
off
pretty
much
just
saying
my
mornings.
Normally
reviews
for
me
to
do
is
the
bottom
upwards.
I
ignore
any
stuff,
that's
unrelated
to
my
work.
That'll
go
last
in
the
queue
and
then
based
on
them
things
that
are
less
than
the
queue
of
my
stuff.
C
I'll,
take
the
more
complex
ones.
First
or
maybe
it
depends
some
of
them
like
it's
super
easy,
and
I
can
like
get
them
out
kind
of
quick
and
maybe
it's
like
a
few
little
lines,
code,
changes
or
whatever,
and
they
can
get
out
quite
quick
and
then
they're
off
my
plate
all
together
and
they
can
focus
more
on
the
complex
ones
or
sometimes
the
complex
ones
are
a
bit
more
urgent
and
they'll
go
first,
so
it
sort
of
depends
at
once
to
month,
but
that's
all
my
days
go
away.
A
Yeah,
I'm
gonna,
ask
you
a
question.
You
started
by
saying:
yes,
since
the
pipelines
take
a
long
time,
we
have
time
to
jump
on
other
things,
but
don't
you
ever
like
start
too
many
threads,
and
I
know
that
you
somehow
master
this
I've
seen
you
like
handle
like
five
threads
at
a
time
and
and
not
skip
a
beat.
Is
there
anything
in
particular
that
you
do
to
to
keep
them
running
into
it,
running
its
course,
because
it's
easy
to
keep
jumping
around
jumping
around
and
you
never
take
it
to
completion?
C
C
It
used
to
be
slightly
different,
and
maybe
that's
how
I
learned
is
that
previously,
when
I,
when
I
first
drank
it
like,
we
would
pick
from
a
big
long
list
of
issues
to
work
on
whenever
we
wanted
to
do,
and
you
would
never
get
the
same
wax.
You
would
never
have
be
given
multiple
things
to
work
on
once
you
choose
it.
So,
when
you've
finished
working
unless
you're
in
the
pipelines
you
run
and
they
used
to
take
much
longer
like
maybe
up
to
two
hours
it
would
take.
C
E
That
you
used
to
just
kind
of
pick
issues
as
soon
as
you
were
ready
for
them,
because
that's
actually
something
that
samantha
brought
up
in
either
this
retro
or
the
last
retro
of
like
the
more
of
the
kanban
style
of
like
just
pull
issues
down
when
you're
ready
for
them.
I
guess
we
moved
away
from
that,
so
that
we
can
have
more
like
cohesive
product
releases.
A
Kind
of
predictability
is
a
big
thing,
and
the
thing
is
not
all
not
all
issues
is
kind
of
the
same,
so
the
kanban
style
is
like.
You
have
a
linear,
pile
and
people
will
take
off
the
top
right,
but,
for
example,
that
that
kind
of
it's
great
for
sharing
knowledge
and
circulating
knowledge,
for
example,
approval
rules,
instead
of
being
something
that
mostly
samantha
worked
on
or
or
the
repository
browser,
or
something
that
mostly
fill
would
work.
A
A
A
A
So
I
think
that's
something
that
if
you're
struggling
with
this,
that's
something
I've
recommended
to
some
of
you
in
the
past
to
limit
the
time
the
the
amount
of
stuff
that
you
open
up.
The
one
thing
that
I
would
say
is
using
your
best
judgment,
because
if
you
have
two
things
in
flight
and
you
have
those
two
in
review
and
those
are
feature
work
and
you
have
like
a
copy
update
of
a
bug,
then
that's
kind
of
like
no
cognitive
overload.
That's
just
like
updating
the
copy
shipping.
A
It
that's
something
you
can
still
pick
up
and
go
over
your
limit
right.
So
using
a
common
sense
approach
on
there.
Like
can
I
go
over
the
limit?
Should
I
should-
and
I
it's
it's
up
to
you
really,
but
it
would
stop
you
from
picking
up
another
complex
work
because
complex
work
is
the
thing
that's
going
to
take
multiple
iteration
overviews
and
a
lot
of
cognitive
load
from
your
side,
so
yeah
kind
of
like
a
gray
area,
not
a
soft
limit
kind
of
thing.
C
A
C
A
C
Just
broadly
yeah,
okay
seriously
thought
it's
kind
of
like
it
was
the
biggest
thing
that
we've
done
at
the
time.
It
was
tech,
wasn't
technically
the
first
few
feature,
but
it
was
like
the
biggest
new
feature
that
would
be
done.
We
got
given,
I
didn't
even
know
it
didn't
work
from
like.
I
think
we
went
from
like
the
21st
or
every
month
to
the
21st.
It
was
kind
of
like
chaotic.
C
If
there
was
a
bug
on
the
last
days,
but
five
times
out
of
ten,
wouldn't
you
wouldn't
be
able
to
fix
the
book
full
of
shipping.
We
did
the
front-end
back-end,
both
in
the
same
branch.
It
was
had
like
a
ridiculous
amount
of
changes
in
it
and
we
had
so
many
different
people
reviewing
it.
The
front
of
them
was
done
in
about
it
probably
took
the
front
end.
We
were
just
over
a
week
to
finish
the
back.
C
End
was
roughly
done
in
the
same
amount
of
time
and
that
took
maybe
another
week
or
so
just
to
finish
off
the
test
and
get
it
done.
It
probably
took
us,
maybe
like
three
weeks
to
take
it
from
start
to
actual
finish
and
bear
in
mind.
This
is
the
point
of
where
we
didn't
really
have
any
guidelines
in
how
to
do
view
most
of
the
people
that
get
like
hadn't
even
looked
at
few.
C
C
A
Now
we
all
understand
that
this
is
anecdotal,
like
we
know
that
we're
not
living
in
that
maturity
stage
anymore
like
it's.
So
we
have.
We
understand
that
right,
but
I
feel
like
this
speaks
to
to
how
to
those
learned
behaviors
that
phil
was
speaking
earlier
right,
just
just
constantly
being
shipped
and
and
just
be
like
that
bias
for
shipping
is
there,
which
I
think
we
sometimes
coming
into
a
later
stage
in
the
company.
A
We
can
learn
the
other
behavior,
which
is
to
be
very
protective
of
what
we
ship
to
be.
Very.
I
don't
know
if
this
is
ready,
so
I
won't
be
shipping
this
until
I'm
very,
very,
very,
very
sure,
so,
there's
something
there
that
we
can
learn
in
that
as
we're
getting
more
confident
with
the
code
base
and
everything
keeping
the
focus
on
shipping
constantly
is
something
we
can
learn
so
that
bias
for
shipping
cool.
I
do.
A
I
would
say
also
that
adding
something
new
to
the
code
base
is
always
easier
than
I
would
say
easier
than
maintaining
something
and
adding
on
top
of
existing
code
base,
so
that
disclaimer
as
well
all
right.
Let's
look
at
the
time
right.
Wrapping
up
the
section
two,
any
more
thoughts
on
juggling
complexity.
A
No
all
right,
so
we
can
go
on
to
smooth
reviews
all
right.
So
a
big
part
of
what
we
do
is
reviews
and
having
our
code
reviewed
and
all
of
us
do
code
reviews.
So
we
are
on
both
sides,
both
on
the
author
side
and
also
on
the
reviewer
side.
So
we
know
kind
of
what
we
like
to
get
from
authors
as
a
reviewer.
So
I
throw
the
question
out
there
like
is
there
anything
particular
that
you
do
to
prepare
your
work
to
help
the
reviewers
and
how
do?
D
I
would
say
my
number
one
thing
with
getting
changes
from
reviewers
is
always
put
them
in
a
separate
commit,
don't
like
force
them
into
the
same.
You
can
amend
without
editing
a
commit
and
get,
and
I
hate
when
people
do
that.
I've
had
that
happen
several
times
where
I'll
give
somebody
a
bunch
of
feedback
and
they'll
make.
You
know
three
or
four
dozen
lines
of
code
changes
squashed
in
the
same
commit,
and
now
I
can't
see
the
difference
easily.
D
So
if
you
always
put
that
in
a
new
commit
and
then
squash
it
later
like
andre's,
a
big
fan
of
fix
up-
and
I
am
now
as
well-
that
makes
from
a
viewer's
perspective
way
way
simpler
and
even
from
a
coding
perspective
when
I'm
working
on
it.
It
helps
me
keep
track
of
what
I've
addressed
and
what
I
have
it
when
I've
spread
them
out
over
new
commits.
E
I
think
this
drop
downs
are
still
broken.
I
don't
think
that.
I
don't
think
that
it's
last
I
knew
it
always
compared
against
ted.
You
could
never
compare
against,
like
whatever
version
you
select
always
compared
against
latest,
so
you
can
never
compare
against
like
the
last
two
versions,
for
example,.
A
A
A
Okay,
so
bugs
aside,
I
wanted
to
address
this
because
I
think
that's
what
justin
said
about
easily
right,
because,
if
you
think
about
like,
if
you
do
a
rebase,
that's
going
to
throw
another
version
on
the
mr,
if
you
do
another
push
you're
going
to
do
another
another
version
of
the
mr,
and
sometimes
you
have
like
eight
unnamed
versions.
The
unnamed
part
to
me
is
the
killer
that,
yes,
it's
useful
to
have
the
comparison,
but
it's
not
easy
right.
A
If
you
have
it
by
commit
like
address,
address
comments
regarding
tests
or
something
it's
far
easier
for
the
reviewer
to
go
in
there
and
just
click
the
commit
and
navigate
per
commit.
So
it's
easier
but
you're
right
like
that's
what
the
versions
are
for.
The
drop
downs
are
four
but,
as
we
see
they're,
not
easy
to
use
for
that
particular
case
now,
do
we
see
this
from
a
reviewer
perspective?
Do
you
think
that
this
helps?
This
is
for
everyone
like
having
a
separate
commit
for
the
changes.
A
Okay,
from
my
perspective
as
a
reviewer,
it
definitely
makes
more.
It
definitely
makes
me
quicker
to
review
the
second
iteration
of
the
review
when
I
can
clearly
see
what
was
changed.
So
I
definitely
agree
with
that.
This
makes
it
easier
for
reviewers
to
even
if
they
don't
appreciate-
or
you
know,
even
if
they
don't
notice
it
it's
tidier.
Now
it
still
asks
the
question
about.
So
when
do
we
squash
it?
Do
we
squash
it
on
merge
by
using
the
option
to
squash
all
commits,
or
do
we
squash
it
before
we
merge
any
thoughts.
D
E
The
ux
needs
any
changes,
some
new
commits
there
and
then,
when
they're
done,
I
squash
there
and
then
send
it
to
the
maintainer.
Now,
if
the
maintainer
needs
needs
updates,
then
you
add
commits
and
they
might
just
merge
those
before
they
get
squashed,
but
that's
more
or
less
fine.
I
think.
Okay,
no.
A
E
A
C
A
A
A
A
E
One
thing
that
I've
just
started
doing,
I
suppose,
as
a
reviewer,
not
as
the
author,
like
last
night,
I
was
going
through
someone's
mr
and
there
were
just
a
bunch
of
like
really
annoying
things
that
prettier
had
done
like
leaving
carrots
on
random
wines.
I
was
about
to
leave
like
four
comments
like
hey.
E
We
should
fix
all
these
and
I
was
just
like
you
know
what
I'm
just
gonna
push
a
commit
for
this,
so
I
just
like
checked
it
out,
like
tweaked
all
those
lines
and
pushed
to
commit
up
to
it
so
like
leaving
all
those
comments
like
hey.
This
is
weird
formatting.
That's
like
hard
to
it's
hard
to
see
like
what's
actually
happening
because
the
for
the
line
like
wraps
weirdly.
It's
just
like
three
minutes
to
actually
fix
that,
so
that
can
help
your
review
go
smoother.
D
Yeah,
that's
an
excellent
point.
I
do
similar
things
too,
when
I
have
large
ideas
and
it's
just
as
simple
to
even
if
I
don't
do
a
push-up
like
you
said,
and
I
stole
this
from
paul
slaughter-
is
really
leaning
on
patches
like
build
a
pass
for
them
and
up
upload
that
directly,
if
it's
too
big
for
just
using
suggestions
and
that's
helped
a
bunch,
especially
when
you're
reviewing
something
like.
D
We
have
the
ux
team
pitching
in
to
do
a
lot
of
the
gitlab
ui
migration
stuff,
like
moving
all
the
new
gl
buttons
in,
and
it's
oftentimes
way
more
helpful
to
just
do
the
change
for
them
because
they're,
not
engineers,
first
they're
ux
people
and,
if
you're,
trying
to
explain
to
them
how
this
test
should
be
rewritten
because
it's
broken
or
something
it's
just
faster.
So
here
here's
the
fix
for
the
test
go
ahead
and
have
it.
A
Does
that
make
sense
to
me
to
you
in
terms
of
like
if
the
maintainer
or
the
review
is
going
to
give
me
the
code
to
fix
this?
I
start
getting
sloppier
next
time
that
I
submit
an
mr,
which
it's
human
behavior,
so
a
grain
of
salt
for
sure,
but
here's
a
story
then
I
I
was
debating
with
myself
whether
I
should
do
it
and
the
the
the
decisive
factor
that
made
me
write
a
patch
for
the
user.
A
Was
it's
going
to
be
very
hard
for
me
to
explain
with
words
what
I
mean
and
it
was
basically
css
change.
So
that
was
the
case
where
writing
a
patch
was
more
efficient
than
explaining
in
words
because
teaching
a
person
to
fish
or
giving
him
a
fish.
You
know
that
thing:
freedom
for
life
as
reviewers,
we're
also
teaching
them
like
the
habits
and
patterns
of
code-
and
I
remember
I
always
use
this
approach.
A
I
don't
know
if
I
used
it
with
any
one
of
you,
but
when
you
join
a
new
company,
no
matter
how
great
of
an
engineer
you
are
you're
like
in
a
pinball
machine
like
you,
like
the
ball,
hitting
the
walls
a
bunch
of
times
until
you
know
where
the
walls
are,
and
you
avoid
the
walls
by
doing
that,
work
for
them.
You're.
Removing
that
lesson
right.
It's
not
I'm
not
against
patching.
A
I
I
think
it
has
definitely
a
place,
especially
if
it's
like
a
pretty
or
something
and
you're
like
you're
gonna
press
merge
or
passing
it
over.
So
it's
easier
to
just
solve
that
problem
and
just
for
the
sake
of
time,
moving
it
there,
but
be
aware
that
if
you're
constantly
doing
that
for
the
same
person
you're
enabling
them
to
be
sloppier
in
the
future,
is
that
reasonable?
Or
am
I
just
being
too
strict.
D
I
was
going
to
say
definitely
sorry.
I
also
I
just
wanted
to
re-point
out
that
I
think
andre
said
it
really
well
when
he
said
the
kind
of
gut
feel
for
that
is
when
it's
it's
easier
to
explain
with
a
patch
than
it
is
and
just
words
what
you're
trying
to
say
right.
So
it's
not
that
you're
doing
the
work
for
them.
It's
that
here's,
what
I
was
trying
to
get
to
more
succinctly.
B
I
just
I
just
wanted
to
add,
like
the
patches
was
super
help
again.
It
was
like
paul
slaughter.
He
I
think
when
I
was
writing
a
spec
test,
and
then
you
know
how
we
have
like
with
jesters
these
like
test
case
or
the
loop.
I
can't
remember
how
to
anyways.
I
didn't
know
about
that,
and
it
was
because
of
his
pack.
She's
like
oh
a
simpler
way
would
be
to
do
it
like
this
and
because
of
the
patch.
B
I
actually
learned
something,
so
I
I
get
where
andre's
coming
from,
but
the
same
time
I
find
that
patch
is
such
a
great
way
for
me
to
kind
of
it's
such
a
great
way
to
knowledge
share,
because
sometimes
that
code
is
like.
Oh
actually,
never
thought
about
that,
and
you
kind
of
pass
that
knowledge
around
a
lot
easier,
like
you
said
than
explaining
it,
but
so
I
get
it
so
it
depends.
I
guess
it
depends
on
what
the
patch
is
trying
to
achieve.
Yeah.
A
D
E
A
Yeah,
this
is
good.
I
I
always
think
about
how
much
of
a
rule
that
would
be.
I
think
it
it's
it's.
It
comes
to
each
author
different
ways
as
long
as
you
communicate
the
roadmap
that
format
itself
is
secondary,
but
it's
definitely
I've
seen
that
I've
seen
that,
but
it's
definitely
useful
when
you
have
multiple,
mrs
coming
yeah
samantha.
B
I
have
one,
but
I'm
I
haven't
done
a
person,
but
I
heard
about
it
right,
so
maybe
phil
will
see
this
more.
I
heard
that
some
people
actually
do
a
self
review
of
their
code,
like
maybe
adding
hey.
This
is
I'm
doing
this
because
of
the
the
the
oh.
This
is
odd,
but
then
I'm
I
have
to
do
this
because
of
that.
B
A
I
think
there's
two
things
there
to
unpack
one,
and
I
remember
doing
this
and
being
very
useful
is
you
should
always
do
one
passive
review
on
your
own.
Mrs,
before
signing
that's
a
rule
like
please
do
this
all
the
time?
It's
so
easy
for
you
to
miss
and
trust
me.
If
I
had
a
penny
for
every
time,
I
committed
something
that
I
shouldn't.
I
I
added
a
file
where
I
shouldn't
it.
A
I'd
be
rich,
so
always
self
review,
which
is
to
go
through
it
as
if
it
was
someone
else's
code
and
review
ron
and
mr
on
assignment
or
before
you
assign
someone.
Okay.
The
second
is
what
you're
saying,
which
is
going
through
it,
and
adding
comments.
Explanatory
comments
for
the
reviewer
is
that
what.
E
C
So
it's
the
best
bit
of
advice.
I've
received
from
someone
to
get
like
is
to
always
self
review
and
it
came
after
me
pushing
up.
I
don't
even
know
how
many
major
questions
like
awful
code
that
I
wouldn't
even
pass
to
myself
and
it
just
sort
of
taught
me
these
two
ways
that
the
review
themselves
will
catch.
That,
like
maybe
I
should
think
about
the
point
of
when
I'm
writing
the
code,
and
then
it
eventually
told
me
how
best
you
can
maintain
it.
Whatever.
D
E
Yeah,
I
think
I
was
actually
just
gonna
say
I
think,
that's
kind
of
basically
what
our
policy
is
like
in
the
handbook
or
in
like
the
development
guidelines
or
whatever
it's
something
like.
If
it's
something
that
has
to
be
explained
in
in
the
code,
then
there
should
be
comments.
Otherwise,
no
comments.
That's.
A
E
What
I've
I
haven't
really
had
anybody
say:
oh,
we
should
take
this
comment
out,
because
my
comments
are
almost
always
like.
Oh
this
magic
number
down
here
is
because
of
like
this
file
over
here
that
we
have
to
match,
or
whatever,
like
that
kind
of
stuff
needs
to
stay
in
the
code,
so
yeah.
I
think
I
think
kind
of
backing
up
what
justin
said.
A
Yeah
I
I'm
on
that
too
I
mean
it
doesn't.
It
doesn't
exclude
that
some
situations
might
be
very
emerging
quest
centric.
But
if
you
find
yourself
explaining
yourself
your
code
in
the
merge
request,
then
definitely
should
be
a
good
comment,
but
that
doesn't
that
doesn't
mean
that
there
won't
be
one
or
two
cases
where
it
makes
sense
to
yeah.
I'm
doing
this
because
after
this
I'm
going
to
have
another,
mr
or
something
like
that
sort
of
stuff
is
mr
sentry
comments.
C
A
E
Okay,
one
thing
that-
and
this
is
before
gitlab
even
but
that
I
learned
this-
but
usually
I
think
that
if
I'm,
if
I
need
to
leave
a
comment
in
code,
that
usually
tells
me
that
it's
not
quite
ready.
It's
not
like
it's
not
quite
like
readable
enough.
I
guess
like
if
I
have
to
write
something
in
english.
E
That
means
the
code
isn't
readable
enough
in
english
to
like
to
like,
take
you
through
it
and
sometimes
that's
unavoidable,
but
usually,
if
I'm
leaving
a
comment
like
oh
this,
this
code
looks
this
way
because
of
xyz.
Usually
I
can
just
like
rewrite
it
to
avoid
xyz.
So
I
don't
need
the
comment.
So
I
think
that's.
A
E
A
A
So
this
is
something
I
bring
up
into
this
conversation
because
there's
always
gonna
be
things
that
we
don't
plan
for,
and
that's
always
disruptive
for
our
efficiency
and
shipping
right,
but
more
than
anything
in
those
cases
we
need
to
keep
shipping
in
mind
even
more
than
deliverables,
because
if
we
don't,
we
end
up
having
yet
another
thread
open
for
a
long
time,
they're
going
to
slow
everything
else
down.
So
whenever
something
like
a
bug
or
aggression,
pops
up
and
tackle
it
right
away.
If
we
don't
have
the
shipping
in
mind,
everything
is
derailed
right.
A
So
it's
even
more
special
then.
So
I
wanted
to
hear
your
thoughts
about
how
you
usually
handle
these
things.
How
what's
the
thought
process
that
you
have
and
when
you
see
a
report
on
slack
when
you
see
somebody
pinging
on?
Is
this
known?
Let's
have
a
discussion
about
that
broken
masters
as
well
like
how
do
you
usually
handle
these
things.
E
I
guess
I
can
give
a
recent
example.
There
was
a
bug
that
sid
reported
in
collapsing
files-
I
I
guess
it
was
maybe
maybe
already
existed-
I'm
not
I'm
not
sure
about
that,
but
it's
one
of
those
things
where
I
had
just
been
working
on
the
collapsing
file
code.
So,
first
of
all,
when
I
saw
it
and-
and
I
think
daniel
posted
it,
it
was
like
something
I
could
immediately
like.
I
wasn't
even
switching
context
really.
E
Sometimes,
however,
the
bug
that
comes
up
is
like.
Oh,
this
is
sort
of
fundamental
to
how
this
application
works
and
it's
not
it's
not
it's
not
something
that
we
can
fix
right
now
and
that's
when
I
just
kind
of
I
leave
a
usual
like
note
I'll
leave
a
note
like
hey,
I
looked
at
this
and
it
seems
like
maybe
it's
this
and
then
I
just
I
leave
it
alone.
So
I
don't
know
what
the
right
approach
is.
A
Right
yeah,
thanks
for
sharing
that,
in
that
case
you
had
the
benefit
of
not
having
to
do
context
switching,
but
you
still
had
to
drop
work
right,
but
to
the
what
I
will
highlight
there,
which
for
the
topic
here
is
you
were
able
to
ship
a
solution
on
the
same
day
that
you
picked
it
up
and
that's
what
you
want
to
see.
That's!
So
that's
exactly
the
kind
of
approach
that
we
should
take
with
these
reports
is
not
like.
A
Oh
yeah
I'll,
take
a
look
later
the
week
or
next
week
or
something
it's
like.
If
you
do
it
right,
then,
and
then
you
can
ship
something
on
the
same
day,
then
you've
basically
did
do
great
things.
One
is
fix
the
problem,
but
also
prevented
it
from
derailing.
The
others
and
dealing
with
regressions
is
always
tricky
because
there
might
be
low
severity.
But
if
there
are
regressions
on
the
current
release,
then
we
should
tackle
them
right
away
because
we
don't
want
to
make
things
worse
for
customers.
A
Is
priority
and
jumping
at
them
with
the
mind
of
shipping
something
very
soon,
and
that's
what
that's
in
that
moment
all
the
things
we
talked
earlier
about
avoiding
complexity
and
keeping
an
issue
prepared
for
tech,
debt
and
stuff,
it's
even
more
paramount
right,
but
yeah
in
that
case
you
shipped
something
very
well
something
very
quickly
and
you
went
for
review
right
after
that.
You
skipped
reviewer.
I
think
you
went
straight
for
a
maintainer.
I
went
straight
to
phil
yeah
yeah
in
that
case,
like
he
was
a
domain
expert.
So
you
did.
A
A
That's
the
greatest
tip
that
I
can
give
there
if
we
identify
opportunities
to
improve
like
phil
was
saying
earlier,
create
an
issue
and
bring
it
up
to
me
for
scheduling
for
the
next
milestone,
and
I
feel,
like
that's
the
having
the
efficiency
in
mind
and
again,
bringing
the
previous
topic
about.
Keeping
the
user
in
mind
is
like,
even
if
the
solution
ain't
great,
if
it
just
unblocks
them
or
solves
a
problem
for
them,
then
we'll
go
with
that
solution.
A
Yeah
shipping
caps,
yes,
more
thoughts
here,
broken
masters.
Have
we
have
we've
been
dealing
with
that?
Do
we
just
ignore?
So
this
is
an
honest
question
like
do
when
whenever
we
see
broken
masters,
do
we
take
a
look
at
them?
Do
we
not
do
we
expect
someone
else
to
take
it
or
is
there
usually
somebody
already
took
it?
What's
the
situation
there.
D
E
Yeah,
usually,
what
happens
for
me
is
I
see
the
the
message
come
in.
It's
like
master's,
broken
check,
check,
master
broken
for
the
thing,
and
I
go
look
at
it
and
it's
like
some.
They
already
have
an
issue
open,
usually
and
there's
and
there's
some.
I
guess
maybe
the
bottom.
It's
an
issue
anyway.
There's
it's
something
like
fight
like
an
ruby
file.
Actually,
I'm
like
okay,
oh
I'm,
just
I'm
not
gonna
touch
it.
A
Yeah,
that's
a
yeah,
that's
a
fair,
a
fair
view,
but
I
it
the
deployments
sometimes
get
all
held
up.
So
it's
it's
variable
but
yeah
it
could
be.
I
think
it
also
about
that
thing
about
the
shift
change
like
the
changing
of
the
guard,
where
you're
closing
up
your
shop
here
in
europe
and
in
the
us
they're
picking
it
up.
I
do
think
we
have
great
people
jumping
at
these
things
right
away.
A
I
I
have
seen
in
the
past
back-end
jumping
on
front-end
issues,
so
some
like
some
something
like
stan
or
or
patrick
or
other
folks
that
I've
seen
jumping
on
these
things.
Sometimes
it's
a
something
on
a
front-end
test
and
they
either
fix
it
or
they
just
quarantine
it
or
something,
but
maybe
we're
just
not
looking
at
the
right
places
right,
because
we
do
see
when
it's
announced
on
the
front
end
and
the
back
end.
A
Sorry
on
the
front
end
channel,
but
I
do
think
we
have
specific
channels
for
watching
that
and
I
don't
think
we
have
have
a
record
of
breaking
master
ourselves
in
source
code.
I
haven't
seen
much
of
that,
especially
in
the
front
end.
The
ones
that
I've
seen
front-end
specific
were
about
node
version
being
updated
or
something
like
that
that
really
messed
up
some
some
things
up,
but
okay.
So
in
that
case,
then
there's
not
much
to
discuss
for
the
broken
masters,
just
something
that
I
wanted
to
be
aware
of.
I'm.
E
C
E
D
A
Yeah
at
least
basically
just
peek
at
the
job,
that's
failing
and
see
if
there's
anything
like
a
css
class
missing
that
they
can't
find
or
something
it's
usually
something
on
the
front
end
that
broke
yeah,
that's
good.
I
wanted
to
bring
another
thing
here
into
the
mix.
So
we've
talked
about
that
broken
masters.
We
talked
about
the
regressions
yeah,
so
the
one
thing
I
would
like
us
all
to
keep
more
eyes
on
is
on
the
is
this
known
channel,
because
that's
where
people
are
reporting
like
gut
feelings
and
hey,
is
this
broken?
A
Do
you
already
know
about
this
and
that's
a
great
moment
for
us
to
maybe
catch
a
feedback
on
something
that
we
just
shipped
for
features
that
we
built
or
just
something
that
falls
on
the
source
code?
And
I
I
do
have
what
what
do
you
say?
You
agree
and
the
one
thing
that
I
like
that
I
keep
in
mind.
Is
it's
like
a
garden
right.
We
have
to
tend
to
our
garden
to
cut
the
little
things,
I'm
not
a
gardener,
but
I
just
use
that
metaphor.
A
A
So
if
you
see
something
like
that,
don't
even
ask
for
permission
to
jump
at
it
if
it
doesn't
impact
the
deliverables.
So
I
have
no
problem
of
you
picking
work
like
that.
That's
unplanned
if
it's
not
impacting
the
deliverables,
so
use
always
that
in
mind-
and
this
also
goes
to
work
that
you
would
like
to
be
that
you
like
to
see
done
and
phil
you're
great
at
this,
where
you
see
something
that
needs
to
get
done
and
you
just
do
it
and
it
doesn't
impact
the
deliverables.
A
A
A
So
that's
kind
of
like
my
my
topic,
the
one
thing
that
I
would
like
the
caveat
there
is,
if
it's
a
feature
issue,
and
you
know
that
there's
a
couple
of
people
looking
at
it
and
ask
first
because
we
might
be
in
discussion
of
schedule
of
specifying
it
a
bit
more
or
something.
But
if
it's
like,
if
it's
a
bug,
if
it's
an
obvious
bug
what
it
should
be
doing
fix
it.
C
So
that
is
this
no
challenge,
so
I
don't
really
see
its
effectiveness
sometimes,
but
it's
normally.
What
I
see
is
that
someone
will
post
a
comment
and
then
maybe
it'll
go
like
on
reply
to
and
like
scroll
up
the
list
and
then
you
wonder,
is
anybody
actually
made
an
issue
for
this?
No
one's
replied
to
it,
so
maybe
it's
not
know.
Maybe
she
should
be
created.
So
it's
all
like
it's
forgotten
about
and
scroll
down,
and
then
you
also
see
on
the
other
side.
Is
that
someone
writes
a
comment
saying?
C
Oh,
is
this
a
book
and
then
like
two
lines
down
someone's
wrote?
Is
this
a
book
which
is
essentially
the
same
thing
as
the
one
like
two
lines
above
and
then
leave
with
them?
We
get
replied
to
and
it
again
it
scrolls
up
the
list
and
no
issue
ever
gets
created
for
it.
It
seems
like
another
job
for
us
to
do.
We
have
to
keep
track
of
issues
up,
keep
track
of
regression
keep
track
of
us
spoken
and
then
we
have
to
keep
track
of.
Is
this
known
there's
like
all
these
different
places?
D
C
A
Yeah,
I
I
might
be
over
asking
here
because
I
already
pay
attention
to
the
east-
is
known
basically,
so
basically,
let's
just
make
that
that's
that's
a
source,
for
instance,
so
up-to-date
feedback
and
you're
right.
Sometimes
they
complain
about
the
same
thing
multiple
times
and
we
have
like
the
champions
that
are
always
there
that
always
know
exactly
that.
Oh
this
has
been
reported
three
days
ago,
like
george
and
stuff,
so
they
always
know
about
those
things
yeah
it
might
not
be.
E
I
wonder
what
the
intended
original
purpose
of
is.
This
known
is
because,
because
I
think
that
as
a
company,
we,
like
everything,
starts
with
an
mr
right,
but
even
if
you're
not
going
to
create
an
mr
issues
are
like
how
we,
how
we
look
at
work
so
is
it
was
the
intent
of
is
it's
known
to
like
check,
really
quick,
whether
someone
responded
and
if
they
didn't
just
create
an
issue
off
of
it,
and
that's
just
not
happening
anymore.
C
So
what
we
used
to
find
is
that
people
would
then
write
a
comment
in
either
the
front-end
channel
or
the
development
channel
and
say:
hey,
is
this
known
and
then
someone's
clicking
there's
actually
front
end,
and
then
you
go
to
the
front
end
channel
and
copy
the
link
across
and
then
they'd
be
like
okay,
maybe
it's
source
code,
and
then
they
copied
the
link
across
the
socket.
So
it's
sort
of
like
this
centralized
place
for
all
these
people
to
ask
questions.
Is
this
actually
known
yeah.
A
A
A
A
That
would
still
be
a
point
about
if
you
see
features
that
you'd
like
to
be
built,
and
it's
like
a
small
thing
or
a
break
point
that
it's
not
breaking
properly
or
like
small
things
that
you'd
like
to
see
in
the
product
like
there's,
nothing
stopping
you
from
picking
that
up
if
it
doesn't
hinder
deliverables,
and
I
would
welcome
that.
Okay,
that's
like
a
message.
I
would
like
to
send
cool.
A
And
as
a
note
on
that,
like,
I
know
that
that
message
can
lead
to
being
worse
at
shipping
your
own
things,
but
if
you're
thinking
about
the
overall
picture,
we're
shipping
more
things,
because
it's
not
affecting
deliverables
and
you're
shipping
that
fix
that
wasn't
that
wasn't
planned
so
in
the
overall
we're
making
the
product
more
alive
like
updating
more
frequently
and
everything
like
that,
so
yeah,
that's
kind
of,
like
the
note
all
right,
10
minutes
out
any
more
topics
on
the
unscheduled
work
that
you'd
like
to
talk
about
any
questions.
Anything,
that's
not
clear!.
A
A
D
D
I
I'm
only
kind
of
joking,
because
I
I
am
of
the
personality
that
if
something
is
broken,
it
will
eat
at
me
until
it's
fixed.
And
so,
if
I'm
behind
my
deliverables,
which
feels
like
I
have
been
for
nine
months,
I've
gotten
very
good
at
just
hitting
going
into
slack
using
the
all
unread
messages
thing
that
it
has
and
just
hitting
bulk
red
for
entire
channels.
C
D
C
A
Okay,
that's
cool
I'll
move
to
my
next
one.
Then,
while
you
think
of
other
points
that
we
might
be
missing,
so
this
is
something
that
I've.
I
think
I've
mentioned
this
to
all
of
you,
but
like
it's
easy
to
fall
into
that
thing
about.
Oh,
it's,
the
beginning
of
the
milestone,
so
it's
like
right,
the
first
week
it's
slower
and
that
sort
of
thing.
A
What
I
would
recommend
is
like
to
having
your
own
self-imposed
deadlines,
so
to
speak
per
per
week
in
terms
of
every
week
is
ship
week.
Every
week
is
shipment
week,
and
this
is
going
back
to
the
topics
that
we've
discussed
earlier
about.
If
you
have
multiple
things,
seeing
whatever
you
can
to
fruition
like
do
it
like
get
whatever
you
need
to
do
to
get
that
shipped.
That's
always
your
your
your
biggest
bet
on
on
getting
things
shipped
is
keeping
the
constant
and
not
be
like.
A
C
So
on
that,
though,
the
deadline
sort
of
create
this
unnecessary
stress
on
people
and
that
you
will
see
that
I've
got
this
issue
done
by
a
certain
date
and
maybe
you've
left
like
a
week
or
two
and
then
oh
crap,
now
they're
like
the
deadlines
in
like
two
weeks.
I've
got
to
like
do
something
quick,
oh,
like
no,
the
deadlines
in
like
two
days.
I've
really
got
to
go
this
one.
A
E
So
the
deadline
feels
like
a
legit
deadline
like
if
you
don't
get
it
in
then
like
everyone's
going
to
be
messed
up,
so
there's
some
pressure
there
from
from
product.
I
think
like
I
haven't
daniel,
has
never
come
to
me
and
been
like.
Are
you
sure
this
is
gonna?
Make
it?
And
you
really?
This
really
needs
to
make
it
like
blah
blah.
But
there's
still
that
implicit
pressure
because
he's
like
off
writing
blog
posts
and
like
off-writing
issues
and
stuff
for
for
features
that
he
presumes
will
make
it
by
the
deadline.
C
So
I'm
probably
going
to
be
outstanding
a
bit
here,
but
I
would
say
so
ignore
them
all
together,
like
that's
their
problem.
Their
problem
is
writing
the
blog
post
or
whatever.
Your
thing
that
you
need
to
do
is
shift
the
stuff
that
you've
been
assigned
to.
If
they're
putting
your
pressure
on
you,
that's
their
problem,
not
your
problem.
C
A
A
Frequently
it's
hard
to
say
no,
but
in
the
recent
stories
that
we
had
was
the
reviewers,
they
were
made
the
fault
the
true
last
day
of
the
sprint
I
in
it
that
happened
after
I,
after
I
told
product
that
this
is
not
going
to
be
ready
to
make
it
default
to
true
today,
and
we
had
a
conversation
around.
Are
we
being
overly
protective
or
not?
But
that's
my
conversation
to
have
with
them
now
with
not
with
you.
A
You
focus
on
the
continuous
delivery
flow
right
and
whenever
it's
ready
to
spready,
if
it's
not
ready
to
flock
like
we
ship,
we,
we
we
flow
over,
and
I
I've
also
had
this
conversation
with
products
saying
about.
If
you
want
to
have
extremely
predictable
commitments,
we
will
be
doing
far
longer
planning
and
far
more
conservative
deadlines.
So,
instead
of
me
saying
that
it
would
be
shipping
reviewers
in
two
milestones
I'll
be
asking
for
six
months.
A
If
they
want
predictability,
that's
how
people
used
to
do
in
the
waterfall
days
that
we
don't
do
anymore.
We
we
accept
the
unpredictability
of
our
prediction.
So
my
message
to
you
is
exactly
what
phil
said
ignore
them.
I
mean
answer
the
questions.
Don't
let
them
hanging
answer
the
questions,
but
don't
take
that
as
pressure
to
ship
earlier.
That's
a
big
lesson.
D
A
A
And
if
you
have
a
process
where
we're
constantly
shipping
and
we're
constantly
like
taking
time
to
like
get
the
things
out,
that
we
can
get
out
we'll
be
in
a
far
better
position
to
yeah
when
it
slips
it
slips.
It
had
to
slip
because
there
was
nothing
that
we
could
have
done
like.
We
saw
something
that
we
weren't
expecting
or
so
yeah.
This
slippage
that
I've
that
we've
talked
about
is
not
to
see
that
as
the
end
of
the
world,
but
it's
not
also
to
see
something
as
normal
constantly
right.
A
E
A
D
A
But
yeah
to
start
let
one
of
the
lessons
here
then
is
to
the
expected
flow
for
the
ics
is
to
work
on
a
continuous
delivery
approach
like
deliver
it
when
it's
ready
do
your
best
to
have
it
ready
as
soon
as
possible,
but
in
reasonable
quality,
but
don't
sacrifice
that,
but
don't
pay
attention
to
deadlines
per
se.
That's
that's
for
me
to
worry
about
get
them
ready,
ship
them
get
them
ready,
ship
them
and
that
sort
of
thing.
A
D
B
D
A
That's
fine
and
I
I
the
one
thing
that
I
it's
normal
is
that
we
did
get
a
lot
of
insight
from
phil.
Naturally,
because
he's
more
experienced-
and
he
has
a
lot
of
experience
with
this
and
he's
great
at
shipping.
But
I
wanted
this
to
have
more
of
a
conversation
flow
than
a
presentation,
because
I
feel
like
it's
more
real
than
we
have
someone
telling
you
how
they
do
their
stuff
and
you
don't
have
a
voice.
C
Yeah,
like
I
could
sit
here
and
just
talk
about
how
I
do
things
every
day
and
if
that
works
for
me
it
might
not
work
for
someone
else
and
I
think
that's
whatever
the
the
code
review
blog
posts
is
that
all
them
things
are
just
the
things
that
I
do
and
they
may
never
work
for
anybody
else.
It's
just
what
I've
sort
of
corroded
myself
to
do
so
I
could
sit
here
and
tell
you
exactly.
A
Well,
it's
the
first
time,
so
we're
definitely
gonna
do
this
more
often,
if
you
did
it
second
time,
but
thinking
once
a
quarter
might
be
interesting
at
the
end
of
the
quarter
having
a
session
about
something
amongst
ourselves-
and
this
will
be
I'll,
be
uploading
this
to
youtube
soon
and
then
sharing
on
the
source
code
channel
so
that
everybody
can
benefit
from
it.
But
thank
you
everyone
for
the
time.
Thank
you,
everyone
for
the
thoughts
and
opening
up,
but
yeah,
that's
all
I
had.
I
don't
have
anything
else.