►
From YouTube: Book Club - The Staff Engineer's Path - Chapter 3 (APAC)
A
A
A
No,
yes,
cool,
just
a
reference,
yeah
cool,
so
all
right
get
started
with
the
first
point.
This
is
a
quote
from
the
book.
A
technical
Vision
describes
a
feature
as
you'd
like
you'd
like
it
to
be
once
the
objectives
have
been
achieved
and
the
biggest
problems
are
sold
describing
how
everything
will
be
after
the
work
is
done,
makes
it
easier
for
everyone
to
imagine
to
imagine
that
world
without
getting
hung
up
on
the
details
of
getting
there.
A
I
think
I
do
like
that
statement,
but
I
guess
in
you
know
in
our
day-to-day
work:
I,
don't
I'm,
not
sure
if
we
have
or
we
always
have
a
vision,
especially
at
the
you
know,
group
or
Team
level
and
then
going
forward
as
a
stage
or
as
a
development
department.
That
kind
of
thing
does
anyone?
Has
anyone
seen
a
lot
of
the
vision
I've
seen
some,
but
maybe
not
all
the
time.
B
I
mean
for
me:
I
I
I've
definitely
worked
in
projects
where
there
has
I'm
sure
at
some
point
there
was
that
Vision,
but
it
would
be,
it
would
have
been
created
by
I
I.
Think,
someone
at
a
higher
level
than
a
staff
engineer,
so
yeah
we've
ultimately
worked
on
those
and
the
staff
Engineers
have
been
instrumental
in
implementing
those
Visions,
but
I
think
the
vision
itself
would
be
from
like
a
group
manager,
or
you
know,
someone
someone
higher
up.
A
B
The
staff
engine
staff
level
was
a
little
bit.
You
know
not
not
as
I
think
all-encompassing.
As
the
author
has
written
about
and
I
think
this
kind
of
like
is
touched
upon
in
a
few
other
parts
as
we'll
get
into
the
discussion
a
little
bit
later
about
some
points.
That
I
was
talking
about
as
well
in
in
the
length
of
some
of
these
things.
Yep
but
yeah
I'd
be
curious.
You
know
for
Tong
if
you've
worked
on
any
technical,
Visions
or
technical
strategies,
yeah.
C
D
Staff
principal
everyone
above
so
it's
all
encompassing
well
for
the
scenario
that
has
been
described
in
this
book.
It
feels
more
like
a
principal
Engineers
role
to
me,
sometimes
referred
to
as
senior
staff
in
other
companies
sometimes
referred
to
as
staff
in
other
companies
as
well
confusingly
and
then
there's
a
lower
principle
level
or
yeah
yeah,
but
yeah
right,
I,
think
I.
Think
like
like,
for
example,
the
the
biggest
project
I've
been
on
was
the.
D
E
B
I
was
trying
to
think
about
like
the
biggest
things
that
I've
seen
this
like
staff
Engineers
on
our
team
work
on,
and
that
was
like.
There
was
definitely
documentation,
like
large
amounts
of
documentation.
That
would
describe
in
detail
all
the
different
components,
and
you
know
for
a
particular
implementation
that
was
upcoming,
but
it
wasn't
so
much
I
think
the
the
vision
and
the
and
the
strategy
was
at
a
higher
level.
F
Yeah,
what
I
was
gonna
say
because
I
mean
I
started
late,
so
I
haven't
read
it
all,
so
I
may
be
losing
something,
but
from
my
point
of
view,
it's
more
about
having
Vision
helps
staff
engineer
to
decide
what
to
do
as
opposed
to
staff.
Engineer
comes
up
with
a
vision
so
to
speak.
I
think
to
me
that
it's
sort
of
like
a
having
something
there.
F
D
A
A
In
context
of
the
chapter
writing
the
strategy
involving
like
a
like
a
group
like
a
core
group
or
kind
of
thing
like
where
you
know
a
smaller
number
of
people
get
together
to
Define
what
needs
to
be
done,
and
there
was
this
discussion
point
where
people
input
from
many
different
people
are
trying
to
like
steal
the
Thunder
from
everyone
else.
That
kind
of
thing.
A
What
I
found
here
is
like
I
I
haven't
really
seen
that
git
love
where
people
are
trying
to
you
know
push
or
step
on
each
other's
toes,
toes
it's
more
like
really
trying
to
be
collaborative.
So
that's
that's!
Pretty
cool
I
don't
know
if
anyone
has
seen
this
a
kid
lab
or
at
other
places
where
people
are
just
like
just
to
be
on
the
spotlight,
but
not
really
necessarily
doing
the
work.
B
Yeah
I've
definitely
felt
that
same
way
at
gitlab
I
mean
in
comparison
to
other
companies
that
have
worked.
Yeah
there's
definitely
be
some
very
toxic
work
environments
extremely
like
stuff.
That
would
just
never
never
fly
at
gilab,
and
it
also
does
seem
that
you
know
with
it
with
like
the
thanks
Channel,
where
everyone's
you
know
thanking
each
other,
the
bonuses
for
doing
a
good
job
and
the
collaborative
aspect
of
people
also
I.
Guess
it's
probably
like
the
fact
that
we
work
in
so
many
different
time
zones.
B
It
kind
of
helps
facilitate
that,
because
a
lot
of
time
you'll
work
on
something
and
you'll
pass
it
off
to
another
developer.
That
is
just
starting
in
Europe
as
you're
going
to
sleep,
and
then
they
can
pass
it
on.
So
we
really
have
to
be
strong
with
collaboration
and
also
because
the
workflow
is
so
asynchronous.
F
F
A
F
A
I
was
reading
through
the
chapter
and
through
the
examples,
I
feel
like
building
the
strategy
and
working
on
all
those
things
is
very
political.
Like
you
need
to
contact
the
right
people,
you
need
to
get
a
sponsor.
You
need
to
get.
You
know,
try
to
convince
certain
key
people
that
are
decision
makers
and
it's
like
I,
don't
know
a
lot
of
back
and
forth
until
you
can
present
a
proposal
that
most
people
would
say.
D
Every
engineer,
even
if
you're
senior
or
not
I,
think
it's
it's
about
it's
about
communication
and
making
sure
you
have
common
understanding
with
whoever
you
are
interacting
with
so
the
most
direct
example
in
the
chapter
is
about
asking
other
people
to
work
on
your
project.
That
is
not
even
their
main
focus,
so
that's
really
what
other
people
call
the
idle
position
or
politics,
but
it's
it's
basically
work.
I,
guess
to
me.
E
G
Yeah
I
think
I
agree
with
both
album
Tong.
That
often
in
my
experience,
it's
been
more
about
China
wine,
your
goals
with
other
people's
needs,
rather
than
the
sort
of
politics
side
of
things,
and
that's
not
always
immediately
obvious
for
the
person
who's
receiving
the
information
as
well,
because
they're
other
competing
challenges,
that'll
take
their
attention
as
well.
Yes,
I
think
it
definitely
seems
like
something,
that's
more
like
a
problem
for
not
a
problem
but
a
challenge
for
any
level
but
yeah.
G
A
B
F
F
F
D
E
It
reminds
me
of
what
a
Peter's
manager
told
me
like
whenever
we
share
ideas
like
the
thing
that
we
always
have
to
think
about
this,
can
we
answer
a
question
from
there
like
the
audience
like?
What's
in
it?
For
me,
if
someone
asks
you
what's
in
this
for
me,
we
should
be
able
to
answer
that
clearly
that
will
help
us
get
better
alignment.
D
Amounts
I
guess
because
they
were,
let
me
described
two
previous
attempts
which
failed
right
so
like
in
a
more
political
culture.
Those
two
people
would
have
been
like
could
have
been
sidelined
or
faced
repercussions
or
failing
like
it
can
be
misused
for
sure
like,
but
it
really
is
really
up
to
your
organization
and
culture,
not
not
prepare
for
her
things
like
that
with
misuse.
Otherwise,
no
one
will
ever
step
up.
B
Yeah
I
was
just
this
kind
of
goes
back
to
I,
guess
the
scope
or
the
size
of
the
scope
on
some
of
the
stuff.
Where
really
we
were
discussing
that
some
of
these
are
really
really.
You
know
it
seems
quite
quite
large
and
I
guess.
I
wasn't
really
didn't
didn't
know
if
this
was
beyond
the
staff
engineer.
Role
at
gitlab
and
I
was
talking
about
the
the
sock
matcher
case
study
where
they
they
talk
about
a
high
level,
one-year
technical
strategy,
because
yeah
I
haven't
seen
anything
but
I'm.
B
Just
you
know.
Judging
from
like
the
small,
you
know
view
that
I
have
on
my
team
and
the
staff
Engineers
that
I've
worked
closely
with
I
haven't
seen
anything.
That's
been
that
big
like
a
year
plus,
but
it
looks
like
Tong
points
to
the
architecture
page,
and
it
seems
that
some
of
those
may
may
be
taken.
You
know
a
year
or
more
and
it
looks
like
those
are
created
by
staff
engineers
and
Coach
coaches
at
a
higher
level.
E
D
The
blueprints
are
things
that
actually
people
have
agreement
on,
so
that's
why
they
get
written,
but
in
addition
to
the
Bruins
are
social
there's
also
working
groups
as
well,
that
have
been
around
for
more
than
a
year
and
deciding
for
things
that
are
bigger
than
a
year.
So
I
think
the
the
a
good
example
is
the
API
Vision
I
think
yeah
we're
deciding
what
to
do
about
our
API
long
term.
B
D
B
B
E
D
But
yeah
and
I
think
there's
a
page
that
says,
like
the
the
kind
of
the
time
frames
staff
engineer
is
defining
for
and
it's
like
three
to
six
months
or
something
like
that
and
then
as
a
guideline
and
then,
if
your
principal
is
six
to
nine
months,
distinguish
it's
very
long
time.
Friends,
yeah,
okay,.
E
I
think
I
have
another
question.
Yes,
so
I
think.
What's
the
recommendations,
though,
is
that
the
private
things
to
get
the
technical
strategy
completed
like
in
terms
of
execution,
it's
usually
like
video
or
particle
here
at
home,
but
how
long
does
it
take
to
actually
write
a
technical
strategy?
I
did
take
a
lot
of
like
many
months,
or
is
it
like
a
one
with
trying
to
work,
or
maybe
they're
insulted
in
that,
like
once
the
process
like
to
to
completely
write
a
technical,
they
just
get
it
to
stay
prayer.
E
E
D
D
It
depends
on
how
how
big
the
thing
is,
but
for,
for
example,
for
the
ports
strategy.
I
think
it
took
about
three
months.
I
think
we
had
like.
Oh
I,
don't
know,
maybe
a
bit
more
than
that,
but
we
spent
a
few
months,
yeah
understanding
what
we're
even
trying
to
do
and
and
then
kind
of
brainstorming,
what
kind
of
high
level
strategies
that
we
want
to
use
and
then,
when
it
came
to
writing
we
we
went,
we
actually
went
a
bit
against
the
flow
actually
because
we
we
said
okay.
D
This
is
too
much
stuff.
If
you
write
everything
we'll
get
nitpick
to
death
and
it
will
never
get
merged.
So
we
just
wrote
one
paragraph
saying
this
is
the
strategy.
This
is
the
goal
I'm!
Sorry,
this
is
the
goal,
and
this
is
a
strategy
in
two
paragraphs
and
then
say
we're
gonna
merge
it.
So
that's
that's
how
we
start
them.
D
B
Yeah,
this
was
just
a
an
observation
as
I
was
reading
through
I
guess:
I
guess
you
know,
maybe
all
of
us
kind
of
read
through
these
chapters
in
a
similar
frame
of
mind
where
we're
comparing
the
content
of
the
chapters
to
our
experience
at
gitlab,
and
you
know
when
they
talk
about
monolith.
Of
course,
my
brain
just
starts
thinking
about
the
gitlab
monolith
and
I
want
to
say
no
developers
want
to
work
on
the
monolith.
It's
you
know.
B
There
are
definitely
challenges
when
working
on
the
gitlab
monolith,
as
opposed
to
working
on
for
isolated
components
that
you
know,
Docker
containers
analyzers
that
kind
of
stuff
but
yeah.
One
of
the
things
that
they
were
talking
about
in
the
case
study
was
about
componentizing.
The
monolith
to
you
know
make
like
shared
components
and
to
make
it
easier
to
work
on
things
individually,
and
it
just
reminded
me
of
this.
B
Other
large
issue
that
I
think
has
been
had
has
had
a
lot
of
back
and
forth
in
the
discussion,
which
was
a
proposal
to
split
the
monolith
into
components,
and
you
can
kind
of
see
after
the
the
author
of
the
of
the
book
was
laying
out
all
of
the
different
challenges
you
can
kind
of
see.
You
know,
because
sometimes
you
think,
oh
yeah,
why
don't
we
do
this?
Why
don't
we
just
make
microservices
you
know,
and
then
one
of
the
things
that
the
author
talks
about
was
that
okay
yeah
I
could
take.
B
We
could
do
that,
but
it
could
take
three
years
and
then
there's
also
a
set
of
problems
and
challenges
with
that.
So
yeah,
it's
just
an
observation
in
case
anyone
hadn't
seen
that
issue.
It's
an
interesting
one
to
see
where
some
people
are
maybe
trying
to
it's
in
the
very
early
stages
of
maybe
something
that
will
become
much
bigger.
B
And
I
guess:
I
got
the.
Unless
anyone
wants
to
discussed
that
that
particular
item,
then
the
next
one
is
about
using
feature
Flags
that
another
thing
as
we're
relating
it
to
ourselves
that
yeah,
you
know
feature
flags
are
already
something
that
we
use
quite
a
bit
and
then
Jamie
I.
Guess
you
had
an
add-on
Point
forget
about
that.
Yeah.
A
Like
it's,
it's
great
how
it's
integrated
into
getting
the
git
love
monolith,
it's
just
there.
It
works.
We
have
the
infrastructure
around
it.
We
have
the
chat,
Ops
and
everything
works
great,
but
when
it's
when
it
comes
to
satellite
projects
or
other
projects
like
container
registry
Pages,
the
ones
I've
been
working
on
mostly,
but
there's
a
cast
agent
as
well.
We
don't
have
a
like
a
proper
solution
for
it.
There
are
proposals.
A
Every
project
has
its
own
issue
that
is
trying
to
list
how
they're
going
to
solve
it,
but
we
haven't
like
actually
reached
a
conclusion
on
how
we're
gonna
get
to
the
next
stage
and
build
it.
I
kind
of
I
was
working
on
this
and
I
got
stuck
like
I,
didn't
know
how
to
move
forward
and
I
just
kind
of
forgot
about
it.
But
it's
you
know,
as
I
was
reading
through
the
chapter.
I
was
I
kept
relating
to
that
project
and
say:
okay.
How
can
I
get
to
the
next
step
on
this?
B
A
Think
it
was
more
political,
like
I
had
a
proposal
and
I
didn't
get
a
no
from
people
which
I
you
know
after
I
finished
reading
the
chapter
it
was
like.
If,
if
there's
no
disagreement,
it's
probably
an
okay
solution.
When
people
are
not
happy
with
the
solution,
they
will
all
raise
their
voices
and
say
no.
A
B
Oh
yeah
I
did
find
that
Point
interesting
where
they
said
that
because
sometimes
I'm
working
on
something
and
I'm
trying
to
get
agreement
from
everybody.
So
that
was
an
interesting
point
that
the
they
introduced
in
the
chapter
was
talking
about
that.
You
don't
need
agreement,
you
know
you
don't
need
complete
consensus,
you
can
just
say:
is
there
anything?
Is
there
anyone
that
doesn't
agree
with
this
or
is
there?
Is
there
anything
any
part
of
this
plan?
That
is
unacceptable
for
you
and
if
no
one
raises
their
voice,
then
yeah?
B
That's
you
can
move
forward
on
that
because
I've
definitely
gotten
stuck
trying
to
I.
Remember
it
was
it
took
six
months
to
make
one
small
change,
because
nobody
could
agree
on
this.
One
small
change
and
I
in
writes
about
retrospect,
I
guess
maybe
I
should
have
said
you
know
is,
but
even
even
then
on
that
one
small
change,
even
if
I
did
say,
does
anyone
have
disagree?
Is
anyone
disagreeing
with
it?
D
The
other
approach
is
to
just
break
the
knot.
The
chicken
egg
situation
is
potentially
writing
a
small
POC,
so
you
have
a
better
idea
on
whether
to
justify
more
time
or
not
because
in
the
beginning
might
say:
okay,
this
project
sounds
good
and
then
three
years
later,
you're
still
working
on
it.
So
that's
the
last
thing
you
want
right
so
yeah,
because,
especially
if
you
didn't,
you
didn't
get
permission
to
to
schedule
on
things
there.
So
that's
why
a
small
PLC
would
help
clear.
Some
of
this
ambiguity
is
even
Union
online
as
well.
A
B
F
I
think
it's
maybe
related
to
the
some
of
the
things
that
I
just
read,
because
I
started
late,
but
there
was
a
saying
about
like
stuff
engineer
overseas
above
their
own
group.
So
you
need
to
see
what
other
groups
are
being
affected
by
the
changes
that
you're
making
and
if
the
opposition
was
coming
from
that
group
that
causing
creating
more
job.
Because
of
you
are
making
such
a
change,
then
that's
something
that
we
need
to
consider
more
seriously.
E
D
D
F
Yeah
one
thing
that
I
find
useful
is
as
much
I
mean,
provide
as
much
information
as
possible.
Up
front
is
helpful,
as
opposed
to
trying
to
answer
the
question
after
the
fact,
because
I
feel,
like
some
people,
don't
read
all
the
comments.
They
just
see
the
first
one
and
then
just
comment
so
I
think
it'll
be
best
to
describe
this
is
the
plan
and
we
consider
this.
This
is
and
then
this
is
where
we're
gonna
go,
and
we
know
that
there's
a
problem
like
this,
but
you
think
that's.