►
From YouTube: The HashiCorp Formula to Open Source - CodeConf 2016
Description
Presented by Mitchell Hashimoto
HashiCorp has built and released eight different large open source tools over the past 4 years. These tools receive millions of downloads per month, all while spanning three separate user types: developers, operators, and security.
I am often asked what the process is like from start to ship: how did we come up with an idea? how did we design our solution? why did we choose to do something the way we did? how do we maintain eight projects at scale? and so on. This talk presents the process we go through at HashiCorp when designing a new project. This process doesn't require a lot of money or a group of people: I built Vagrant in my dorm room in college! I'll cover idea discovery, technical decisions, user experience design, and more.
About CodeConf
CodeConf improves the software community by providing a forum for thought-provoking talks and forging social connections. The fourth installment of the CodeConf series took place in Hollywood in 2016. This year's event focused on systems engineering projects, practices, and programs in the open source community.
For more information on this year's CodeConf, go to:
https://codeconf.com/
A
A
A
It
and
and
I
very
confidently
can
say
that
I
wouldn't
be
where
I
am
without
open
source
and
I
don't
mean
that
in
the
way
that
I
started
a
company
based
on
open
source
or
anything
I
mean
it
a
lot
earlier
and
that
I
probably
wouldn't
even
be
the
programmer
or
maybe
wouldn't
have
even
programmed
if
I
hadn't
found
open
source.
So
I
taught
myself
programming
when
I
was
12
and
the
way
I
taught
myself.
Programming
was
I
actually
printed
out
the
intro
section
to
the
PHP
manual.
A
It
was
like
30
pages
on
on
dead
trees
and
everyday
walking
to
middle
school.
For
about
I,
don't
know
three
months.
I
would
just
read
it
over
the
same
same
30
pages
I
just
kept
reading,
because
I
didn't
understand
anything.
But
after
about
three
months,
I
started
understanding
at
a
very
basic
level.
You
know
what
a
variable
is,
what
a
conditional
is,
what
a
loop
is,
but
even
after
three
months,
I
was
really
really
struggling
to
tie
these
pieces
together
to
make
something
to
actually
do
something
with
it.
A
A
I
would
just
study
the
source
code
and
take
parts
of
it
and
put
it
in
my
own
programs
and
see
what
happened,
and
it
was
a
huge
huge
learning
experience
and
in
that
one
or
two
week
period
of
reading
the
source
code.
I
came
so
much
farther
than
the
three
months
of
reading
the
PHP
manual
every
day
and
and
that
really
began
my
journey
for
open-source.
A
So
as
I
was
growing
up
as
I
got
a
little
bit
older,
you
know,
kids,
any
age
have
idols,
have
like
what
you
would
when
I
would
quote,
unquote,
call
a
rock
star
and
for
a
lot
of
kids,
you
know
they're
professional
athletes,
celebrities
musicians
pick
something
and
maybe
even
their
family.
For
me,
it's
really
sad,
but
my
idols
were
really
open.
Source
people
and
I
put
three
of
them
up
here.
A
The
list
constantly
changed
and
was
bigger,
but
these
are
very
identifiable
people
and
if
you
don't
know
from
left
to
right,
it's
Yehuda,
Katz,
John,
Resig
and
David
Heine
Meyer
Hansen,
and
they
created
these
things
or
worked
on
these
things
and
I
really
looked
up
to
these
people.
I
liked
I
watched
every
single
talk.
I
could
get
my
hands
on
that.
Any
of
them
ever
gave
I
read
every
single
blog
post,
I
read
their
code.
A
A
So
I
just
remember,
being
really
struck
by
the
fact
that
this
person
and
we're
about
the
same
age
I
think
or
he
might
be
a
little
older,
a
little
younger
but
I
just
remember
thinking
that
this
person
created
something
as
successful
as
jQuery
3
years
ahead
of
when
I
even
found
out
about
him
and
I
was
doing
nothing
really
at
the
time
and
and
instead
of
being
like.
You
know
this
really
motivated
me.
It
showed
me
that
it
was
possible.
A
It
was
something
that
I
didn't
even
think
was
possible
and
it
showed
me
it
was
possible
and
really
inspired
me
to
do
more.
You
who
to
cast
was
just
prolific.
He
works.
He
seems
to
work
on
all
the
right
things
at
the
right
time
and
David
Henry
Maier
Hansen
is
is
unique,
but
what's
what's
really
interesting
about
him
to
me
is
he's
also
a
very
successful
entrepreneur.
A
So
all
these
people
were
were
sort
of
my
version
of
what
I
looked
up
to
and
what
I
really
wanted
to
be
so
around
2006
I
started
doing
open
source
software
so
about
four
years
into
programming.
By
some
definition,
I
started
contributing
to
open
source
projects.
Finding
projects
I
could
work
on
actually
how
I
got
into
it
was
building
mods
for
open
source
software
for
forum
software,
actually,
which
is
kind
of
weird,
but
this
in
2006
when
I
started
doing
it
and
and
about
seven
years
later
this
thing
came
out
in
2013.
A
You
could
look
up
the
definition,
how
they
measured
it,
but
in
2013
I
ended
up
being
number
eight
on
the
most
active
github
users
list
and
it's
a
vanity
superficial
thing.
But
it's
still
I
was
really
proud
and
happy
to
see
this
because
it
showed
the
progress
I
had
made
in
sort
of
the
seven
years
since
I
started,
trying
to
do
open
source
and
in
the
about
eleven
years
since
I
even
found
what
open
source
software
is,
and
shortly
after
that
I
found
at
hotshoe,
Corp
and
haja
core
also
really
loves
open
source
software.
A
A
This
is
one
of
the
talks
that
I
wish
the
content
sort
of
existed
when
when
I
was
starting,
something
to
at
least
give
me
a
framework
to
work
around
and
I
hope
that
it
could
kind
of
guide
you
in
that
direction
too.
If
you
want
to
get
involved
in
open
source
to
try
to
start
working
on
open
source
so
really
quickly
before
we
dive
into
the
formula,
I
want
to
go
back
to
2007
in
2007,
I
worked
for
Apple
and
I
was
a
freshman
in
college,
so
this
is
an
apple
incorporated.
A
And
I
worked
in
a
store.
A
lot
like
this
I
walked
around
the
floor.
A
lot
like
this
and
my
job
at
Apple,
my
title
was
Mac
specialist,
which
basically
meant
I
was
a
Mac
salesperson,
dinner
and
commissions.
But
I
was
a
Mac
sales
person
and
there
was
an
iPod
specialist.
There
was
iPhone
specialist
of
a
Mac
specialist
and
and
I
would
walk
the
floor
and
to
this
day,
I
consider
the
one
year
I
worked
at
Apple
retail
to
be
some
of
the
most
formative
teachings.
A
I've
ever
received
that
really
molded
in
a
profound
way
how
I,
build
and
design
software
and
work
with
software
communities
and
I
could
probably
talk
for
an
hour
about
the
various
stories
and
things
I've
learned
at
Apple
Store,
but
I
need
to
boil
it
down
a
lot
quicker.
So
we
can
move
on.
One
of
the
lessons
I
learned
is
that
look-and-feel
matters
as
an
engineer.
A
It's
easy
to
put
the
technology
or
the
implementation
on
a
pedestal,
and
what
Apple
really
taught
me
is
that
the
implementation,
the
guts
that
need
to
work.
But
nobody
cares.
People
want
things
to
work
and
they
want
things
to
look
nice
and
feel
nice
when
they
work.
They
don't
care
how
the
gears
are.
Turning
on
the
inside
another
part
of
look
and
feel
matters
is
in
this
store,
so
I
had
to
help
sell
computers
and
when
I
wasn't
helping
a
customer
sell
computers.
A
Another
rule,
I
remember,
for
example,
is
that
the
the
magic
mouse
on
an
iMac
keyboard
must
be
a
hands
distance
away
from
the
keyboard,
not
more
not
less,
and
these
are
funny
rules,
but
you
would
get
yelled
of
them.
Every
one
of
the
Apple
saw
has
a
radio
and
it
was
really
not
not
abnormal
to
hear
a
manager
or
even
another
employee
call
on
the
phone
and
say
like
hey
the
iPhones
are
out
of
alignment.
A
You
need
to
fix
the
iPhones
your
next
time
around
and
and
so
apples
are
really
funny,
because
they're
chaotic
and
their
constant
source
of
entropy
and
anti
entropy
happening
in
real
time
so
go
to
an
Apple
store
at
an
any
given
moment.
Something
will
be
out
of
out
of
alignment,
but
if
you
look
about
30
seconds
later,
it's
very
likely
it's
going
to
be
fixed
and
you
wouldn't
have
seen
it
happen.
You
actually
get
really
good
at
doing
it
without
people
even
noticing.
A
So,
for
example,
I
would
be
helping
to
sell
a
computer
I'd
be
talking
to
someone
then
go
okay,
let's
go
look
at
the
laptops
and
they
would
turn
to
go.
Look
at
the
printer,
so
they
turn
to
go.
Look
at
the
printers
and
I
would
follow
them,
but
before
I'd
follow
them,
I
quickly
fix
two
and
then
go
follow
them.
So
you
get
really
good
at
this
and
what
it
taught
me
was
that
these
little
details
they
do.
A
A
They
just
taught
you
how
to
treat
people
that
walked
into
the
store,
because
you
see
all
sorts
of
different
people,
and
these
are
high
school
and
college
kids
in
here,
and
it's
an
awesome
thing
to
teach
these
kids,
and
one
thing
they
taught,
though,
is
that
most
people
are
generally
kind.
They
want
to
be
nice.
Most
people
want
to
be
nice,
and
this
is
important
on
the
internet,
because
there's
a
lot
of
mean
people
on
the
internet.
A
But
the
thing
to
remember
is
that
most
people
want
to
be
nice
and
then
the
other
thing
Apple
always
said
was:
if
someone's
not
nice,
they
usually
have
a
reason.
They
feel
emotional.
For
a
reason,
that's
not
nice
and
you
would
also
feel
uncomfortable
if
you
had
that
reason.
There's
very
few
people
that
just
want
to
be
mean
they
exist,
but
there's
very
whew.
A
We
experience
more
people
that
you
would
describe
as
toxic
and
and
it
gets
you
down,
and
one
thing
that
we
always
try
to
tell
our
employees
or
even
committers
is.
Is
they
there's
some
mean
people,
but
most
people
are
actually
nice,
just
be
nice
to
them
in
return,
show
them
you
actually
care
and
they'll
turn
around,
eventually,
usually,
and
and
ultimately,
if
they
don't
don't
like
get
someone
else
to
help,
you
out
hand
it
off
to
someone
else
and
that's
something
we
did
an
Apple
as
well.
A
It
was
if
you
feel
like
you're
going
to
suddenly,
if
you
feel
like
you're
approaching
the
edge
where
you
can't
be
nice
to
somebody,
even
if
they're
being
mean
to
you,
you
needed
to
hand
it
off
to
another
employee.
You
liked
you
weren't
allowed
to
talk
to
that
person
anymore,
the
customer's,
always
right
so
okay.
So
these
were
some
lessons.
A
I
learned
and
like
I
said,
I
could
probably
talk
a
lot
about
Apple
I
blogged
a
lot
about
Apple,
but
let's
dive
into
the
sort
of
the
formula
of
open
source
and,
like
I
said,
the
formula
has
changed
over
the
past
six
plus
years.
I
haven't
always
broke
it
down
this
way,
but
I
built
this
given
the
the
history
of
our
last
eight
projects,
so
here's
the
six
step
thing
that
I
broke
it
down
to
and
we're
going
to
go
over
each
one
so
step.
A
One
is
obviously
to
find
a
problem
that
you
want
to
solve
so
find
something
you
want
to
build,
a
solution
for
and
I'm
an
engineer
and
as
an
engineer,
the
thing
I
would
always
want
to
do
is
work
on
whatever
is
fun,
and
you
should
definitely
and
it
there's
no
problem
working
on
whatever
is
fun,
but
it
matters
what
your
goals
are.
If
your
goals
are
just
to
learn
something
and
have
fun,
then
work
on
working
on
whatever
it's
fun
is
totally
fine
and
there's
zero
problems
with
that.
A
You
feel
like
you.
Could
the
time
spent
is
unnecessary,
something
that
costs
more
money
than
it?
Should
you
think
that
you
could
you
can
make
something
cheaper
or
something?
That's
error-prone,
so
something
that
you
feel
that
software
could
actually
drastically
lower
the
error
rate
on,
and
ideally
you
want
to
find
something.
That's
more
than
more
than
one
of
these
things.
A
A
It
might
not
be
worth
trying
to
solve
it,
but
if
it's
something
that
is
super
frustrating-
and
you
think
is
you
know,
causing
you
to
make
a
bunch
of
mistakes
causing
you
to
work
longer
than
you
want
to
just
isn't
fun
than
you
think
you
could
solve
it
in
a
more
fun
way.
Then
it's
probably
worth
solving,
but
it's
really
hard
to
solve
a
problem
that
you
that
doesn't
affect
you.
A
The
next
thing
I
do
is
ask
these
three
questions.
These
are
fairly
uncomfortable
questions
because
you
really
want
specific
answers
out
of
these,
but
you
rarely
get
those
answers.
So
once
you
find
a
problem,
the
at
least
my
what
I
want
to
do
right
away
is
just
go
solve
it
go
do
it,
but
it's
really
important
to
ask
these
questions
to
learn
about
the
environment
first,
so
who
else
is
trying
to
fix
this?
If
there's
almost
certainly
going
to
be
someone,
that's
try
to
fix
it.
A
A
Is
it
worth
building
this
one
open
source
project
at
the
risk
that
we
introduce
a
horrible
vulnerability
and
our
reputation
for
vagrant,
Packer,
console
terraform
and
any
future
thing
we
do
is
just
gone
actually
Arman
and
I
our
mom's,
my
co-founder
Arman
and
I
talked
about,
should,
should
we
or
should
we
not
build
vaults
on
these
merits
for
probably
three
months
before
we
ever
move
to
step
two
of
this
process?
We
did
other
things
in
the
meantime,
but
we
always
came
back
to
do.
We
really
want
to
risk
it
eventually.
A
You
want
to
be
significantly
better
in
some
way
than
the
previous
thing,
so
they'll
move
to
the
new
thing
and
the
project
overall
doesn't
have
to
be
better.
So
an
example
I'll
give
here
is
with
terraform
and
and
I
should
mention
it's
part
of
the
the
process.
We
actually
have
a
section
where
we
do
this
on
paper.
We
actually
the
section
where
we
write
why
our
idea
is
ten
times
better
or
what
part
of
idea
is
10
times
better.
We
believe
so
for
terraform.
We'll
give
you
an
example.
A
A
The
ops
and
dev
sort
of
managers
talked
for
a
little
bit
and
then
said
done
we're
going
to
use
where
we're
getting
rid
of
CloudFormation
reasoning,
terraform
starting
right
now.
Because
of
that.
So
let's
ask
questions
about
like:
let's
stop
the
demo
and
start
asking
deeper
questions
about
terraform
and
and
that's
what
you
want.
You
really
want
something.
A
That's
so
much
better
that
you
show
somebody
something
and
because
of
that
one
thing
it
invalidates
everything
they've
previously
done
and
they
need
to
move
to
the
new
thing
and
so
2x,
better,
not
good
enough
and
so
on.
So
you
really
want
to
aim
for
something
like
this
okay,
so
we
have
a
problem.
We
know
the
idea.
We
know
how
we're
going
to.
A
We
know
why
we
believe
our
ideas
better
and
so
step
to
starting
to
design
a
solution
and
and
a
lot
of
people
at
this
point-
will
reach
and
start
trying
to
write
code
and
and
very
painfully
you
you
can't
write
code
yet
or
I,
don't
believe
you
should
write
code
yet
you
instead
want
to
write
a
lot
of
human
language
so
for
terraform,
for
example,
we
we
do
it
as
this
on
google
box,
for
this
was
terraformed
actual
initial
design.
This
never
became
terraformed.
A
None
of
this
that
is
written
here
ever
became
terraform
but
and
and
that'll
become
important,
but
this
is
terraformed
initial
design
and
you
can
see
by
the
scroll
bar
that
it's
a
fairly
lengthy
document,
not
a
tome
by
any
means
but
fairly
lengthy,
and
we
cover
a
bunch
of
things
and
and
basically
watch
what
you
want
to
cover
in.
This
is
the.
A
This
is
a
section
cover
in
the
front
end
and
there's
a
section
car
in
the
back
end
and
the
way
we
define
that
is
the
back
end
is
any
internals
of
the
thing.
It's
it's
how
the
thing
works
internally,
it's
the
technical
details.
It's
the
computer
science
II
stuff,
that's
inside
there
and
what
you
want
to
aim
for
for
the
internals
is
build
something
that
designs
for
the
future
and
gives
you
a
technical
edge.
What
a
huge
huge
benefit
and
a
huge
huge
detriment
of
starting
any
new
project
is
that
you
have
a
clean
slate.
A
So
the
huge
benefit
is
that
you
have
the
ability
to
learn
from
other
people's
mistakes
and
do
it
a
lot
better
and
the
detriment
is
that
they
have
code
in
the
user
base
as
a
head
start
to
catch
up
with
you.
So
it's
sort
of
a
race
and
a
challenge,
an
engineering
challenge
of
whether
you
could
build
something
better
before
they
can
and
and
so
with
the
backend
design.
You
really
want
to
think
I.
Don't
have
backwards,
compatibility
issues
right
now,
I,
don't
have
any
assumptions
right
now.
What
could
I
do?
That's
very
different.
A
That
gives
me
a
great
foundation
for
the
future
and
so
with
terraform.
For
example,
one
of
those
foundational
things
we
decided
was
terraform
would
be
based
very,
very
heavily
on
graph
theory,
there's
a
full
talk,
I
tweeted
about
this
week
that
the
terraform
project
fleet
gave
for
an
hour
about
how
graph
theory
has
made
terraform
possible.
A
So
if
you
want
to
find
that
it's
on
Twitter
from
this
week,
but
but
this
is
what
you
want
to
do-
and
the
last
thing
you
I
do
is
understand
trade-offs,
because
every
choice
has
trade-offs
and
you
can't
do
everything.
So
a
good
example
is
here
is
when
we
were
designing
surfing
console.
There
were
our
first
distributed
systems
and
we
chose
a
bunch
of
a
bunch
of
protocols
and
things
to
base
it
on,
and
there
was
a
lot
of
cases
where
I
would
say
something
like.
Oh
it'd
be
cool.
A
If
we
did
this
and
then
we
think
about
and
say,
okay
well,
given
our
choices,
that's
actually
technically
just
impossible.
We'll
never
ever
be
able
to
do
that.
So
is
it
important
that
we're
ever
able
to
do
that?
Or
are
we
okay
with
that,
never
being
possible
and
getting
these
other
benefits
so
understand
the
trade-offs,
because
there
is
some
at
a
very
basic
level.
For
example,
are
you
building
a
distributive
system
or
you
building
a
single
server
system?
The
benefit
of
the
distributive
system
is
that
it
could
be
highly
available.
A
If
you
do
it
correctly,
the
benefit
of
the
single
server
system
is
it's
a
lot
easier
to
implement
and
you
could
do
things.
You
can
reason
things
that
you
technically
as
far
as
we
know,
theoretically,
right
now
cannot
reason
about
an
initiative
system.
So
you
have
the
trade
off
these
things
and
understand
those
trade
offs
very
early
on,
because
these
aren't
things
that
you
could
fix
later.
A
This
is
why
I
sort
of
laughs
when
any
project
says
oh,
it's
single
server
today
it'll
be
distributing
system
tomorrow,
it's
like
well
you're,
going
to
build
features
into
a
single
server
that
when
you
try
to
convert
it
to
distributed
system,
you're
going
to
have
to
remove
or
they're
they're,
not
going
to
theoretically
work
anymore,
and
so
it's
really
important
to
understand
these
trails
early
on
and
then
the
front-end
design
I
consider
the
front-end
anything
user
facing.
So
this
could
be
a
web
application.
A
If
you're
building
web
application,
it
could
be
an
app
like
on
your
phone
or
something
if
you're,
building
an
app
for
us.
It's
almost
always
the
terminal
is
what
we
consider
the
front
end
and,
and
we
design
that,
at
the
same
time
as
the
back
end
and
we
design
it
kind
of
separate
and
the
way
we
design
the
front
end
is
really
thinking.
A
How
do
I
want
to
use
this
in
an
ideal
world
I,
don't
think
about
sort
of
how
what's
technically
possible,
I,
don't
think
about
how
we're
designing
the
back
end,
I,
think
about
if
I
were
to
solve.
If
I
were
having
this
problem,
what
would
I
want?
The
terminals
will
look
like
for
me
to
solve
it
and
I
used
that
experience
to
help
guide
the
back
end
and
vice
versa,
so
build
the
front
end.
A
Design
for
humans
comes
up
again,
which
is
that
people
need
to
use
your
software
and
people
like
fun
things
so
try
to
make
your
front-end
have
nice
errors,
try
to
make
it
fun
to
use
intuitive
like
what
are
the
steps
you're
going
to
take?
How
many?
How
long
does
it
take
to
go
through?
How
is
the?
How
is
the
program
communicating
to
the
person
there's
a
human
interaction
between
software
so
designed
for
people
and
then
play
test
the
front
end?
A
So
we
actually
string
up
a
bunch
of
bath
scripts
that
emulates
the
the
front
end
and
nothing
actually
works
right.
We
fake
the
reading
the
config
in
something
but
we'll,
for
example,
with
terraform.
We
wanted
to
spin
up
a
bunch
of
servers.
We
didn't
implement
any
of
terraform
yet,
but
we
strung
up
a
bunch
of
bash
scripts
to
make
it
look
like
terraform
was
done
and
we
went
through
the
steps
of
what
we
wanted
to
achieve.
We
wrote
the
configuration
that
there
was
no
parser
for
nothing
understood
it.
A
We
did
everything
we
actually
use
terraform
before
almost
any
tariff
code
existed
and
we
found
a
bunch
of
things
that
weren't
fun
and
and
so
play
test
the
front
end,
because
you
can
you
don't
need
something
to
work
in
order
to
see
if
it's
good,
you
could
basically
the
front
end.
You
just
assume
the
back
end
is
going
to
work.
You
assumed
that
you
could
engineer
something,
but
you
want
the
front
end
appeal
right.
So
at
this
point,
we're
still
not
writing
code.
So
the
next
step
is
to
build
the
zero
point.
A
One
and
and
finally
like
engineers
could
rejoice,
because
this
is
the
part
where
we
actually
get
to
write
code
and
depending
on
how
you
do
it.
The
first
two
steps
might
take
a
long
time,
but
at
this
point
you
kind
of
have
smooth
sailing
for
a
while,
just
just
writing
code
and
for
a
zero
point.
One
I
usually
aim
at
a
three
to
six
month
time
frame,
whether
you're,
full-time
or
part-time.
If
you're
doing
full-time,
you
could
just
do
more
in
that
period
of
time.
A
Shorter
feels
like
it's
a
little
bit
you're
building
something
a
little
too
two-week,
there's
not
enough
in
there
in
three
months.
You
could
do
a
lot
better
in
three
months
and
longer
than
six
months
to
me
is
just
mentally
tiring.
If,
if
I'm,
building
something
that
for
six
months
doesn't
have
actually
get
any
users,
even
if
the
user
is
just
me,
it's
not
actually
usable
I
get
kind
of
burnt
out,
like
I
project,
becomes
far
less
interesting
after
six
months.
A
So
I
really
aim
for
three
to
six
months
in
order
to
get
something
out
there
and
get
some
positive
reinforcement,
hopefully
that
that
I'm
on
the
right
track,
and
so
with
a
zero
point
one.
You
really
want
to
aim
for
the
primary
use
case.
Basically,
a
demo,
a
basic
use
case,
working
really
great,
with
the
understanding
that
the
edge
cases
probably
won't
work
well
and
there's
going
to
be
bugs.
A
The
best
thing
you
could
do
is
just
guard
those
bugs
with
errors,
so,
for
example,
with
terraform
0.1,
actually
terraform
0.1
to
0.25
shook
warp
that
it
was
a
command
line
to
exercise
looking
at
go
panic
stack
traces,
because
if
you
did
anything
outside
of
really
the
happy
path,
it
would
probably
panic
which
is
not
human
friendly.
But
that's
sort
of
the
way
is
point.
A
One
goes
if
it
shows
people
where
you're
headed
it
shows
people
what
you're
doing
what's
possible,
with
the
understanding
that
it's
super
early
and
you're
going
to
get
there
I
like
to
I
like
to
think
of
a
0.1
as
a
path
to
a
1.0.
It's
a
0.1
is
not
something
that
should
stand
on
its
own.
It's
not
something
that
should
necessarily
be
that
good,
but
it
should
show
people
a
data
point
on
a
line
that
you're
heading
towards
a
1.0
and
even
at
terraform
zero.
One
I
would
use
it
and
it
would
crash
anyone.
A
Work
and
I'd
be
like
dang
it
but
I'd
be
like,
but
this
is
how
I
want
things
to
work.
This
is
definitely
the
direction
that
I
want
things
to
go
and
so
yeah
and
when
you're
building
a
0.1
follow
the
design
doc
you
made
so
it.
This
is
what
makes
building
the
0.1
so
easy
and
part
of
the
reason
that
I
believe
at
hofstra
group
we've
been
able
to
build
software
so
quickly
is
because,
by
the
time,
we're
coding
the
decisions
of
what
we're
coding
have
already
been
made
for
us
in
the
Google
Doc.
A
We
never
actually
ran
volt
manually
until
about
a
week
before
we
ship
to
zero
point
one.
We
just
never
saw
it
work,
but
we
didn't
have
to
because
we
automated
tested
everything
we
knew
the
api's
we're
heading
towards.
We
knew
how
the
CLI
was
going
to
look.
We
ran
it
on
a
play
test.
Environment,
we
knew
is
how
we
wanted
it
to
work
and
by
the
weeks
before,
when
we
finally
connected
the
core,
the
HT
API,
the
CLI
and
all
those
things
together.
A
The
unit
test
made
sure
they
all
worked,
and
then
the
play
tests
and
stuff
made
sure
that
we
ran
it
or
like
yep.
This
is
exactly
sort
of
what
we
designed
what
we
wanted
it
to
be,
it's
very,
very
normal
to
go
back
so,
like
I
showed
you
this
was
the
Tara
forms
initial
design
about
a
week
into
building
the
0.1.
A
We
realize
that
it
would
never
work,
and
so
we
did
a
complete
do-over,
which
we
called
terraform
simplified,
and
you
can
even
see
in
the
sidebar
that
there's
like
there's
a
there's,
a
section
called
abandoned
ideas
from
complicated
terraform,
and
so
we
talked
about
what
went
wrong.
Why?
Why
we
didn't
do
it
and
you
can
notice
it's
a
lot
shorter
too?
We
simplify
things
actually
quite
a
bit
and
this
became
terraformed.
So
if
you
were
to
read
this
document,
it's
this
document
we're
public.
A
It
could
be
there's
nothing
secret
in
there,
but
it
would
be
very
familiar
to
any
hair
form
users
it.
This
became
terraform,
whereas
the
other
one
would
sound,
really
cool
and
fancy,
but
it
never
became
anything
and
then
the
last
thing
is
the
code
is
craft.
So
when
you're
coding
of
0.1
again,
it's
a
0.1
is
just
a
path
on
the
way
to
a
1.0.
It's
not
something
you
try
to
get
out
of
sass
as
possible.
It's
not
something
that
ends
there.
A
So
you
really
want
to
make
sure
your
automated
testing
from
the
beginning,
you
care
about
how
code
is
laid
out
the
care
but
care
about
the
way
it's
designed,
because
the
code
you
write
in
20.1
very
rarely
gets
changed.
There's
code,
that's
in
vagrant
that
hasn't
changed
in
seven
years.
There's
most
of
our
projects,
the
core
of
them
rear,
really
rarely
changed.
They've
gone
three
or
four
years
without
the
core
code,
changing
in
any
significant
way
other
than
to
fix
bugs.
So
what
you're?
A
Okay,
almost
done
here
so
the
next
section
is
documentation
landing
page,
so
most
open
source
projects
just
say:
I'll
make
a
pretty
readme
and
that's
good
enough.
So
yes
do
that,
but
also
make
real
docs
and
maybe
a
website,
and
this
comes
back
to
designing
for
humans.
So
what
you
just
spent
three
to
six
months
doing
is
writing
a
lot
of
code
and
code
talks
to
computers
code
talks
to
machines,
so
you
did
a
great
job
spending
six
months
talking
to
a
machine.
A
It's
now
time
to
spend
some
little
bit
of
time,
writing
docs
and
human
language,
which
is
the
only
way
you'll
ever
talk
to
a
human
humans,
will
not
talk
to
the
code.
So
if
you
want
humans
to
actually
use
your
software,
you
really
really
need
ducks
and
docs
really
are
painful
to
write,
but
you
need
to
write
them
and-
and
the
other
thing
is
documentation
is
not
a
landing
page.
A
So
if
you
visit
your
website
on
github
pages
or
anything,
and
it's
immediately
Doc's
it's
better
than
not
having
ducks,
but
it's
it's
not
equal
to
a
landing
page.
So
documentation
tells
you
how
something
works.
Tells
you
gives
you
reference
material
answers,
questions
about
how
to
use
something.
A
landing
page
tells
you
what
something
is
and
why
you
want
to
use
it.
It's
a
lot
more
marketing,
but
you
need
marketing
in
order
for
people
to
understand
what
you're
doing
and
look
and
feel
matters.
A
So
I
don't
have
a
long
enough
to
tell
you
the
story
of
why
I
look
and
feel
matters.
But
here
are
our
websites
I'm
going
to
go
through
all
of
them
and
you'll
see
they're
very
similar.
So
this
is
the
vagrant
website
and
the
answers
we
try
to
solve
on
the
landing
pages
of
usable
landing
pages
is
what
is
this?
How
do
I
get
started
and
from
an
open-source
perspective,
how
can
I
get
involved?
A
So
there's
vagrant,
you
can
see
download,
get
started
and
then
community
stuff
is
up
right
in
the
top
bar
and
then
here's
console
I'm
going
to
just
blast
through
them,
but
you'll
recognize
common
elements
throughout
all
of
them.
What
it
is
is
really
big.
What
it
is
is
really
big
downloads
obvious
a
little
bit
different,
but
still
all
those
elements
are
there
and
you'll
see
a
change
in
style
throughout
because
vagrant
you
got
to
remember
is
six
years
old.
The
design
is
four
years
old.
A
A
So
for
documentation
we
use
what's
called
human
ordering.
We
don't
order
alphabetically.
We
order
in
a
way
that
we
expect
people
to
discover
things
like.
If
you
get
started
with
vagrant
or
any
of
our
projects.
We
try
to
order
the
dock
sidebar
in
a
way
that
intuitively
is
a
path
or
journey
that
you
would
travel
through
to
get
things
because
beginners
want
that
journey
and
advance
people
are
just
going
to
know
where
things
are
they're
going
to
be
there
enough
to
know
where
things
are.
A
You
want
to
cover
both
high
and
low
level
stuff,
so
there's
sections
on,
for
example,
getting
started
very
high
level
and
then
there's
lower
level
sections
online
networking
you
want
to
cover
both
and
the
documentation
now
and
then
repeat
yourself.
So
this
would
be
a
really
long
time
to
figure
out
as
an
engineer,
we're
taught
to
would
not
repeat
ourselves,
abstract,
right,
reusable
code,
so
that
we
don't
need
to
write
the
same
code
over
and
over
I
treated
Docs.
A
The
same
way,
I
would
write
a
document
once
and
link
to
it
everywhere
and
use
a
link
as
sort
of
an
abstraction
unit.
That's
really
unfriendly
to
people,
people
clicking
a
link
is
move
them
into
a
totally
different
context
and
people
don't
like
doing
it
as
what
I
found.
So
instead
I
repeat
myself
a
lot
more
I
explain
the
constant
concept,
different
wording
all
over
the
place
and
it's
harder
to
maintain,
but
it
makes
a
much
nicer
welcoming
experience
so
we'll
go
through
these
again.
They
all
look
pretty
similar
it'll.
A
Take
you
about
a
week
or
40
hours.
There's
like
a
full
week
to
write
documentation.
It's
a
really
really
sad
week,
but
it
pays
off
and
and
the
documentation
lasts
forever.
So
last
section
almost
out
of
time,
so
shipping
you
could
celebrate.
This
is
awesome
day.
There's
a
lot
of
endorphins
you're
really
happy.
Hopefully,
people
are
saying
nice
things,
there
will
be
people
saying
mean
things
but
ignore
them,
and
and
it's
great,
but
you
want
to
start
working
about
a
0.2
right
away.
A
You
know:
0.1
zoar
roughs,
as
I
covered
0.2,
should
be
fast
to
clean
up
things
and
just
ship
features
that
you
wanted
to
get
into
the
0.1,
but
didn't
have
time
for
Hoshi
Corp.
We
actually
aim
for
0.3
to
0.5
to
be
where
we
feel
comfortable
for
someone
running
in
production
for
other
companies
that
could
be
later
could
be
earlier
on.
Some
companies
go
straight
to
1.0.
It
matters
how
you
go.
A
One
of
the
last
things
I
want
to
cover
is
public.
Speaking
when
I
first
built
big,
Hrant
I
went
to
the
mantra
of
like.
If
you
build
it,
they
will
come.
I
completely.
Do
not
believe
in
that
at
all
anymore,
and
if
you
look
at
vagrants
trajectory
about
nine
months
in
it
was
still
getting
only
200
downloads
a
month.
Actually,
that
doesn't
show
that
for
six
months
it
wasn't
growing
or
shrinking
and
downloads
at
all.
A
So
there's
meetups,
there's
local
conferences
and-
and
you
could
I
would
go
in
this
order
and
you
don't
need
to
reach
every
single
one
right
and
and
think
about
it
is
that
meetups
are
free,
remote
conferences,
cost
money,
but
if
you're
creative
there's
ways
to
work
around
this,
a
lot
of
conferences
will
help
cover.
Some
of
the
cost,
your
employer
Ross
and
help
cover
some
of
the
cost.
A
If
you
wrap
them
in
some
way,
so
just
sort
of
get
creative
and
find
an
operator
talk
about
it
and
then
the
last
thing
is
community,
so
I
wish
I
could
spend
a
lot
more
time,
even
though
I'm
over
time
right
now
to
talk
about
community
I
could
give
a
talk
on
it.
The
three
bold
points,
I'll
tell
you
is
just
be
kind,
be
helpful
and
be
welcoming
all
the
time
and
if
you
feel
like
you
can't
be
one
of
these
three
things.
Remove
yourself
from
the
situation.
A
A
There
will
be
bad
people
that
come
and
and
just
rain
on
your
parade,
but
try
to
be
nice
to
them
and
if
they
don't
be
nice
in
return,
just
turn
them
away
just
turn
it
off,
and
all
this
I
learned
from
Apple
I
blogged
about
how
to
interact
with
people
on
my
blog
and
so
Google
ad.
If
you
want
and
that's
it
I
think
you
could
all
do
it,
it's
very
possible.
It's
fun
and
good
luck.
Thank
you.