►
From YouTube: Engineering Productivity Office Hours: 2021-09-22
Description
Discussion on Frontend developer points of friction and improving documentation
A
A
I
kind
of
seeded
a
topic
that
that
prompted
mark
to
show
up,
and
I'm
very
grateful
for
that.
So
thank
you,
but
I
wanted
to
focus
in
on
how
we
can
optimize
front-end
cycle
time
and
feedback
loops
for
context,
engineering,
productivity
we've
when
we
try
to
shorten
the
pipeline
duration
for
the
single
like
the
get
lab
single
repo,
we
primarily
focus
on
back-end
and
front-end
exclusive
pipelines.
B
Well,
I
think
this
is
outside
of
the
scope
of
this,
but
I'll
mention
it
anyway.
I
think
on
the
gitlab
project,
just
waiting
for
a
pipeline
to
start
and
appear
in
the
list
is
is
a
bit
of
a
pain,
and
this
comes
up
when
doing
reviews
as
well.
You
know
if
I
want
to
if
I
think,
a
magic
quest
looks
good.
I
want
to
approve,
run
a
pipeline
and
merge
when
it
succeeds,
but
I
need
to
wait
for
the
pipeline
to
begin
before.
I
can
do
the
mw
mwps.
B
B
The
issues
I
run
into
more
often
are
when
I
want
to
run
a
spec
locally,
so
when,
when
front-end
fixtures
are
involved,
generating
these
fixtures
locally
is
a
huge
pain.
I've
never
done
it
successfully.
I
always
have
to
go
to
ci
and
download
the
the
fixtures
that
are
generated
there,
because
I
think
it
can
take
like
half
an
hour
or
more
to
generate
all
of
them,
and
maybe
that's
fine.
A
So
what
one
thing
on
that
before
we
move
on
to
anything
else
and
remy
jump
in
here,
that's
really
interesting.
I
didn't
realize
that
that,
like
people
are
doing
that
at
all
the
downloading
the
fixtures
from
ci
that
almost
and
I
think,
you're
working
with
albert
on
removing
the
front
end
fixture.
I
know
that
you
and
him
were
going
back
and
forth
on
that-
that
that
kind
of
points
to
having
some
sort
of
programmatic
way
of
storing
those
or
retrieving
them
would
help
your
workflow,
your
local
workflow,
am.
B
Yes,
there
was
talk
about
having
them
be
part
of
the
repository
and
sort
of
removing
the
fixture
generation
from
the
sort
of
serial
flow
of
the
pipeline
and
just
having
a
check
that
fixes
have
changed.
That
would
be
great
if
we
could
do
it,
but
there's
a
lot
of
discussion
there
about
having
stable
fixtures,
because
if
they're
not
stable,
then
you
know
we'll
run
into
problems
there.
A
B
I
think
that
is
almost
always
the
recommended
approach.
Someone
every
now
and
again
asks
question,
I'm
trying
to
generate
the
fixtures,
but
it's
failing
or
what's
taking
forever
or
it's
hung
or
something
like
that.
What
do
I
do
and
the
the
feedback
is
almost
always
go
to
ci
download
the
fixtures
we
might.
B
It's
not
too
convoluted,
so
I
would
just
go
to
a
job
go
to
one
of
the
frontend
fixtures
jobs
and
I
think
I
can't
remember
either
download
the
artifact
zip
and
then
extract
it
locally.
You
know
it's
not
too
big.
It's
much
quicker
to
do
that
than
to
run
the
fixtures
locally
run
the
fixed
regeneration
locally.
So
I'm
actually
kind
of
happy
with
that
process,
as
it
is
it's
just
it's
not
obvious
to
if
you've
never
done
it
before
you
know
I
want
to
generate
this.
How
do
I
get
it?
It's.
A
And
kind
of
the
workflow,
I'm
thinking
is
just
like
a
script
that
we
can
add
to
the
gitlab
project
that
says
get
the
fixtures
by
default
from
master
or
if
you
pass
like
a
pipeline
url
to
it
or
your,
mr
or
some
sort
of
argument,
it
will
try
to
retrieve
the
latest
front-end
fixtures
and
put
them
in
the
right
spot,
so
you're,
not
navigating
downloading
saving
them
extracting
them
in
a
different
directory.
It
just
does
that
all
for
you.
A
C
A
Mark
is
there
a
way
that
we
can
like
how
what's
an
easy
way
to
get
feedback
from
just
everyone
in
front
end,
just
drop
something
in
the
front
end
channel
and
say:
hey
we're
we're
experimenting
with
this.
One
of
the
things
we're
running
into
is
just
not
having
the
subject
matter,
expertise
or
familiarity
with
front-end
developer
workflows
to
know
where
to
go
as
albert's
running
into
things
like
this
or
remy
or
jin
chun.
A
B
B
Another
option
is
the
front-end
weekly
call
put
it
as
a
putting
it
as
an
agenda
item
in
there.
There's
some
complication
there,
because
we
actually
have
three
different
time
zones
depending
on
the
week,
the
one
that's
at,
like
I
think,
1pm
utc
or
something
like
that
is
probably
the
one
that
has
the
most
people
in
it.
So
maybe
that's
the
best
one
to
target
and
that's
better
because
the
people
who
are
there
are
there,
because
they
want
to
contribute
and
and
hear
hear
about
things.
B
B
We've
actually
been
discussing
that
we
often
don't
have
much
to
discuss
in
those.
So
it
would
be
great
to
have
outsiders.
You
know
it's
open
office
hours,
so
it's
great
to
have
people
come
in
exactly
this
kind
of
thing
is
perfect
for
them.
So
absolutely
bring
it
to
front
and
maintain
his
office
hours
as
well.
A
C
B
Yes,
I'm
almost
certain
that's
happened,
it's
not
happened.
Well.
Actually
you
know
that
may
well
have
happened
to
me
in
that
situation.
I
knew
what
I
had
to
do.
I
had
to
find
the
merge
base
and
then
pull
the
you
know,
fixtures
from
from
the
closest
ci
job
that
ran
on
that
merge
base,
but
that
might
not
be
obvious
to
everyone.
I
don't
know
so
that's
a
very
real
problem
and
I
think
again
bringing
it
back
to
making
these
part
of
the
repository.
I
think
that
would
solve
that
problem.
B
B
Right
so
that
I
guess
that's
what
albert's
proposal
of
using
import
rather
than
get
json
fixtures
about,
because
jest
has
this
find
related
tests
functionality
and
if
you,
if
you
use
the
import
mechanism,
I'm
assuming
that
he's
tested
this
out,
because
I
I
don't
know
if
it
would
work.
To
be
honest,
I
don't
see
why
not
cool
dynamic,
dynamic
imports.
So
I
like
the
idea
of
that,
but
I
think
albert's
already
identified
potential
problems.
B
I
guess
one
of
the
problems
is
that
import
being
asynchronous
means
that
the
tests
have
to
be
refactored,
whereas
the
get
json
fixture
is
synchronous,
so
that
might
cause
a
bit
of
a
problem,
but
not
too
much
of
one.
No,
that's
not
a
big
problem
at
all.
Actually
you
could
just
do
it
in
a
before
all
or
something.
B
A
A
A
B
B
A
Yeah
yeah,
I
think,
ideally,
what
we're
looking
for
is
to
accelerate
that
feedback.
So
you
talked
about
set
it
and
forget
it.
We
want
to
get
to
a
state
where
it's
set
it
and
you
get
the
feedback
much
faster,
like
you're,
probably
waiting
80
minutes
like
70
to
80
minutes
or
more
for
your
pipeline
to
complete,
assuming
review,
deploy
and
everything
else
that
happens
by
default
on
front-end
pipeline
graphs.
B
B
B
A
B
C
B
D
B
B
C
A
B
B
A
B
A
A
Okay,
if
anything
comes
up
so
I'll
kind
of
encourage,
albert
and
we'll
take
a
look
at
those
meetings
to
see
how
we
can
join
a
little
bit
and
drop
a
note,
drop
more
notes
in
the
front
end
maintainers
channels
to
engage
with
that.
If
anything
comes
up
or
anything
comes
to
mind,
just
drop
a
slack
in
geoengineering
productivity,
our
slack
channel
and
we'll
be
happy
to
collaborate
further.
That
way.
Okay,
great.
C
B
A
D
I'm
not
sure
about
that,
but
yeah.
No.
I
just
saw
this
this
comment
from
drew
today
and
about
basically
the
the
point
is
that
our
pipeline
documentation,
so
the
documentation
about
pipeline
config
and
and
also
all
the
tricks
that
you
can
use
in
pipelines
so,
for
instance,
the
labels
to
run
for,
like
all
aspect,
jobs
or
to
run
as
if
first
jobs
stuff
like
that
these
are
kind
of
buried
in
the
documentation.
D
D
For
instance,
the
the
details
about
the
implementation
of
our
pipelines
are
probably
not
that
important
for
day-to-day
work
for
most
people,
so
that
could
go
probably
like
we
could
put
it
in
the
bottom
of
the
page,
and
I
don't
know
highlight
a
few
items
that
people
run
into
frequently,
and
I
was
also
thinking.
Maybe
we
need
to
educate,
so
maybe
I
don't
know
create
some.
D
Like
even
some
videos,
maybe
to
explain
these
tricks
because
we
mentioned
these
new
labels,
the
pipeline
labels
and
to
like,
for
the
run
all
aspect
run
as
fos
stuff,
like
that
we
mentioned
those
in,
I
think
in
slack
and
engineering
we
can
review,
but
that's
that's
actually
something
that
it's
not
a
one.
One
time
thing
like
we
need
to
remind
people
about
that.
I
think
regularly.
C
I
personally
don't
really
look
at
the
documentation
from
time
to
time.
I
will
probably
read
it
once
then
forget
about
it.
So
any
newly
edited
content
I
won't
really
read
and-
and
I
think,
unless
we
make
the
documentation
very
short,
it's
going
to
be
longer
and
longer
unless
we
remove
contents.
So
it's
getting
more
and
more
difficult
to
look
at
things
and
for
this
kind
of
thing
I
always
feel
like.
C
I
personally
won't
mind
if
some
automation
add
comments
on
the
merch
request.
I
don't
know
if
it's
it
will
be
noisy
for
other
people,
but
but
like
having
a
comment
saying
that
this
is
a
minimal
pipeline,
be
sure
to
approve
and
re-run
it.
Things
like
that
would
be
fine
for
me,
and
I
think
that
would
be
super
obvious
for
people.
C
D
D
Like
kind
of
pushing
the
documentation
to
the
people,
instead
of
like
letting
people
search
into
the
kitchen
so
pushing
in
a
sense
like
yeah
comments,
or
it
could
be
in
the
magiques
template
or
any
anything
on
the
magical
page,
I
agree
that
the
danger
comment
is
probably
overlooked,
like
people
are
used
to
it.
So
if
there's
no
failure,
they
will
just
keep
it
or
look
just
at
the
roulette,
maybe
so
yeah
a
new
comment
could
be
useful
yeah
as.
C
D
A
I
do
kind
of
want
to
go
back
to
what
you
said
remy
at
the
start,
like,
I
think
the
simplest
things
we
can
do
with
the
feedback
we
got
is
prioritize,
actionable
things.
First,
on
the
page,
maybe
move
things
like
the
pipeline
graph
to
a
different
page
and
link
to
it,
but
really
re-prioritize
the
information.
A
So
it's
clearer
to
people
who
land
on
the
page
what's
most
important
to
them
at
the
top,
and
I
like
the
idea
that
you
have
making
videos
something
that
is
a
lasting
resource
that
we
can
refer
to
in
the
docs.
That's
quick
on
the
labels
and
things
like
that.
Yes,
that
creates
a
maintenance
like
a
maintenance
thing
as
things
change,
but
I
think
that
really
gears
with
how
some
people
learn
is
interactive.
Content
versus
written
content.
A
C
A
I
don't
know
if
people
would
look
at
the
labels.
I
think
a
comment
is
a
good
idea
for
informing
there
and
starting
with
that
and
seeing
where
the
feedback
takes
us,
because
we're
never
going
to
make
like
I'm
not
trying
to
say
this
to
be
defeated,
but
we're
always
going
to
interfere
with
someone's,
ideal
workflow,
and
that
feedback
is
something
we
should
be
open
to
and
listen
to
and
see
how
we
can
adjust
or
tweak
things.
But
we
need
to
start
somewhere
versus.
A
So
I
think
the
actionable
things
here
we're
looking
at
re-prioritizing
the
content
on
the
pipeline
pages,
just
moving
things
higher.
Consider
making
some
videos
on
the
labels
and
a
few
of
the
other,
like
maybe
just
talking
through
minimal
to
full
transition,
would
be
really
helpful
and
why
we're
doing
that
providing
the
context
on
that.
A
And
then
looking
at
a
comment
of
informing
people
or
how
we
can
inform
this
is
a
minimal
pipeline
versus
a
full
pipeline.
I
haven't
seen
too
many
failures
like
this,
though,
which
I
think
is
positive,
because
our
spec
for
one
that's
been
going
for
almost
two
months
now,
and
this
is
the.
I
think
this
is
the
first
problem
like
this,
that
I
recall
where
it's
an
mr
was
merged
with
a
minimal
pipeline
that
caused
a
broken
master.
A
D
The
like,
initially,
that
was
the
main
fear
that
that
would
break
master
very
frequently
like
in
the
first
iteration
of
this,
so
so
yeah.
That's
that's
pretty
cool
to
see
that
it's
it's
actually
not
that
problematic
and
yeah.
I
think
a
video
would
be
useful
in
the
sense
that
we
could
explain
why,
as
you
said,
and
even
like
show
some
graphs
about
my
consideration
and
you
know
so
that
people
understand
that
the
feedback
is
coming
like
I
don't
know,
15
minutes
faster.
Maybe
I
don't
have
the
data,
but
you
know.
A
Yeah
when
I
first
saw
drew's
discussion,
he
he
brought
he
shared
something
in
development
too.
I
can't
I
was
hesitant.
I
wanted
to
jump
in
and
say:
please
don't
just
use
this
as
an
opportunity
to
default
run
all
our
spec
all
the
time.
This
is
an
infrequent
occurrence
and
it
kind
of
goes
against
the
overall.
Shortening
the
feedback,
loop
goals
that
we're
trying
to
do
but
yeah
it
was.
It
was
kind
of
I
had
kids
screaming
and
things,
and
I
I
don't
think
I
could
have
crafted
a
good
message
at
that
moment.
A
D
A
Okay
but
ezekiel,
thank
you
for
joining.
We
had
some
good
great
discussion
with
mark
earlier
on
front
end
I'll,
say
like
just
front
end
feedback
loops
in
general
and
where,
where
there's
points
of
friction,
if
you
have
other
things
to
share,
I'm
like
I
really
enjoy
hearing
from
you
on
that
mark
also
shared
reaching
out
in
the
like
front
end
maintainer
office
hours
or
the
front
end
weekly
calls
has
good
opportunities
for
us
to
collaborate
more
directly
with
front
end
and
bring
some
ideas
for
feedback
in
those
forms
too.
E
Can
I
jump
in
just
to
observe
so
I'll
probably
go
back
and
have
a
look
at
the
recordings
and
the
discussions
that
I
had
previously
but
yeah,
I
think
yeah,
I'm
happy
to
stay
in
touch
and
yeah
I'll
keep
an
eye
on
if
there's
anything
that
jumps
out
to
me,
particularly
maybe
when
maintaining
mrs
or
actually
all
through
my
own,
mrs
as
well
and
feed.
That
back
is.
C
A
A
I
want
to
try
to
meet
you
like
in
your
ideal
way
of
sharing
versus
trying
to
say
like
this
is
the
one
way
that
you
have
to
get
in
contact
with
our
team
so
office.
These
office
hours
are
monthly,
so
I
would
say:
don't
wait
for
an
office
hours
to
bring
something
up,
create
an
issue
drop
a
like.
Send
us
a
slack
message
or
start
a
thread
would
be
great
cool,
yeah
yeah
in
part
of
where
I
kind
of
mention
this
to
mark,
but
our
the
engineering
productivity.
A
We
don't
have
a
lot
of
front-end
development
experience
on
our
team.
So
as
we
look
at,
how
can
we
optimize
the
local
developer
tooling,
or
even
like
the
feedback
you
get
in
pipelines,
we're
pretty
far
removed
in
what
we're
doing
or
how
to
do
that?
And
we
really
need,
like
a
stronger
partnership,
to
help
make
sure
that
we're
we're
focusing
we're
giving
it
the
focus.
E
Awesome
now
that's
really
awesome
to
hear
yeah.
I
think,
like
part
of
what
piqued
my
interest
with
this
particular
office
houses,
the
analytics
team,
so
I'm
part
of
the
optimize
team.
Sorry
we
were
previously
called
analytics
and
yeah.
We
actually
use
back
end
aspect,
fixtures
quite
a
bit,
so
I'd
be
quite
interested
in
reviewing
what
was
kind
of
discussed
earlier
and
seeing
if
there's
any
any
input
that
our
team
could
have
on
that.
A
Yeah
part
of
the
challenge
mark
shared,
so
maybe
if
you
have
a
different
challenge
like
we'd
love
to
chat
about
that,
but
the
challenge
mark
was
talking
about
is
when
you
need
to
rebuild
them
locally.
It
takes
a
long
time
and
it's
a
hard
process
and
he
normally
just
downloads
the
artifacts
and
loads
them
locally.
So
we
kind
of
talked
about
just
having
a
script
or
some
sort
of
local
tooling.
E
I
think
that's
probably
the
main
one
for
sure,
particularly
in
I
do
a
fair
bit
of
work
on
value
stream
analytics.
So
those
fixtures
touch
a
lot
of
the
database
level
stuff.
So
it's
not
uncommon
for
fixed
regeneration
to
be
five
six
minutes
locally,
but
I
think,
probably
I'm
sure
I
think,
there's
anything
else.
Particularly
that
stands
out.
I
mean
possibly
knowing
when
fixtures
are
broken.
E
I've
definitely
come
across
one
or
two
instances
where
it
seems
like
they're
passing
in
ci,
but
there
might
be
some
sort
of
minor
misconfiguration
in
my
local
system.
I
might
not
have
run
some,
I
don't
know
migrations
or
something
so
locally.
My
fixtures
might
look
okay
and
then
they
might
look
okay
in
ci,
but
then,
when
the
emergence
master,
something
else
happens,
but
I'll
definitely
keep
an
eye
out
and
ask
around
in
the
team
as
well.
A
Well
that
this
is
I,
if
there's
nothing
else
like,
I
think
we
can
call
it
here.
This
feedback
has
been
really
awesome.
I
think
at
the
team,
like
I'd
like
to
have
albert
review
this
as
well,
because
he's
been
working
a
lot
on
our
front
end
optimizations,
but
there's
definitely
some
things
that
we
can
look
to
do
over
the
next
few
milestones
to
help
help
that
front-end
developer
experience,
making
sure
that
those
points
of
friction
can
at
least
be
lessened,
if
not
eliminated.