►
Description
Incubation Engineering Enablement session where Stan Hu shares his secrets on Thriving as a GitLab engineer
A
A
I'll
give
you
a
quick
introduction.
I
worked
at
a
lot
of
other
startups
in
the
past
in
a
range
of
fields.
You
know
I
started
my
career,
doing
software
design,
radio
defined
radio.
I
should
say
before
anyone
really
knew
what
that
meant,
and
it
was
part
of
the
team
that
produced
one
of
the
the
first
fcc
certified
based
cellular
base
station
for
a
company
out
in
massachusetts.
A
I
didn't
really
have
a
lot
of
visibility
with
the
team
was
working
on.
I
would
have
to
refresh
gitlab
constantly
and
then
I
really
wanted
to
see
slack
notifications
and
about
like
when
somebody
checked
in
code
or
created
an
issue,
and
things
like
that,
and
I
looked
at
this
issue
on
gitlab.com
and
everybody
said
yes,
more
slack
notifications
plus
one
plus
one,
but
there
was
no.
There
was
no
activity
around
it,
and
so
you
know
eventually
I
got
tired
and
said:
well,
I'm
just
going
to
add
it.
A
I
don't
know
ruby
on
rails,
but
I
know
python
I
know
cc
plus.
I
think
I
can
figure
it
out.
So
I
spent
some
time
looking
at
the
code
base
and
kind
of
being
amazed
how
well
structured
and
well
and
understandable
it
was,
and
so
I
submitted
my
first
merge
request
shortly
after
that
around
november
2014,
and
then
I
waited,
I
didn't,
get
a
response
back.
A
I
think
sid
finally
saw
the
merging
quest
and
asked
dow
he
was
who
was
a
long
time
member
in
hitler,
not
at
the
time,
but
he
just
joined
to
review
the
merge
requests.
And
finally,
you
know
that's
really
what
started
me
on
my
passage
contributed
to
gitlab.
I
finally
got
feedback
from
dally.
We
went
back
and
forth.
I
really
enjoyed
the
process
I
got
it
merged
in.
A
I
was
really
excited,
and
so
I
kept
looking
for
other
things
to
do,
because
you
know
I
was
using
gitlab
day-to-day
and
I
really
wanted
to
make
it
better
for
myself,
and
so
I
was
using
their
their
bug
reports
to
kind
of
figure
out
what
I
should
work
on
next,
because
I
knew
it
was
going
to
benefit
me
and
also
it
was
always
going
to
help
the
wider
community.
So
eventually
it's
got
their
attention
because
I
was
submitting
so
many
emerging
quests.
I
was
invited
to
the
accord
team.
A
A
I
I
shot
an
email
to
sit
and
say:
hey,
you
know,
I'm
I'm
thinking
of
going
somewhere
else,
but
is
there
something
git
lab
has
available
and
then
we
started
talking
and
you
know
long
story
short.
In
short,
I
joined
as
the
the
vp
engineering
in
april
2016.,
so
the
company
was
about
70
people
when
I
joined
over
over
my
time.
It
grew
over
200
and
then
eric.
A
We
hired
eric
johnson
to
kind
of
scale
up
the
team
further,
and
I
switched
to
an
ic
role
and
created
this
engineering
fellow
role,
and
that
has
been
sort
of
where
I
am
now.
You
know
five
years
later
fast
forward,
I'm
still
in
this
role
and
I'm
loving
it.
So
that's
sort
of
a
brief
history.
Any
questions
about
that.
B
A
A
We
went
through
a
few
organization
changes
there,
updating
the
board.
You
know
I
would
spend
a
lot
of
time.
You
know
updating,
slides
for
the
board,
giving
them
updates
of
where
engineering
was
going
and
just
like,
I
wasn't
doing
a
lot
of
hands-on
work.
I
was
you
know.
Most
of
it
was,
you
know,
other
team
members,
but
you
know
we
were
doing
a
lot
of
we
were.
We
were
scrambling
at
the
time
to
get
like
to
scale
out
like
the
nfs
solution.
I
get.
A
Love
was
running
on
nfs
at
the
time,
and
so
we
had
a
lot
of
challenges
with
that
of
scaling
out
the
file
system,
and
things
like
that.
So
you
know
there's
questions
about,
you
know.
Do
we
use
the
cloud
or
we
do
our
own
roll,
our
own
bare
metal
and
was
for
a
while?
We
were
going
to
you
know,
spin
up
our
own
hardware,
because
we
were
going
to
run
this
distributed
file
system
that
required
that-
and
you
know,
spent
a
lot
of
time
talking
to
vendors
and
then
eventually
the
boards
convinced
us.
A
That
was
a
terrible
idea
and
retrospective.
They
were
right
because
you
get
a
lot
of
things
for
free
when
you
run
the
cloud
and
today
it
seems
like
yeah,
of
course,
but
at
the
time
you
know
we
were
really
we
weren't
sure
about
that,
because
I
mean
dropbox
and
other
companies
had
moved
away
from
amazon
for
a
number
of
reasons,
and
we
thought
we
were
in
the
same
boat.
A
So
I
was
spending
a
lot
of
my
time
kind
of
thinking
about
those
kind
of
problems,
and
you
know
still
dealing
with
like
the
releases
and
trying
to
get
leases
out
the
door.
So
it
was
kind
of
frenetic
in
that
sense
that
I
was
trying
to
do
a
lot
of
things
at
once
and
you
know
not
doing
a
great
job
at
all.
Any
particular
one
since
then
I've
been
much
more
technically
focused.
You
know
I
still
get
pulled
into
tough
customer
issues.
A
You
know
we
had
a
innocent
a
couple
of
years
ago
from
one
of
our
premier
customers
and
I
spent
a
lot
of
stressful
time
doing
that.
Dealing
with
that,
I
went
to
austin
for
another
customer
to
deal
with
some
of
their
challenges
and
every
now
and
then
I
get
pulled
into
something-
that's
really
high
priority
and
sort
of
works
on.
You
know
cross-functional
latest
stuff.
You
know,
for
example,
it's
like
fips
compliance
that
requires
talking
to
almost
every
team
at
gitlab
because
it
affects
everybody,
and
then
you
know
lately.
A
I
think
we've
got
we're
dealing
with
this
ssh
problem
where
ips
are
not
working
and
allow
listing
is
not
working
for
ssh
connections
and
so
that's
again
kind
of
a
cross-functional
initiative
between
infrastructure
and
source
code.
So
that's
what
I'm
working
on
today.
So
you
know
that
gives
you
a
brief
overview
that,
like
I'm
just
I'm
now,
I'm
much
happier
just
kind
of
focusing
on
a
lot
of
these
technical
things,
and
you
know
eric's
do
a
great
job
of
worrying
about
how
do
we
grow
our
company
from
200
to
1500
and
beyond.
B
A
B
Ones
down
the
list,
but
okay,
so
I
moved
from
sales
to
engineering
about
seven
eight
months
ago
and
I
felt
that
you
know
when
I
joined
a
remote
organization
in
the
sales
team,
there
was
a
lot
of
lubrication
in
the
machine
like
you
knew
there
were
methods
or
mechanisms
to
know
what
all
is
available
and
who
do
you
speak
to
on
the
engineering
side?
I
find
that
part
a
little
challenging
like
what
is
available
in
the
ecosystem,
that
we
call
our
engineering
team
and
how
do
you
navigate
through
that?
A
A
Part
of
it
also
is
just
like
you
know,
having
personal
connections
with
different
people
on
the
team.
You
know,
so
it
may
be
helpful
to
have
coffee
chats
with
certain.
You
know.
Just
take
a
sampling
people
support
people
in
you
know,
reliability,
people
on
the
back
end
and
just
kind
of
get
a
lay
of
the
land
of
like
what
people
are
working
on.
I
mean,
I
think
you
know
I
mean
having
been
here
for
a
while.
A
I
I
have
a
good
sense
of
what
all
the
different
teams
are
working
on,
but
that's
just
from
you
know
over
time
you
know
either
seeing
their
name
pop
up
or
looking
at
their
merge
requests,
or
you
know
just
having
dealt
with
incidents
in
the
past.
So
you
know,
I
think
it's
incubation's
interesting,
because
you're
you're
you're
a
new
team
and
you're
still
trying
to
understand
like
how
you
fit
in
with
the
rest
of
the
back-end
team
and
maybe
eduardo.
You
have
some
comments.
You've
been
here
for
a
while.
A
C
Yeah,
so
there
are
tracks
very
useful.
At
least
you
know
where
you
are
and
who
you
were
talking
to.
I
always
try
to
go
to
the
team
first
or
should
ask
anywhere.
Where
should
the
team
be
and
the
best
way
to
get
help
is
with
nmr?
If
you
get
an
mr,
it's
a
lot
easier
than
asking
for
help
in
chats
or
in
slack
channels,
because
then
people
are
like
it's
almost
like
a
review.
You
become
a
menace,
and
people
have
to
manage,
manage
the
madness
that
you
became
so
that
that
helps
out.
C
C
What
are
the
areas
that
you're
gonna
be
touching
not
now,
but
in
two
months
and
start
building
the
relationships
that
you
need
right
now
so
with
the
engineers
with
the
product
with
pms,
this
can
go
for
the
team.
This
can
go
with
the
stage
level,
and
so
on
so
forth
it
depends
a
lot
on
their
own
specific
group
or,
and
some
areas
are
a
lot
more
delicate
than
others,
so
that
there's
that
as
well.
B
A
One
thing:
industry,
let
me
think
well,
I'm
I
think
top
of
mind.
You
know
we
have
an
incident
early
on
in
the
gitlab,
where
somebody
accidentally
dropped
the
gitlab.com
database,
and
I
think
I
would
have
prioritized
the
backups
and
focus
on
the
backup
restore
a
lot
sooner,
because
that
was
a
you
know.
We
were
lucky
we
recovered
from
that,
but
it
was
just
by
dumb
luck
that
we
happen
to
have
like
a
backup
sitting
around
at
some
machine.
A
So
I
think
that's
one
thing
I
would
have
done
differently,
I
mean.
Obviously
there
are
a
lot
of
different
things
that
you
know.
I
wish
I
handled
better
in
the
past.
So,
for
example,
you
know
when
I
was
in
reporting
to
sid.
There
were
a
lot
of
different
things
related
to
just
you
know,
team
team
performance
and
things
like
that
and
how
I
handled
that-
and
you
know
you
know.
Obviously
you
can't
you
know
you
learn
from
those
lessons,
but
those
were
also
things
I
I
wish
I
had
done
a
little
better.
D
Okay-
okay,
I
just
I
just
you
know.
I
just
don't
want
to
steal
all
the
time,
because
I
have
a
few
things.
I
recently
tried
gitlab.
So
thanks
for
you
know
doing
a
session
for
us.
I
think
you
will
learn
a
lot
from
it.
One
thing
I
try
to
understand
is
like:
how
do
I
see
scrolls
grow
at
gitlab?
You
know
from
a
senior
engineer
stuff.
I
think
principle
is
the
next
step
and
I
really
had.
D
I
got
a
conversation
last
week
with
I
seen
a
staff
front
and
engineer,
and
I
was
kind
of
like
yeah.
It
seems
like
you're
doing
cross-organizational
work,
which,
in
my
previous
company
was
mostly
considered
a
you
know,
a
few
teams
as
a
staff
engineer.
But
probably
you
know
someone
who
is
like
working
across
organizations
with
like
we've,
been
bigger
across
bigger
organizations,
it's
kind
of
like
a
principal
engineer,
so
I
wanted
to
understand
like
what
your
thoughts
are
like.
What
is
a
principal
engineer?
What
is
the
difference
between
you
know?
A
Yeah,
that's
a
good
question
and
I
think
eric
has
done
a
good
job
of
kind
of
trying
to
lay
out
the
different
the
roles
and
you
know
we've
gotta.
We,
I
always
point
people
to
the
handbook,
because
there's
these
job
descriptions
and
they're,
you
know
eric-
has
done
a
great
job
of
thinking
through
all
the
different
things.
But
so
I
can
only
do
my
best.
I
summarize
kind
of
what
I
think
is
helpful
here
and
you
know
at
gitlab.
A
A
I
think
we
had
just
we
have
distinguished,
and
now
we
have
senior
distinguished
and
things
like
that,
so
it's
kind
of
in
flux
at
the
time
I
you
know
it's
also
challenging
for
me,
because
I
you
know
I
didn't
I
pivoted
from
you
know
one
role
to
another
and
I
didn't
kind
of
you
know
I
you
know
I'm
helping
people,
you
know
get
go
up
the
track
that
we
have
today,
but
I
don't
have
a
good
sense
of
having
gone
through
it.
My
take
take
my
advice
for
what
it's
worth.
A
I
do
think
it
is
like
the
idea
behind
this
to
these
different
levels.
Is
that
the
the
difficulty
of
the
issues
and
the
sort
of
the
breadth
of
the
the
issues
increase
as
you
kind
of
go
up,
you
know
so
people,
I
think
you're
kind
of
expected
to
to
be
able
to
jump
into
almost
any
problem
that
sometimes
because
I
get
pulled
into
all
sorts
of
crazy
stuff
that
I
haven't
looked
at
before,
and
I
I
for
people
in
support
and
other
engineering
file
engineering.
It's
like
well,
I'm
just
the
person
to
ask.
A
A
You
know
whether
it's
a
scale
build
issue
in
in
giddily
or
some
problem
with
a
customer
just
be
able
to
jump
into
it
without
kind
of
hesitation.
I
think,
is
sort
of
what
I've
found
that
valuable.
You
know
also
be
able
to
to
look
at
an
instant
and
figure
out
like
the
10
things.
We
need
to
do
and
kind
of
help
teams
figure
out
like
what
is
the
priority
of
things.
A
So
you
know
one
thing
I
found
instructed
with
the
fip
stuff:
is
that,
like
a
lot
of
people
just
don't
know
what
it
means
to
be
fixed
compliant?
I
didn't
know
what
physical
line
was
and
I
spent
the
last
three
months
understanding
what
it
was
and
be
able
to
go
through
the
issues
and
say
no.
You
don't
have
to
worry
about
that.
Yes,
you
have
to
worry
about
that
and
just
kind
of
help
prioritize
like
what's
really
important
and
what's
just
can
be
kind
of
table
for
later
in
kind
of
a
cross-functional
way
right.
A
A
A
D
A
A
Like
that
that
handbook
page,
hopefully,
if
it's
not
clear,
then
it's
a
merger
question
right
like
if
you
find
something
in
that
that
thing,
that's
not
clear.
It's
submitted
to
hurricane,
you
can
get
it
fixed
and
tweaked
the
way
you
wanted
to
so
in
some
ways
it's
like
you
can
help
to
shape
the
role,
which
is
what
I
love.
What
I
love
about,
get
love
it's
not,
but
this
is
not
a
static
thing.
It's
not
from
above
that
says.
A
C
Yeah,
my
follow-up
is
that
incubation
engineer
is
a
very
specific
thing
right.
It's
it's
just
different,
like
a
lot
of
expectations
are
already
like
built
in
because
we
work
horizontally.
We
are
very
like
very
dynamically.
We
start
something
today
and
next
week
we
might
change
to
something
completely
different.
C
Perhaps
we
do
the
tracking
across
the
teams,
with
the
relationships
we
already
our
eyes
by
the
foe
on
everything
we
do
how
and
this
at
least
from
the
description,
whether
they
are
big
into
the
principal
world
and
not
on
the
on
the
staff
from
how
would
you
see
a
principal
incubation
engineer?
I
was
just
like
okay.
This
guy
should
be
a
perspective
engineer.
A
It
is
a
little
bit,
I
think,
but
you
know
I
could
see
you
know.
I
could
just
give
like
just
examples
off
the
top
of
my
head
right,
like
machine
learning,
obviously,
is
going
to
be
a
big
part
of
the
future
of
software
development
right
and
we
need
to
figure
that
out
at
gitlab
right
and
that's
part
of
what
community
creation
engineering
is
hoping
to
kind
of
structure
right.
A
But
how
does
that?
Actually?
What
does
that
actually
mean
for
gitlab
right?
So
I
could
see
you
know
someone
who's,
really
successful,
gitlab
say:
look.
We
need
to
be
able
to
support
x,
y
and
z
to
really
be
serious
about
machine
learning.
You
know
as
a
fundamental
feature
at
gitlab
right
just
at
least
define
those
goals,
and
like
say
this
is
how
we're
going
to
get
there.
This
is
what
we
need
to
do
today.
These
are
the
incremental
steps
and
this
is
sort
of
the
long
term.
A
It
helps
shape
that
with
product
right,
because,
right
now
I
think
the
challenge
is
like
we
all
know
it
needs
to
happen,
but
what
does
it
actually
mean
like?
What
are
the
features?
What
is
the
functionality?
What
is
it?
What
is
it?
That's
going
to
really
deliver
value
and
make
people
want
to
use
gitlab
for
this
project,
and
you
know
I'll
give
a
good
example.
You
know
camille
when
he
started
at
gitlab.
A
You
know
ci
was
a
separate
thing.
I
think
this
is
a
class
example
and
the
runner
was
its
own
thing
and
and
camille
proposed
hey.
We
should
really
make
it
ci
integra
tightly
integrated
with
gitlab
right,
don't
separate
the
auth
make
it
like
part
of
the
view
and
that
at
the
time
was
not
it
was,
was
counter-intuitive.
A
You
know
at
the
time
you
know
everyone's
first
reaction
was
like
that's
a
terrible
idea,
like
they're
different
services.
You
know
you
got
to
shoot
them
separately,
but
then
I
think,
the
more
and
more
you
know
we
made
the
case
for
it.
Camille
made
the
case
for
it
the
stronger
the
case
was,
and
eventually
I
think
it's
getting
8.0
9.0.
We
decided
to
merge
it
and
make
it
ci
kind
of
an
integral
thing.
It
wasn't
its
own
separate
data
service.
A
It
was
it
lived
and
breathed
within
gitlab,
and
so
I
think
the
same
with
machine
learning
is
like
what
do
we
need
to
do
to
make
machine
learning
an
integral
part
of
gitlab,
and
so
I
could
see
engineering
in
computing
engineering's
roles
like
okay.
This
is
what
we
really
need
to
do
right,
like
the
models,
the
data.
A
You
know
right
now,
the
stuff
that
we
have
is
kind
of
can
kind
of
support
it,
but
not
really
like.
We
really
need
to
think
about
it
in
this
way,
and
so
I
think
one
of
the
most
powerful
things
you
can
do
is
just
like
this
is
like
this
is
what
we
want
to
do.
This
is
how
we're
going
to
make
a
machine
learning
an
integral
feature.
I
think
that
could
be
really
powerful,
so
it.
C
A
Be
measured
in
that
kind
of
form
like
something
really
visible
that
people
can
really
say
yeah
this.
This
made
your
your
life
better
and
made
everybody
who's
doing
data
analysis
better
right,
so
I
can
see
that
being
kind
of
one
example.
It's
not
the
only
example
but
like
I
can
see
it
as
a
classic
example
of
like
using
the
the
you
know,
past
history
as
an
as
a
sort
of
a
template
and.
B
A
B
A
D
D
What
do
you
think
are
the
biggest
technical
challenges
for
git
live
in
the
next
few
years,
like
where
it's
going
to
fall
apart?
If
we
don't
do
something
like
investing
in
foundations
that
are
not
going
to
like,
I
was
talking
to
a
few
people
like
I
started
four
weeks
ago
with
what
was
talking
to
a
few
people
and
databases
always
came
up
as
a
thing.
C
D
Vertical
sharding,
I
think,
has
been
established
by
now,
but
what
if
we
actually
have
to
go
towards
a
horizontal
sharding
solution?
How
does
that
affect
the
open
source
product
versus
the
software
as
a
service
product,
because
it's
kind
of
like
tricky
to
introduce
additional
infrastructure?
I
assume
like
kafka,
for
example,
or
doing
change
data
capture
internally,
but
not
in
the
open
source
project
like
those
are
just
like
rough
ideas
that
came
to
mind,
but
I
wonder
what
your
thoughts
are,
and
you
know
what
I
don't
know
yet.
D
A
So
I
think
it's
going
to
be
scaling
out
the
database,
whether
it's
horizontal
starting
to
mention.
I
think
the
current
thinking
is
using
some
pod
architecture
where
you
could
have
customers,
you
know
and
will
share
a
pod,
but
like
they
have
their
own
dedicated
resources.
For
that
it's
like
reducing
that
blast
radius.
Right,
like
it's
about
isolation,
right
right
now,
I
think
the
problem
is
like
one
customer
can
affect
everybody
else
and
we
need
better
isolation
right.
A
If
something
goes
down,
we
should
be
able
to
function,
and
then
performance
obviously
is
kind
of
time
to
intertwine.
With
that,
obviously
you
can't
you
can
get
better
performance
just
by
having
smaller
instances
and
things
like
that,
but
there
is
still
a
lot
of
work
to
be
done
to
optimize
what
you
have,
and
so
I
think
we
need
to
do
a
better
job
of
you
know
that,
and
also
just
you
know,
continue
to
improve
the
stability
and
the
and
the
fleshing
out
a
lot
of
our
features
right.
A
A
lot
of
features
are
not
completely
baked
if
you
will
and
they
need
to
be
refined
and
improved.
So
we
have
a
lot
of
challenges
in
those
respects
and,
at
the
same
time,
we're
trying
to
expand
the
scope
of
gitlab
too
right.
This
whole
initiative
of
of
you
know,
bringing
ml
and
new
new
ideas
to
get
lab
is
like
a
whole,
another
area,
and
I
think
that's
why
we're
trying
to
invest
in
this.
A
D
A
Yeah,
if
you
have
thoughts
on
how
we
should
best
pod,
you
know
we
would
love
to,
because
I
know
we're
having
a
lot
of
we've
been
having
a
lot
of
discussion
over
the
last
six
months.
What
does
it
mean
to
the
pod
thing?
We
looked
at
shopify.
We
said
okay,
that
works
for
them,
but
it
doesn't
work
for
us
because
of
x,
y
and
z,
dependency.
A
D
Yeah,
the
biggest
problem
we
had
were
like
rebalancing
parts,
obviously
like
you,
need
to
move
shops
in
during
production
and
in
real
time,
and
you
know,
there's
a
system
that
should
be
that
has
like
a
dla
plus
proof,
but
in
reality
it
can
still
fail,
and
those
are
the
issues
and
I
think,
a
part
of
the
problems
that
we
have
like
before
I
moved.
I
was
working
in
data
engineering
and
we
recently
got
like
change
data
capture
as
as
a
thing,
and
it
was,
I
think,
it's
really
powerful.
A
Yeah,
we
may
need
something
like
that.
I
don't
know,
we've
thought
about
it
too
much.
You
know
we,
we
definitely
are
trying
to
add
an
analytical
store,
so
click
houses
are
the
next
thing
that
we're
trying
to
add-
and
so
I
think
that
could
complement
a
lot
of
stuff
we're
doing
in
postgres
right
now,
because
we're
doing
a
lot
of
analytic
queries
and
postgres,
which
is
kind
of
an
awful
thing
from
a
data
science
perspective,
because
you
can't
do
these
very
well
and
it
requires
yeah,
it's
just
the
wrong
tool
for
the
job.
D
Yeah
I
had
one
I
had
one
more
question
about
like
biggest
challenges,
because
one
wasn't
technical
but
organizational.
So
another
theme
that
I
that
always
that
comes
up
in
like
a
couple
of
conversations
I
had
was
product
priorities
versus
building
the
platform
and
is
do
you
think
of
like
your
role
or
the
roles
of
other
senior
engineers
at
gitlab,
that
they
should
be
the
advocates
for
like
reducing
the
technical
depth,
making
things
like
sustainable
for
the
long
term
and
those
kind
of
things.
A
Absolutely
right,
because
you
know,
and
since
you
work
on
the
code
day-to-day,
you
have
the
best
perspective
and
most
reason
to
get
this.
You
know
fix
this
stuff.
I
think
it's
absolutely
important,
especially
if
it
impedes
some
development
or
feature
or
product
right
to
give
a
good
example.
Our
object,
storage
implementation
is
not
really
ideal
at
gitlab
and
you
know
there's
a
working
group
to
address
it,
but
it's
been
a
long
time.
Technical
debt
and
it's
kind
of
hurting
us
right
now.
A
So
I
you
know,
obviously
it's
it
leads
into
like
availability
problems
and
scalability
problems
for
customers
and
things
just
time
out
when
they
shouldn't
time
out.
So
I
mean
those
should
be
product
concerns,
obviously,
and
then,
and
especially
those
things
that
impact
just
the
overall
experience
of
gitlab.
I
think
that
needs
to
be
a
priority.
So
I
think
if
you.
C
A
Can
definitely
get
buy-in
if
that
technical
debt
address
is
like
some
customer
visible
problem.
Obviously,
there's
stuff,
that's
not
necessarily
customizable,
but
could
be
eventually
so
anytime.
You
can
come
up
with
a
kind
of
a
strong
case
of
like
this
will
help
us
do
x.
Then
it
makes
it
easier
to
prioritize,
but
I
do
think
absolutely
that,
like
anyway,
at
gitlab
should
be
able
to
say
yeah,
we
really
need
to
get
this
fixed
like
this.
A
B
A
C
One
question
that
always
makes
I
always
make
users
and
people
talk
to
is
what
is
the
one
feature
that
you
want
to
want
to
add
trigger?
For
me,
it
was
jupiter
notebook
this.
It
was
the
one
thing
that
I
knew
I
had
to
implement
on
gitlab
and
that's
what
I
told
sid
on
the
on
on
my
interview,
like
yeah
free
from
join
the
first
thing
I'm
gonna
do
is
gonna,
be
that
and
what's
that
for
you
what's
the
one
thing
you
wanna
like,
you
really
need
to.
A
A
Felt
like
that,
like
a
year
ago
or
two
years
ago,
like
we,
you
know,
I
think
github
had
the
future
to
paste
spreadsheets
into
markdown,
and
I
was
you
know
at
the
time
early
in
my
role.
I
was
copying
spreadsheets
all
the
time,
and
so
I
really
wanted
that
and
I
added
that
about
a
year
and
a
half
ago.
I
think
I
added-
and
I
think
the
second
thing
I
added
about
a
year
ago
was
the
slash
rebase.
So
everybody
you
know,
did
a
rebate
of
merch
quests
before
you
would
have
to
like.
A
E
Yeah,
so
I
was
trying
to
think
about
how
to
phrase
this
so
I'll
kind
of
talk
through
what
I've
written.
But
you
know
the
the
org
structure
of
incubation
engineering
is
different
intentionally
from
the
rest
of
development,
and
I
think
that
provides
us
opportunities
to
do
things
a
little
differently
or
just
approach
problems
differently
or
whatever.
E
A
Yeah,
I
mean
that's
a
good
question.
I
I
think
I
I
come
from
the
perspective
I
think,
whatever
before
this
group
was
founded
like
I
took,
I
spent
a
little
my
time
on
ml
and
trying
you
know,
because
I
know
that
was
high
on
sid's
radar
and
I
think
the
one
thing
I
struggled
with
is
how
defining
how
we
make
ml
friendlier
for
for
users.
Gitlab
has
a
very
like
opinionated
view
of
how
you
know
artifacts
and
things
get
managed,
but
I
would
love
to
know
like
you
know.
A
What
are
we
missing
from
that
like?
What
do
we
need
to
be
doing
better?
In
that
sense,
and
just
managing
you
know,
repeatability
of
ml,
managing
the
you
know
like
the
ml
training,
the
all
those
things
so
like
what
are
the
things
that
we
should
be
doing
and
defining
kind
of
like
you
know
how
to
and
kind
of
meshing
that
with
gitlab
like
right
now
we
do
things
where
we
try
to
fit
things
in
the
wrong.
Those
that's
you
know
like
a
square
peg
in
a
round
hole
like
I.
A
If
you
look
at
one
of
my
tanooki
stand,
which
trains
like
our
issues,
I'm
using
sierra
artifacts
to
store
the
outputs
of
the
machine
learning
but
like
it
doesn't
feel
like
it's
like
the
right
thing
and
like
getting
that
back
into
source
control,
it's
kind
of
cumbersome,
like
I'm,
checking
in
as
an
lfs
file,
which
doesn't
really
feel
like
the
right
thing
either.
So
you
know
I
would
love
like
for
incubation
engineering
is
like
hey.
A
This
is
the
kind
of
new
paradigm
we
think
you
know
we
should
take
with
git
lab
and
how
do
we
integrate
it
with
the
existing
models?
How
do
we
take
advantage
of,
like
you
know,
click
house
or
whatever?
You
know,
just
all
the
stuff
that
we're
working
on
today
and
how
does
that
fit
in
the
picture?
So
I
would
love
to
incubation
engineering
to
be
able
to
define
like
what
is
it
that
we
need
to
introduce
to
gitlab
to
make
it
powerful
for
you
to
do
your
jobs.
A
But
I
don't
I
mean
that's
my
nearest
person,
I'm
not
sure
what
you're
all
working
on
but
like
from
just
the
ml
side
of
things.
I
can
see
that
as
being
like
that
could
be
game.
Changing
freaking
lab
is
just
having
a
better
workflow,
because
I
know
there's
certain
companies
that
are,
you
know
doing
stuff
specific
for
ml,
but
I'd
love
to
know
like
what
can
we
learn
from
that
and
what?
What
should
we
introduce
to
gitlab
to
make
it?
You
know
closer
to
those
kind
of
solutions.
E
Yeah
this
that's
really
interesting.
I
think
I've
I've
seen
a
lot
of
what
you're
describing
where
well
we
have
these
things
that
we
can
build
on
top
of,
and
it's
not
quite
right,
but
it'll
it'll
get
us
there.
We
can
kind
of
ship
the
feature
and
and
then
kind
of
move
on,
even
though
it's
you
know,
maybe
not
everything
that
it
should
be
or
or
it's
it's
a
bit
of
a
hack
to
get
it
to
work.
E
So
yeah
that
I
don't
know,
I'm
I'm
aligning
your
answer
with
the
thing
that
I've
been
working
on,
which
is
which
is
a
better
like
handler
for
using
files,
is
like
ci
variables,
the
the
current
like
file
file,
way
of
doing
that
is
just
to
hack,
on
top
of
you
know,
like
text
strings
and
and
like
changing
that,
I
think,
can
open
up
a
lot
of
a
lot
of
other
opportunities
for
for,
like
it's
like
introducing
a
new
primitive
into
the
system.
That
thanks.
A
I
you
know,
I
find
things
I
really
enjoy
working
on
right
and
so
or
stuff
that
I
you
know
I
I
I
think
my
activity
is
kind
of
combination
of
merge
requests
and
just
commenting
on
issues.
So
we
get
you
know
so
a
lot
of
times.
You
know
some
of
the
weekend
work.
I
just
do
stuff
like
you
know.
Well,
I
really
would
like
to
update
that
thing.
A
In
a
while,
I
like
to
pop
in
the
issue
tracker
and
just
see
what
people
are
saying
and
try
to
be
useful,
but
I
think
the
short
answer
is
that
I
really
enjoy
what
I
doing
so,
I'm
you
know
there's
always
like
10
things
I
want
to
do
like.
Oh,
I
really
need
to
comment
that
respond
to
that
or
I
need
to
review
this
merch
request,
and
so
you
know
I
just
feel
like
I've
got
a
lot
of
balls
up
in
the
air,
and
so
this
graph
is
just
reflective
of
me
being
almost
adhd.
B
Lovely
lovely,
I
think
adhd
is
you
know
it's
home
for
all
of
us,
so
we
we
get
what
you're
saying
that's
we've
gone
through
all
the
questions
last
five
seconds.
If
anybody
has
something
else
to
add,
if
not,
we
can
end
this
a
bit
early
and
give
you
20
minutes
of
your
time
back
all
right.
Thank
you.
Everybody
thanks
thanks!
So
much
stan.