►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hey
everyone.
We
are
here
to
discuss
chapter
8
of
the
staff
Engineers
path.
This
is
the
Americas
and
APAC
time.
Slot
and
chapter
8
is
good
influence
at
scale.
A
B
Yeah
I
I
really
liked
how
it
mentioned.
You
know,
being
letting
people
kind
of
level
up
into
the
position,
and
my
last
job
I
I
went
around
and
I
asked
people.
Would
you
hire
the
version
of
you
that
got
hired
for
your
position
and
everyone
said
no
everyone's
like
no
way
and
I.
Think
I
do
remember
like
my
first
few
months
at
gitlab
being
like
well,
they
made
a
mistake
and.
A
A
That's
a
common
mindset
in
our
industry
kind
of
is
like
part
of
the
Imposter
syndrome
of
like
you
know,
I'm,
not
I'm,
not
actually
this
level
engineer
yet
and
and
then
by
the
time
you
are
you're
like.
Why
is
anyone
even
think
I
was
but
in
reality
like
there's
such
a
big
range?
You
just
have
to
remember
that
and
I
still
struggle
with
that.
But
but
it's
it's
an
interesting
reminder
that
there's
like
a
constant
spectrum
of
skills
in
any
given
level
and
in
any
given
position.
B
Yeah
and
I
I
think
as
you
as
you
get
higher
up
or
further
along
in
your
career
even
and
further,
along
with
your
position
in
a
are
like,
as
you
spend
time
with
a
project
I
think
it's
one
of
those
things
like
going
from,
like
you
know:
High
School,
to
college,
to
grad
school
to
doing
a
doctorate
there's
this
great
graph
of
like
you
know
the
area
of
study
that
you're
really
working
on
just
gets
smaller
and
smaller
and
smaller,
and
doesn't
transfer
and
I.
B
Think
that
happens
with,
like
your
Knowledge
and
Skills.
As
an
engineer,
I
think
I
think
you
a
lot
of
value
is
from
like
having
a
deeper
understanding
of
something
specific
and
something
that
could
be
specific
to
the
projects
you're
working
on
or
more
broadly,
even
the
company,
and
that
just
you're
not
going
to
come
with
that.
You
know
you're
not
going
to
show
up
with
the
batteries
included
in
that
way.
A
I
thought
that
I
had
noted
here
and
see
if
you
can
find
it
so
there's
this
kind
of
realization
that
I
had
when
it
was
talking
about
like
the
different
scales
of
influence.
A
And
there
was
like
there's
the
individual
influence
the
group
influence
and
then
the
Catalyst
level,
which
is
kind
of
like
influencing
the
whole
organization
in
some
way,
and
the
nice
realization
that
I
had
was
that,
like
a
lot
of
those
things
require
many
of
the
skills
that
were
previously
discussed
in
the
book.
So
the
example,
the
author
gives,
is
like
you
know,
you
can
start
by
just
like
mentoring,
one
person,
but
then
the
Catalyst
level
is
like
creating
a
mentorship
program
which,
like
like
that's
actually.
A
How
do
you
do
that,
like
at
Kayla
like
I,
could
create
an
issue,
but
that
doesn't
necessarily
go
anywhere,
but
you
know
like
leading
the
the
skills
that
were
kind
of
discussed
and
like
creating
your
different
maps
and
leading
big
projects,
kind
of
we're
all
applicable
to
how
you
might
get
something
like
that
done,
and
so
I
I've
always
considered
those
types
of
things
like
the
ability
to
lead
big
projects
or
influence.
C
B
Yeah
and
I
was
just
thinking
like
not,
you
know,
starting
small,
like
mentoring,
one
person,
you
know
when
you
first
try
to
Mentor
somebody.
It
doesn't
quite
go
as
well
as
planned,
not
that
you'd
necessarily
do
bad,
but
you
don't
quite
live
up
it's
harder
than
you
think
so,
I
think
I
think
you
do
need
to
build.
You
know
you
kind
of
have
to
cut
your
teeth
on
the
small
scale,
to
really
know
how
to
how
to
blow
things
into
larger
scales.
How
to
how
to
you
know
see
some
of
the
commonalities.
B
You
know
you
can't
just
maybe
you
had
one
mentee
and
they
got
things
a
certain
way,
but
you
know
if
you
have
three
or
four,
you
kind
of
realize
that
people
have
different.
They
come
from
different
places
and
the
same
explanations
don't
work,
and
so,
if
you
only
have
the
more
experience
you
have
with
one-on-one
mentoring,
it's
a
lot
easier
to
build
an
effective
program
that
targets
more
people.
Although
your
first
program
that
targets
more
more
people
is
going
to
be
bad,
probably
too.
C
Yeah,
that's
exactly
right,
I
think,
yeah
and
also
like
half
the
time
as
you
boot
it
up
you
you
realize
that
maybe
you
are
or
you're
not
the
right
person
to
start
that
or
that
they
they
isn't
really
a
need
to
have
a
wide
encompassing
program
or
maybe
maybe
you
make
the
case
for
it,
but
yeah
I
think
the
book
does
mention
that.
Don't
worry
so
much
about
jumping
on
a
catalyst
part
but
yeah
focus
more
on
the
the
middle
part.
A
C
A
D
The
point
about
this
section
that
that
I,
like
is
that
tried
to
have
that
largest
Catalyst
level
scope
of
influence
is
often
not
the
right
thing
to
do,
because
it's
not
appropriate
for
the
organization.
For
example,
you
can't
go
from
you
know
an
environmental
code
reviews
to
every
every
change
must
have
a
card
review
or
you
can't
go
from
an
environment.
If
we're
not
documenting
anything
to.
We
must
document
everything
you
have
to
tailor
what
you're
attempting
the
scope
and
drastic
drasticness
I
don't
know.
B
Yeah
I
I
forget
where
I
learned
this
that
I
was
told
when
you
get
to
a
new
organization.
You
get
to
do
one
big
thing
and
if
you
do
that
big
thing
you've
succeeded,
you
know,
and
that
will
be
hard
and
at
my
previous
job,
I
really
like
championed
unit
testing,
and
it
was
all
I
talked
about
for
four
years
and
it
took
four
years.
D
B
Once
you
convince
somebody
to
do
it,
I
think
if
they
haven't
been
unit
testing,
they
kind
of
they
really
see
the
benefit
quickly
and
that's
as
soon
as
I
got
the
right
person
convinced
he
was
a
bit
louder
than
I
was
about
it
and
was
able
to
kind
of
evangelize.
So
there
was
some
momentum
that
got
built
up
by
that.
C
C
Right
yeah.
B
I
think
when
I
do
code,
reviews
I
try
to
be
you
know,
EX,
you
know
fair
and
like
willing
to
have
people
not
do
this,
like,
like
the
book
said
like
there's
no
clone
of
Haley
running
around
but
like
be
fair
and
be
open
to
different
approaches,
but,
like
the
example
I'm
thinking
of,
was
somebody
fix
a
bug
and
bump
the
Go
version
in
one
commit,
or
one
more
and
I'm
like
hey
like
this,
absolutely
has
to
be
split
up
and
like
I,
don't
think
I
said
it
that
way,
but
I
was
like
Hey
when
he
splits
up,
because
there's
so
many
changes
that
happen
under
the
hood,
with
the
version
bump
that
it's
really
helpful
to
have
it
in
its
own
line
and
get
history,
and
this
helps
us
like.
B
If
there
is
a
problem
due
to
the
version
bump,
we
can
roll
it
back
really
easily
without
reverting
other
things
and,
like
you
know,
having
that
standard,
but
also
trying
to
not
just
you
know,
explain
like
why
the
why
the
feedback
is
coming
in
and
like
try
to
like
make
it
a
point
of
like
education,
I
guess.
B
Yeah
I
think
I
think
one
of
the
things
I've
had
to
I
think
I've
started
saying:
is
it's
really
honestly
difficult
to
make
a
Mr?
That's
too
small
and
kind
of
free
people
as
like
you
know,
try
to
try
to
make
a
mistake
by
making
it
too
small
right.
If
we
try
to
try
to
make
it
a
too
small
a
bar,
and
it's
actually
pretty
difficult
to
do
that.
You
know.
D
D
It
takes
in
many
ways
like
some
Advanced
engineering
and
architecture
thought
to
decide
where
do
I
start.
Where
is
the
piece
of
this
that
I
can
pull
off
to
do
a
cohesive
change
and
not
have
a
giant
Mr?
That
is,
you
know,
pulling
at
the
the
fashion
and
drills
of
the
the
big
ball
of
mud
and
so
again
that's
an
opportunity
for
for
educating
people.
It's
like
okay.
D
Well,
maybe
don't
start
here
start
start
over
there
in
this
little
area,
and
then
you
can
do
this
change
in
you
know
with
no
dependencies
and
then
you
could
start
building
on
that.
But
I
do
think
it's
it's
difficult
in
a
somewhat
unstructured,
not
definitely
not
well
structured
monoliths,
as
we
have
here.
B
More
seriously,
though,
I
think
one
of
the
things
that
I
I
like
to
do
is
like
the
refactor
sandwich
like.
Can
you
do
refactoring
in
anticipation,
and
can
you
do
refactoring
after
after
the
manamars
go
through
just
to
like
I
think
the
principle
that
I
try
to
think
about
is
what
where's
the
actual
logic
change
coming
from
and
how
do
I
make
that.
B
Into
how
do
I
isolate
that,
and
so
like
I
can
be
like
hey.
This
Mr
is
changing
the
logic
and
you
don't
have
to
worry
about.
You
know
things
getting
pulled
into
functions.
All
this
kind
of
stuff,
like
you
can
just
say,
like
hey.
D
And
often
that,
like
again
the
pulling
into
the
senior
skills
that
are
needed,
that
becomes
political
because
then
the
the
product
manager
may
be
saying.
Well,
why
are
we
doing
this
refactoring?
Why
aren't
we
just
delivering
the
future?
You
know,
and
you
have
to
have
that
discussion
and
explain.
Well,
okay
with
we
really
need
to
do
this.
It's
not
just
me
wanting
to
go
polish.
D
This
is
why
we
have
to
reorganize
this
stuff
and
in
separate
Mrs,
maybe
a
couple
of
them
before
we
can
even
actually
start
working
on
the
feature
and
that
politics
and
communication
is
often
you
know
the
hardest
part
like
split
figure
out
how
to
split
apart
technically
and
the
refactor
is
a
technical
challenge,
but
defending
that
decision
and
the
the
longer
scope
of
effort
to
the
stakeholders
who
just
want
the
future
done
is
a
non-technical
skill.
B
Yeah
and
I
think
I
think
it's
good
to
be
challenged
on
that
I
think
if
I
was
left
to
my
own
devices,
I
would
definitely
just
beautify
the
registry
code
base
for
the
next
two
years,
but
I
think
there's
I
think
there's
like
big
r
refactoring
and
little
r,
refactoring
and
they're
sort
of
refactoring.
That's
like
I
have
to
I'm
going
to
do
this
in
the
course
of
like
if
I
was
just
changing
the
Mr
doing
it
in
one
big
go
and
just
trying
to
get
the
info
implementation
done.
D
C
That
is
his
own
justification,
because
the
small
art
refactor
is
obvious.
Right,
like
you,
are
making
the
code
review
smaller,
but
also
de-risking
the
landing
order
change,
because
you're
separated
out
of
the
refactoring
the
reflecting
is
going
to
land
on
its
own
cycle.
The
actual
logic
thing
is
going
to
end
landing
on
his
own
cycle.
They
can
be
independently
reverted,
so
yeah
and
I
think
like
I
would
be
very
concerned
if
product
managers
are
questioning
the
small
with
factorings
because
like
why.
D
But
in
some
cases
the
Big
R's
are
needed.
Like
you
know,
the
I
worked
a
long
time
on
the
captcha
stuff
and,
like
I,
asked
several
staff
Engineers
like
when
I
first
saw
it
I
was
like
I
think
we
need
to
mostly
rewrite
the
front
end
and
the
back
end
of
this
talk
me
down.
D
If,
if
you
disagree-
and
nobody
did
so
like
I
spent
several
months,
just
sort
of
doing
a
big
RV
factoring
on
it
and
put
it
in
a
place
where
it's
easier
to
just
Implement
features
on
top
of
it
in
the
future-
and
you
know
luckily
got
support
for
that,
even
though
it
wasn't
part
of
of
my
group,
but
that
often
doesn't
happen.
One
thing
I
I
think
is
really
missing
in
the
industry.
D
I've
only
seen
like
a
couple
of
articles
that
or
maybe
presentations
that
talk
about
this
one
from
a
game
company
is
like
how
can
you
be
quantifiable,
like
and
and
have
a
methodology
for,
assessing
technical
debt,
because
there's
so
many
things
that
go
into
it?
It's
like
does
this.
You
know
how
big
not
just
how
big
is
this
or
what
does
it
impact,
but
it's
like
how
how
annoying
is
this?
Is
this
something
that
makes
you
know
Engineers
just
want
to
quit
their
job
and
move
somewhere
else.
D
Does
it
affect,
and
if
so,
does
it
affect
them
every
day
or
do
they
see
it
like
once
every
six
months?
Is
it
something
that
is
like
a
security
concern
that
will
get
us
on
the
front
page
of
Hacker
News
in
a
bad
way?
Is
it
you
know
something
that
is
going
to
metastasize
and,
be
you
know,
cargo
culted
throughout
the
code
base
and
and
be
harder
to
undo,
or
is
it
something
that's
going
to
remain?
D
You
know
buried
over
in
a
corner
and
like
all
of
those
things,
sort
of
go
through
my
head
when
I'm
you
know
making
this
decision
like
it
is
to
say
I
refactoring
that
I
want
to
fight
to
be
able
to
do
or
not,
but
there's
really.
No,
that's
why
I
call
to
say
what
we
do:
a
craft
or
an
art.
It's
not
an
engineering
discipline,
because
there's
there's
no
quantifiable
metrics
for
that.
It's
like
a
philosophy,
much
more
around
the
philosophy
and
and
get
feel
and
experience.
C
I
find
it
constantly
surprising
and
in
awe,
like
lots
of
things,
annoy
a
lot
of
Engineers,
but
I
don't
get
annoyed
very
often
so
you
know
so
there.
There
is
a
lot
of
different
code
bases
that
suit
different
people,
and
that's
probably
why
it's
not
really
quantifiable.
D
And
the
parts
that
I've
that
I
never
see
people
giving
enough
weight
to,
but
in
my
opinion
it's
like,
maybe
you're
different.
But
for
me
you
know.
The
senior
Engineers
when
they're
having
to
work
in
a
code
base
is
just
painful
and
feels
like
it's
walking
through
mud.
The
best
most
talented
Engineers
are
the
ones
with
the
most
opportunities
to
just
say.
You
know
what
walk
away:
I'm
gonna
work
somewhere
else,
and
so
it's
like
a
risk
of
losing
really
good
talent.
D
By
saying
no
we're
just
going
to
live
with
this
technical
debt,
we
need
to
crank
out
features,
you
know
and
you
may
lose
some
Engineers
that
could
have
like
cleaned
up
that
technical
debt,
if
you
would
have
given
them.
You
know
six
months
and
then
gone
on
to
like
let
like
we
said
in
this
chapter
leverage
that
into
enabling
everyone
else
to
deliver
features
at
a
faster
velocity
for
a
much
longer
time.
So
I
often
see
that
short-sightedness
in
respect
to
large-scale
technical
data
at
the
management
level
and
Technical.
D
B
Yeah
I
I
think
one
of
the
things
that
that
can
be
done
is
if
you
really
think
that
every
factor
is
necessary,
have
an
issue
for
that
and
then
kind
of
take
stuff
where
you
notice
like
hey
this
was
slow.
You
know
there
was
a
bug
that
kind
of
stems
from
not
having
that
refactor
done
and
you
kind
of
have
a
narrative.
That's
like
hey,
like
we
lost
velocity
here,
and
here
there
was
a
bug
here
and,
like
my
my
take,
is
that
a
refactor?
B
Would
you
know
in
the
future
gain
that
velocity
and
reduce
these
bugs
and
I
got
the
Martin
Fowler
like
refactoring
book
and
his
his
shtick
as
I?
Remember
it?
Is
that
like
finding
ways
to
iterate
on
the
radio
factoring
where,
like
every
step,
kind
of,
improves
the
code
base
and
you
don't
have
to
really
take
a
detour
but
make
it
sort
of
part
of
the
main
path
forward?
B
I
know
that's
not
always
possible,
but
if
you
can
find
a
way
to
do
that
and
sort
of
not
not
slow
down,
while
you
do
the
refactor
I
think.
That's
that's
a
that's
like
the
ideal
approach,
but
I
think
you.
A
B
If
you,
if
you
do
have
to
like
literally
take
like
time
away
from
new
issues,
just
to
do,
a
refactor
I
think
is
responsible
to
have
like
a
collection
of
like
this.
Is
you
know
this?
This
missed
a
milestone
because
refactor
related
like
issues
that
would
have
been
solved
with
the
refactor.
This
is
a
bug
that
you
know
would
have
been
less
likely,
if
not
impossible
with
the
refactor,
you
know
have
have
have
basically
evidence,
and
then
you
can
present
that.
D
D
You
know,
I,
don't
answer
specifics,
but
I've
heard
a
direct
story
from
gitlab
of
like
where
there's
evidence
presented,
saying
I
I
think
it
was
the
database
split
saying
we
are
definitely
going
to
fall
over
we're
going
to
hit
hit
the
the
size
limit
of
a
field
in
this
period
of
time.
We
have
to
do
this
and
there
was
still
you
know
a
lot
of
obstacles
to
overcome
to
to
start
that
and
I'm
sure
dung
has
more
context
on
that.
D
But
that's
how
I
remember
the
from
some
people
that
the
initial
discussions
around
that
you
know
the
initial
database
split
refactoring.
It
wasn't
just
like.
Obviously,
oh
yes,
we
definitely
need
to
do
that.
Go
do
it.
There
was
still
a
lot
of
justification
for
something
that
was
like
absolutely
necessary.
D
And
so
for
something
like
well,
let's
some
you
know
make
things
less
couple:
let's
make
the
service
layer
more
cohesive.
Let's
you
know
clean
up
the
boundary
between
graphical
service
layer,
which
is
a
very
nebulous
goal,
but
you
know
can
would
increase
velocity
on
features
in
the
monolith.
D
B
Yeah
I
think
I
think
it's
hard
as
an
engineer
to
like
take
this
on.
But
you
know
we
don't
we
don't
deliver
a
code
base,
that's
not
the
product
right,
it's
the
artifact,
it's
like
what
gets
them.
What
like
makes
it
into
production,
what
gets
compiled?
It's
the
behavior
that's
presented
to
the
user,
and
sometimes
it's
just
worth
having
bad
code
that
does
a
good
job
and
like
it
can
be
really
sometimes
the
bit.
Sometimes
the
sometimes
the
mbas
are
right.
This.
D
A
So
back
on
that
that
the
original
question
of
like
creating
good
influence,
because
we
kind
of
like
gone
down
the
refactoring
side,
side
quest,
so
I'm
curious,
then
like
when
it
comes
because
they're
like
there
are
these
certain
topics
that
are
like
become
like
pretty
opinionated
and
obviously
in
a
place
like
gitlab,
where
we
have
a
couple
hundred
Engineers
that
are
all
going
to
have
differing
opinions.
A
I
guess
like
looking
at
git
lab
I
guess
we
can
look
at
it.
Two
ways
like
like
who
are
the
people
I
mean
we
don't
like
name
names
or
anything
but
like
like
how
are
the
people
that
are
currently
creating
in
the
influence
like
the
the
culture
of
like
how
we
view
refactoring
as
a
company?
A
How
are
they
doing
that
and
then
like,
if,
like
kind
of
back
to
that
same
original
question
like
it,
if
you
saw
a
really
good
reason
that
we
needed
to
change
our
philosophy
or
you
know,
maybe
within
your
group,
we
need
to
do
things
a
certain
way
like
what
are
the
actions
you
might
take
to
do.
That.
D
Yeah,
reducing
the
scope
of
the
change,
wherever
possible,
I
think
is,
is
a
good,
a
good
way
to
do
it.
It's
the
ones
where
that's
not
possible,
when
it's
truly
the
scope
of
the
entire
application
that
it
becomes
very
difficult
and
political,
and
when
the
people
who
are
advocating
for
that
change,
don't
have
the
influence
to
make
that
that
level
of
investment
happen,
but
I
understand
and
other
thoughts.
C
Yeah
I,
like
I,
like
Hilly's
idea
of
opening
issues
like
and
then
creating
thoughtful,
a
thoughtful
case
for
it.
It's
not
always
successful
in
my
personal
experience,
but
sometimes
sometimes
it's
quite
useful
as
well,
especially
for
bigger
things.
But
then
the
book
talks
about
you
know
don't
worry
about
being
a
catalyst
yeah.
C
A
Yeah
I
think
I
agree,
like
I
mean
not
just
with
the
refactoring
but
like
in
the
general
sense,
like
some
of
the
most
successful
arguments,
I've
seen
for
like
changing
something
that
the
like
group
level
or
even
at
the
like
our
levels
like
there's,
an
issue
that,
like
everything
that's
written
in,
it
seems
so
obvious
that
you're
reading
it
and
you're
like.
Why
did
someone
take
so
much
time
to
even
write
this?
It
would
have
it's
like
you
know.
A
B
Yeah
and
I
think
I,
don't
I,
don't
know
necessarily
like
if,
if
you
can
sort
of
like
put
the
bad
code
in
a
box
and
just
sort
of
like
and
leave
it,
that's
always
like
a
good.
You
know
like
if
you
have,
if
you
have
bad
working
code,
that
you
never
have
to
like
open
up
and
see
like
if
you
looked
at
the
date
library
of
any
programming
language,
you
know
it's
your
face
would
melt
off
right,
but
you
never
have
to
think
about
it.
B
A
D
Yeah,
that's
like
the
the
heuristic
of
like
how
much
does
this
matter
like
in
the
other
end
of
the
spectrum
is
like
well,
you
know.
Is
this
going
to
metastasize?
Is
it
going
to
get
cargo
culted
as
mad
patterns
over
and
over
throughout?
The
database
like,
for
example,
leaky
or
poorly
defined
abstraction
boundaries
between
the
graphql
versus
surface
layer
and
error?
How
error
handling
should
work
and
where
it
should
happen
to
pull
a
random
example
out
of
our
own
monolith?
That's
something
it's
like
well.
D
B
B
So
it's
been
a
minute
since
I
have
read
this
well
good
I
press
enter
and
Google
Docs
did
not
do
it,
I
think
it
did.
Okay,
I
think
I
didn't
mess
anything
up
so
riot
games
famous.
D
D
B
Yeah
yeah
I
think
I
think
as
a
way
to
influence
sort
of
borrowing.
Credit
credibility
is
always
something
I
like
to
do
like
hey.
It's
not
just
I
that
have
thought
of
this.
Like
here's,
this
company,
that's,
like
you
know
it's
a
real
business
who
started
this
or
here
it's
just
like
you
know,
Dev,
who
has
the
blog
that
everyone
knows
that,
like
Dave
Chaney,
if
you,
if
you
do
go
like
everyone
knows,
Dave
Cheney,
you
can
point
to
a
jade
chat.
B
You
know
Dave
Chaney
article
and
be
like
hey,
like
somebody
who's
way
better
at
thinking
and
writing
about.
This
is
thought
and
wrote
about
this
and,
like
I,
agree
so
sort
of
like
I,
think
that
makes
it
look
a
little
less
like
sort
of
your
personal
opinion
and
something
that
you
know
you
don't
necessarily
have
to
spend
the
time
articulating
it
as
well
as
it's
been
articulated
by
somebody
who
spends
a
lot
of
time.
Thinking
and
writing
about
these
ideas.
D
Yeah
exactly
it's
like
so
awesome
that
you
found
that
the
one
article
that
I
randomly
alluded
to
earlier,
like
I,
would
love
to
see.
You
know
this
as
an
inspiration
for
something
that
makes
it
in
the
handbook
to
say,
like
here's,
at
least
an
attempt
at
quantifying
our
decisions
about
whether
and
how
to
prioritize
technical
bit-
and
you
know
with
our
own,
take
on
this
and
our
own
taxonomy.
That
makes
sense
at
gitlab.
That
would
definitely
be
a
staff
plus
plus
sort
of
initiative.
You
would
need
a
lot
of
like
a
couple.
D
B
Think
you
could
I
think
yes,
yes
and
no
and
I
think
you
could
convince
your
team
to
do
this.
You
know
and
then
sort
of
say,
like.
D
B
Did
an
experiment
and
visit
the
results
and
you
can
sort
of
have
that
filter
up
and
I,
don't
think
I,
don't
think
you
have
to
look
to
I
think
you
can
start
it
sort
of
your
scope
of
influence.
B
C
Yeah
it
it
shows
that
it's
practically
applicable,
which
is
what
people
like
me
look
for,
because
if
you
can
bring
something
that's
already
been
applied,
then
that's
one
evidence
that
we
can
take
up
to
say:
let's
apply
it
globally,.
B
Yeah
and
I
think
thinking
about
that
article,
like
one
of
the
things
that
I
remember
liking
about
it,
there's
been
a
few
years
since
I've
read
it
is
they
had
hacky
solutions
to
some
of
their
problems
that
are
just
like
hey?
This
is
not
the
right
way
to.
This
is
not
the
right
way
to
do
this.
This
is
the
way
we
did
it
because
it's
faster
and
it
works
and
there's
no
there's
not
a
risk
of
this
sort
of
like
spreading
and
causing
problems
elsewhere.
B
It's
and
so
I
think
I
think
that
was
like
a
good
kind
of
level-headed
way
to
to
use
sort
of
engineering
time
wisely
in
a
way
that
feels
kind
of
bad
as
an
engineer
because
they
had
something
that
was
like
objects
were
like
passing
through
barriers,
and
they
just
say
well,
we'll
just
like
spawn
more
barrier
objects
and
call
it
a
call
it
a
day
which
everyone's
written
code
like
that
and
it
never.
It
always
feels
like
a
moral
failing
as
the
software
developer.
It's
like
I
should
have
been
like
nobody.
A
D
A
C
Yeah,
especially
if
it's
self-contained
right,
it's
it's
it's
terrible,
but
it's
self-contained
and
you
judge
that
when
people
copy
their
email
list
seems
terrible,
so,
okay,
that's
fine.
They
can't
do
a
judgment
as
well,
but
if
people
copy
unconsciously
the
thinking
is
good,
then
too
bad
but
yeah,
I,
I
I'm.
On
the
same.
D
Yeah,
that's
their
contagion.
Factor
like
how
contagious
is
going
to
be
if
it's
like,
absolutely
horrible,
but
it's
like
off
in
a
dark
corner.
Nobody
will
ever
see
or
clone
it.
But
if
it's
like
this
one's
the
first
one
of
the
thing
and
everybody's
gonna
copy
this
one,
like
that's
going
to
be
that's
I
use
metastasize
like
a
cancer
metaphor,
but
contagious.
C
B
B
My
goal
is
like
no,
don't
don't
write
a
bug
so
bad
that
the
Infectious
Disease
researchers
write
a
paper
about
it.