►
From YouTube: Developing Nirvana by Corey A. Butler, Author.io
Description
Developing Nirvana - Corey A. Butler, Author.io
It is common to hear how much impact user experience has on the success of an application. Similarly, developer experience (DX) has a huge impact on the quality and usefulness of code. Why are some libraries so popular while others disappear? How do you create code people will actually use? In this talk, Corey Butler will review the oft-overlooked art of developer workflow. He will share tips and tricks used to make life sane, and even pleasurable, acquired on his journey through open source projects like NVM for Windows, Fenix Web Server, and node-windows/linux/mac. Find out how a focus on DX can elevate you and your code from obscurity to nirvana.
About Corey Butler
Corey is an entrepreneur, technologist, and consultant with a passion for developer experience (DX) and workflow management. He is the author of NVM for Windows, node-windows/mac/linux, NGN, numerous node modules, and Fenix Web Server. Most recently, he and his brother founded Author.io to commercially support Fenix Web Server and other OSS software that has served hundreds of thousands of users across the globe. He also co-organize's Austin's Bleeding Edge Web meetup.
A
So,
as
monaco
said,
I'm
Cory,
Butler
and
I
do
live
here
in
Austin.
So
it's
great
to
see
everybody
here,
gathering
around
node,
you
know
in
my
own
hometown,
so
author
I
yo
is,
as
he
said,
brand
new.
The
under
construction
page
was
just
launched
like
yesterday,
so
this
is
is
really
new,
but
this
talk
is
kind
of
inspired
by
the
journey
that
led
to
that,
as
well
as
several
the
open
source
projects
that
have
really
been
around.
A
So
really
we're
going
to
be
trying
to
condense
two
years
into
about
20
minutes
or
the
talk,
so
this
is
going
to
go
fairly
fast.
If
you
have
questions
or
want
to
talk
in
detail
about
anything,
I
will
be
around
the
conference.
Just
stop
me
and
ask
so
developing
nirvana
Nirvana
is
defined
as
a
transcendent
state
in
which
there
is
neither
suffering
desire
nor
sense
of
self,
and
the
subject
is
released
from
the
effects
of
karma
and
the
cycle
of
death
and
rebirth.
It
represents
the
final
goal
of
Buddhism.
A
Now
this
isn't
a
religious
talk
right.
It's
the
key
points
here
are
that
it's
talking
about
really
disregarding
suffering
desire.
Sense
of
self
and
to
me,
that's
really
a
state
of
contentment
and
that's
something
that
we're
looking
for
in
our
workflows
and
then
it's
also
a
goal.
It's
not
something!
That's
here
right
now.
It's
something
that
we're
pursuing
so
I
like
to
think
of
developing
nirvana
is
pursuing
a
state
of
contentment.
A
Now,
in
order
to
do
that,
we
have
to
ask
what
is
containment,
what's
a
composed
of
and
there's
really
two
major
factors,
the
amount
of
time
that
you
spend
working
on
stuff,
so
they
learn
the
time
you're
spending
coding,
given
the
time
you're
thinking
about
the
code
planning
processes,
then
there's
the
stress
factors.
Now
time
is
really
kind
of
the
currency
of
life
and
so
how
we
spend
it
where
we
spend.
It
is
important
to
everybody.
This
is
a
unifying
factor
beyond
just
developers
and
managers
and
business
folks.
A
So
it's
something
we
can
all
relate
to
stress.
On
the
other
hand,
it
directly
impacts
how
we
experience
that
time.
So
as
a
developer,
if
you
are
working
on
something,
that's
stressing
you
out,
obviously,
that's
not
not
something
that
you
want
to
be
doing
and,
as
you
would
expect
here,
hi
time
spent
high
stress
is
low
contentment,
whereas
load
time
spent
and
load
time
stress
is
much
higher
contentment.
A
The
answer
to
this
is
really
that
we
don't
because
again,
this
is
a
journey
and
there
are
many
things
we
can
do
on
our
development
journey,
though
that
will
make
our
lives
a
lot
more
enjoyable
and
so
really
answering
the
question
of.
How
can
you
be
a
happier?
Developer
really
begins
with
your
understanding
of
these
motivators
and
people
have
a
lot
of
difficulty
actually
asking
themselves
the
questions
surrounding
these
points,
so
I
have
a
little
trick.
A
I
call
it
find
the
fulcrum
really
your
time
and
your
stress
and
your
own
objectives
when
you're
working
are
competing
forces
and
their
offset
by
the
work
that
you
actually
do
this
or
your
actual
effort-
and
these
are
not
always
equal
forces
so
like
in
this
stick
figure
diagram.
You
can
see
that
the
the
load
arm
here
is
a
lot
shorter
than
the
effort
arm.
So
the
key
is
finding
a
point.
A
Now,
for
me,
this
begins
with
developer.
Workflow
I've
been
a
consultant
most
of
my
career,
and
so
I've
spent
a
lot
of
time.
Thinking
about
workflow.
The
reason
that
I
keep
coming
back
to
this
term
is
because
it's
really
the
path
of
least
resistance
to
change.
This
is
both
an
individual
level
or
at
an
enterprise
level.
A
It's
really
the
key
piece
that
we
can
control
as
an
individual.
So
even
if
you
don't
have
much
say
in
the
overall
architecture
of
your
applications
that
you
work
on,
maybe
it's
a
large
system
you
can
still
control
your
own.
Individual
work,
flow
or
flow
is
also
something
that
touches
all
parts
of
the
development
life
cycle,
including
the
human
side,
and
so
the
question
that
I
kept
asking
myself
over
and
over
is
why
don't
more
people
actually
pay
attention
to
this
and
I?
A
A
How
many
different
things
do
you
have
on
your
plate
at
any
given
time
and
that
one
thing
that
load
can
be
quite
challenging
and
what
this
really
does?
Is
it
surfaces
a
problem?
That's
in
almost
all
of
IT
and
that's
the
empathy
is
really
lacking.
Really
people
don't
understand
what
we
do
as
developers.
Sometimes
we
don't
even
understand
what
we
do
is
developers
mean
think
about
all
the
new
technology.
That's
out
there
and
so
I
t
isn't
really
known
for
understanding
emotions.
A
Yet
we
all
experience
them
at
something
again
that
we
all
have
in
common
and
the
biggest
emotion
that
I
feel
as
developer
is
often
times
that
we
can
be
pretty
overwhelmed
and
so
I
look
to
areas
like
wine.
Now,
I,
don't
know
if
any
of
you
are
familiar
with
wine,
but
winemaking
has
really
been
around
for
centuries.
Maybe
maybe
the
millennia
I
don't
remember,
but
it's
interesting
because
there
are
a
lot
of
parallels
to
development
like
wine
changes
through
its
entire
life
cycle
based
on
the
environment
based
on
the
temperatures
based
on
people's
tastes.
A
So
if
you
and
I
are
sharing
the
same
glass
of
wine
but
in
different
glasses,
if
you
swirl
it
around,
the
chemical
makeup
of
the
wine
is
going
to
change
and
that's
going
to
be
different
in
your
glass
and
in
mind.
So
we
may
have
a
complete
different
tastes
and
it
might
be
subtle,
but
it
is
different,
even
though
we're
drinking
the
same
wine
and
that's
very
similar
to
things
like
node
modules
or
two
frameworks
that
you
may
be
using.
A
So
my
tip
is
to
think
about
targeting
continual
change,
and
this
is
really
the
opposite
of
thinking
about
a
lot
of
people
when
they
think
about
workflow.
I
just
want
to
make
their
lives
easy.
They
want
an
easy
development,
workflow
and
I
think
that
this
is
really
in
the
eye
of
the
beholder,
because
what
you
may
think
of
as
easy
may
seem
really
verbose
to
someone
else.
A
So
again,
it's
a
changing
environment,
and
so,
if
you
focus
on
change
as
your
common
denominator,
you
can
get
a
lot
further
with
your
code,
and
so
that's
where
I
learned
this,
mostly
in
creating
nvm
for
windows.
Now
for
anybody,
that's
unfamiliar,
it's
a
version
manager,
as
was
mentioned,
one
of
the
keynotes
there's
a
working
group
around
this
now
because
it's
become
a
rather
hot
subject,
but
at
the
end
of
the
day,
it's
a
version
management
for
node
and
what
I
recognized
when
I
created
this
was
that
the
environment
was
constantly
changing.
A
So
this
came
out
first
right
around
the
node
0
dot,
11
branch,
and
then
we
saw
the
introduction
by
ojs,
then
we
saw
the
merger
of
I
ojs
and
there
were
naming
changes.
We
saw
the
unstable
and
stable
versions
moving
into
LTS
and
current,
and
now
we're
looking
at
things
going
forward
being
able
to
swap
out
the
engine
right
you
can
throw
in
chakra
instead
of
the
eight.
A
So
that
was
really
the
the
genesis
behind
nvm
for
Windows
was
that
I
knew
that
the
environment
was
always
going
to
change,
and
how
do
I,
how
do
I
handle
that
and
like
with
any
of
any
version
manager,
there's
an
expectation
that
you
are
going
to
save
time?
You
know
nobody
wants
to
install
and
uninstall
and
reinstall.
You
know
different
versions
just
in
order
to
test
them,
and
this
is
really
what
this
utility
is.
A
What
gave
nvm
for
windows
use
and
value,
and
it's
why
people
keep
using
it
today,
but
it's
not
really
what
made
it
popular.
So,
the
question
of
what
makes
something
popular
and
nvm
for
windows
has
become
popular.
It's
the
most
starred
node
version
manager
for
windows.
There's
been
a
whole
lot
of
downloads
in
the
last
couple
of
months
and
I
think
that
these
numbers
are
frankly
a
little
bit
small,
because
there's
more
deployment
of
this
internally
in
organizations
than
there
is
externally
and
there's
a
fair
number
of
contributors.
A
In
fact,
after
this
conference
we're
going
to
be
doing
translations
into
several
different
languages
and
the
contributors
are
coming
from
all
over
the
globe
and
I
think
that
that's
really
unique,
because
when
you
think
about
the
popularity
of
a
project
or
getting
people
behind
a
project
that
you're
working
on
you're
asking
questions
about
like
what
is
a
motivator
and
that
last
point
the
about
contributors
being
across
a
globe.
Is
what
solidified
this
for
me,
because
this
is
written
and
go.
A
This
has
nothing
to
do
with
node,
there's
not
a
like
a
javascript
in
this
application,
but
there
are
contributors
that
are
so
passionate
about
node
that
they
are
willing
to
go
and
learn
at
least
a
little
bit
ago
to
help
contribute
to
this,
and
so
I
asked
myself.
Why
would
anybody
do
that?
Well,
I
mean
who's
as
crazy
as
I
am
to
sit
down
and
learn
another
language
to
manage
another
language,
and
it
really
boiled
down
to
the
stresses
again
when
I
created
this
application.
This
was
probably
the
darkest
time
of
my
life.
A
I
had
more
stresses
than
I
could
possibly
imagine.
I
actually
wrote
this
from
primarily
doctor's
office
lobbies,
so
my
life
was
kind
of
in
turmoil
and
at
the
time
I
was
also
teaching
a
lot
of
people
about
node,
and
the
big
challenge
was
that
node
was
moving
so
fast
that
it
was
hard
to
keep
up
with
things.
So
the
popular
factor
came
in
to
just
an
installer.
A
You
know
just
being
able
to
get
this
installed,
because
nvm
for
windows
was
not
the
first
version
manager
for
windows
that
were
several
before,
but
it
was
the
first
one
to
come
with
an
installer
and
so
that
dropped
people's
stress.
I
dropped
my
stress
and
so
developers
would
respond
to
me
saying
that
they
felt
good
using
this
tool
and
about
well
it's
just
an
installer,
but
getting
to
the
point
where
you
can
actually
use
your
code
is
as
important
as
the
code
itself
and
what
it's
doing
for
you.
A
So
my
tip
in
this
is
to
just
ask
yourself
about
your
own
stresses.
This
may
sound
kind
of
stupid,
but
at
the
end
of
the
day
you
know
the
little
nitpicky
things
that
really
would
gnaw
at
you
and
who
really
wants
to
be
working
day
to
day
with
a
workflow
that
gnaws
at
you,
sometimes
that's
more
challenging
than
some
of
the
big
stresses
that
we
have
in
our
lives
and
that
also
moves
into
what
makes
people
actually
use
a
technology
and
I
think
this
is
unequivocally
trust.
A
It
doesn't
mean
that
you
can
be
using
the
best
technology
out
there.
It
just
means
that
you
can
be
using
a
technology
that
you
believe
in,
and
this
is
kind
of
where
node,
in
my
mind,
came
from.
So
if,
if
any
of
you
have
read
any
of
our
alien
doll's
blogs,
he's
got
one
out
there
talking
about
how
he
hates
just
about
all
software,
it's
kind
of
a
distrust
in
software,
and
that
is
what
brought
a
lot
of
the
concepts
that
are
now
node
around
in
the
first
place.
A
So
my
trick
here
for
this
is
to
piggyback
off
of
things
that
people
do
trust
and
the
example
here
would
be
the
the
node
windows,
node
Mac
and
no
linux
series.
This
was
the
this
was
a
series
or
it's
three
separate
projects
that
I
created
a
number
of
years
ago.
Now,
at
this
point,
and
I
piggybacked
off
of
the
trust
in
the
operating
system,
now
you
may
be
a
Mac
user
or
Windows
user,
but
maybe
you're,
not
both.
A
You
may
not,
or
you
know,
that
the
Mac
operating
system
and
the
Windows
operating
system
are
solid
and
they're
going
to
be
able
to
do
the
things
that
you
would
expect
to
be
able
to
do.
But
you
might
not
know
how
to
accomplish
everything.
So,
in
this
case,
these
projects
you're
able
to
set
up
background
damon's
or
background
services
to
run
native
node
scripts.
So
you
just
run
a
script
and
it
will
run
as
though
it's
a
native
process
on
any
one
of
these
operating
systems
using
the
same
consistent
API.
A
So
again,
it's
a
blending
of
trusting
this.
This
project
will
take
the
trust
that
you
may
have
an
operating
system
operating
system
and
combine
it
with
the
trust
that
you
have
in
your
own
ability
to
code
in
node,
and
it
alleviates
the
problem
of
having
to
understand
how
the
intricacies
of
each
one
of
these
operating
systems
worked,
and
there
was
a
third
motivator
in
this
to
to
just
kind
of
emphasize
the
point
of
popularity.
Again.
The
node
windows
project
is
even
though
they're
all
basically
the
same.
A
It's
far
and
away
the
most
popular
of
these,
and
it
took
yet
another
stress
off
of
developers,
primarily
by
the
fact
that
there
are
no
native
dependencies
in
this
one,
and
that
was
especially
critical
at
the
time
because
I
in
order
to
run
a
background
process
on
Windows.
If
you
did
have
to
use
native
dependencies
you're
talking
about
a
10
gigabyte
download
with
visual
studio
there's
channel,
there
were
a
lot
of
challenges
between
the
versions
at
that
time,
so
without
any
native
dependencies
that
wasn't
a
problem.
A
So
again,
the
the
more
the
stress
decreases,
the
more
popular
or
a
project
can
become
so
long.
As
you
know,
what
stresses
those
are
you're
dealing
with
so
I
modern
developer
experiences.
Today
again,
this
is.
This
is
really
the
last
couple
of
months
that
I've
been
working
on
a
couple
of
different
libraries,
as
well
as
a
tool
called
Phoenix
which
released
a
couple
of
years
ago,
and
it
really
is
what
I
attribute
my
more
recent
work,
the
success
of
that
and
how
quickly
I
was
able
to
get
things
done.
A
I
attribute
to
phoenix,
so
I'm
going
to
take
a
quick
look.
There
are
two
libraries
that
have
been
working
on:
ngn
is
its
kind
of
the
building
blocks
for
your
own
framework,
both
back-end
and
front-end.
Chassis,
on
the
other
hand,
which
was
actually
created
by
my
brother,
is
a
layout
engine
based
on
responsive
topography,
which
is
just
an
ethos
that
we
like
to
follow
now.
Ngn
has
a
whole
bunch
of
stuff
going
on
with
it
there's
data
modeling
there
are
microservice
architectures,
there's
a
whole
bridging
platform.
A
It
works
with
docker,
their
native
docker
containers
out
there
that
you
can
use
chassis
has
a
web
component
library.
It
has
its
own
front-end
utilities,
there's
a
lot
of
stuff
in
this,
and
it
was
two
guys
working
part
time
that
got
this
done
in
less
than
nine
months,
something
that
a
lot
of
teams
can't
do
in
years
and
the
reason
behind
this
is
a
really
really
simple
tool.
Phoenix
is
a
visual
static,
web
server
for
windows
and
mac
and
it
ships
the
unique
thing
compared
to
other
static
web
servers.
A
Is
this
ships
with
a
sharing
system?
So
it's
point-and-click.
You
fire
up
a
website
on
your
local
machine,
pointing
to
a
directory
that
contains
your
HTML
files
or
JavaScript
or
whatever
click
a
button
share.
It
you
get
a
link
and
you
can
now
immediately
collaborate
with
people,
so
you're
serving
from
your
local
machine
directly
to
the
web,
and
then
you
shut
it
down
when
you're
done.
So
what
this
gave
us
was
instant
infrastructure
and
instant
sharing.
It
gave
us
faster
feedback
loops
and
it
was
a
lot
more
intuitive
for
people
that
weren't
just
back-end
developers.
A
So
we
brought
our
time
and
stress
down
again
and
we
really
gave
ourselves
a
platform
that
we
could
trust
for
productivity
now.
The
result
of
all
of
this
was
that
are
we
had
a
in
time?
We
stopped
focusing
so
much
on
local
infrastructure
and
administration,
so
things
like,
maybe
needing
to
run
an
engine
X
server
and
reconfiguring
it
to
test
something
we
didn't
have
to
do
that.
We
didn't
have
the
administration
of
having
to
launch
up
a
new
google,
hangout
or
some
other
way
to
collaborate
across
country,
which
was
our
case.
A
So
our
time
shifted
away
from
that
into
doing
things
that
were
more
relevant
to
the
libraries
that
we
were
working
on.
So
things
like
unit
testing
and
documentation
and
as
a
result,
we
wound
up
with
nearly
800
unit
test
for
ngn
and
the
project
hasn't
even
really
been
formally
released
so
ultimately
I.
This
gave
us
more
useful
code,
more
robust
code,
fewer
bugs
the
shorter
developer
onboarding
time,
and
the
code
was
really
just
easier
to
understand
because
we
had
the
time
to
focus
on
it.
A
So
the
future
for
us
is
kind
of
a
little
bit
more
of
the
same
of
Phoenix
web
server.
3.
The
screenshot
is
a
little
bit
small,
but
it
focuses
on
thing
on
new
challenges
that
we
experience,
things
like
being
able
to
toggle
on
and
off
ssl
being
able
to
test
a
core
support
or
gzip
compression.
Does
that
actually
matter
in
your
application
or
not?
And
it
just
brings
up
more
questions
and
that's
a
good
thing
a
lot
of
times.
You
think
that
if
you
are
working
on
an
application,
you
just
want
it
done.
A
You
don't
want
to
be
asking
more
questions
and
I.
Think
the
exact
opposite!
You
really
should
be
asking
as
many
questions
as
you
can
so
kind
of
keeping
with
our
Austin
theme,
I,
just
I'd
like
to
leave
you
with
the
idea
of
continue
to
ask
questions
about
your
own
workflow.
It's
not
you
know.
Being
able
to
ask
questions
about
things
that
you
may
consider
to
be.
A
A
A
The
original
version
is
based
on
node
WebKit,
it's
a
pretty
old
version,
but
the
new
version
is
based
on
electron.
It
I've
been
able
to
run
it
on
linux,
but
I'm
not
planning
to
support
linux
just
due
to
this
year
number
of
intricacies
that
it
would
frankly
take
too
much
time
for
to
you
guys,
yeah.
The
question
was
around
phoenix
and
the
fact
I
mentioned
that
it's
supported
on
windows
and
mac,
and
the
question
was
about
whether
or
not
that
was
built
on
electron
and
the
answer
was.
The
original
version
was
based
on
webkit.