►
Description
Presented by: Nick Liffen
Let’s discuss why modern software needs processes and tooling to be developers-first. Nick will explain why security is becoming essential and why just shifting your security tooling left won’t cut it for your developers. Nick will dive into some of the data and tools at hand, which can help push your developers to be more aware of security, and truly treat it as a first-class citizen of the software development lifecycle. (SPEAKER MANAGER: Does "security" need to be added before "processes" in the above?)
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
Good
morning,
good
afternoon
and
good
evening,
and
welcome
to
Universe
whether
you're,
watching
this
remotely
or
you're
watching
it
in
person,
it's
a
pleasure
to
have
you
here
today
and
it's
really
exciting
for
me
to
go
through
what
shifting
left
versus
developer,
First
Security
really
means
I
hope,
you're,
excited,
I,
hope
you
saw
this
title
and
was
like
I
want
to
learn.
More
I
am
really
excited
to
go
through
what
the
differences
are
between
shift
and
left
and
developer
First
Security.
So
let's
not
waste
any
time.
Let's
get
straight
into
it.
A
My
name
is
Nick
I
am
a
director
within
the
GitHub
Advanced
security
space,
my
location
I'm,
based
in
Reading
in
the
UK
now
again
just
to
share
some
of
my
passions
with
you.
I
am
a
huge
believer
in
developer.
Experience
and
I
have
a
big
passion
for
Dev
secops
and
just
to
share
something
outside
of
a
work
environment
I'm,
an
avid
golfer
if
at
any
time
that
we
meet
face
to
face
I,
am
always
open
for
a
conversation
about
golf.
A
Now,
that's
a
quick
introduction
into
myself
again,
you're,
probably
thinking
the
title
is
a
bit
ambiguous.
What
what
are
you
actually
going
to
talk
about
in
this
presentation,
so
I
actually
want
to
go
through
a
journey
with
you
today
and
the
way
we're
going
to
start?
This
is
by
talking
about
the
history
of
a
developer.
I
want
to
go
back
to
the
beginning,
well
about
17
years
ago
to
be
specific
and
talk
about
how
software
development
used
to
be
I
then
want
to
move
on
and
talk
about.
A
So
that's
really
thinking
about
how
devops
devsecops
influences,
how
we
work
and
then
I
want
to
get
a
little
bit
controversial,
and
this
is
where
it's
going
to
get
interesting,
because
I
remember
want
to
talk
about
how
shifting
left
has
actually
caused
some
unexpected
consequences
that
we
didn't
think
about
and
I'm
going
to
tease
you
with
some
nice
ideas
that
we
can
share
on
how
you
can
improve
things.
I'm
then,
going
to
finish
with
why
it's
important
to
rebuild
that
trust
within
the
developer
Community
before
we
dive
into
any
of
the
per
se
big
content.
A
I
more
just
want
to
take
the
time
to
open
up
with
a
question
for
you
to
consider
so
I
want
you
all
to
think.
What
is
your
answer
to
this
question?
Is
the
shift
left
term
the
correct
phrase
the
industry
should
be
advocating
for
and
I
know
a
lot
of
you
are
probably
thinking
going
Nick.
Of
course
it
is
like
shift
left,
that's
what
we've
been
trying
to
do.
This
is
what
everyone's
told
us
to
be
doing.
A
Why
are
you
asking
me
this
question,
but
I
really
want
you
all
to
take
the
time
just
to
think
about
what
your
answer
would
be
to
this
question
so
again,
think
about
it
now
and
again,
as
you
go
through
this
journey,
maybe
think
about
how
you
may
reflect
on
your
own
answer.
Okay,
so,
let's
start
with
how
a
developer
used
to
work
and
for
that
to
happen,
I
want
to
introduce
you
to
someone
called
Finn.
So
Finn
is
a
developer
and
the
year
is
2005.
A
So
we're
going
back
about
17
years
now
now
Finn
has
been
given
a
use
case.
Finn
has
been
told
that
he
needs
to
go
out
there
and
deploy
a
web
application.
So
that
is
the
use
case
that
Finn
has
been
given
in
the
year
of
2005
when
we
were
racking
and
stacking
them
servers
now
on
a
really
really
high
level.
A
This
is
how
Finn
used
to
work
Finn
used
to
have
a
project
manager
that
would
go
out
there
and
would
build
all
of
the
requirements
they
would
go
out
there
like
and
make
sure
that
what
Finn
built
was
actually
going
to
meet
the
need
of
the
business.
So
that
was
how
it
would
all
start
and
all
begin.
Then
it
would
be
handed
over
to
Finn
and
film
would
be
there
and
film
would
go
ahead
and
write
all
of
that
application
source
code
that
was
needed
for
this
web
application,
so
Finn
would
be
there.
A
He
would
then
write
all
of
the
code
and
Finn's
unhappy.
Finn
is
like
you
know
what
I'm
really
happy
with
what
I've
built.
So
what
Finn
would
then
do
Finn
would
then
hand
off
to
to
the
testers
and
Finn
would
be
like
hey
I'm
done,
I'm
feeling
good
testers.
Are
you
able
to
go
ahead
and
test
this
code
and
again
Finn
would
just
sit
back,
relax.
Maybe
he'd
move
on
to
something
else.
Now
what
again,
once
testers
are
done,
Finn
would
be
like
okay
cool.
A
Maybe
I
can
fix
any
of
the
problems
that
you
have
found
and
again.
He
would
then
throw
like
pass
it
over
to
the
security
people
and
the
security.
People
would
then
go
ahead
and
run
all
of
their
security
tests
and
make
sure
that
it's
happy
again,
maybe
a
week
or
two
later
they'd
bring
it
back
to
Finn
and
Finn
would
go
ahead
and
fix
any
of
the
problems
that
have
been
identified.
And,
finally,
once
that's
all
done,
Finn
would
most
likely
again
we're
in
2005
right
now
hand
over
to
some
infrastructure.
A
People
and
Finn
would
then
go
ahead
and
like
ask
them
to
actually
rack
and
stack
some
of
the
web
servers
that
were
needed
to
get
this
done,
but
again
what,
whilst
the
testers,
the
security,
people
and
infrastructure
people
were
doing
their
thing,
Finn
would
sit
there.
Maybe
he'd
move
on
to
a
different
like
application,
but
in
regards
to
this
project,
he's
done
and
again
once
that's
all
all
iterated
on
maybe
there's
a
few
test
problems.
He
needs
to
fix
a
few
security
problems.
A
The
infrastructure
will
take
probably
three
or
four
weeks
an
application
would
be
built,
and
a
lot
of
you
are
probably
thinking
Yep.
This
is
a
very
waterfall
way
of
working,
but
this
is
how
it
used
to
be,
and
probably
still
is
in
quite
a
few
places,
but
this
is
how
developers
used
to
work,
and
a
lot
of
you
are
most
likely
thinking
right.
That
just
did
not
work.
A
That
was
not
very
efficient
and
there
were
four
main
per
se
problems
that
were
identified
here,
the
main
one
being
it
was
so
slow
right
like
if
you
go
back
to
that
previous
example,
the
tested
was
would
take
two
weeks
after
that
the
security
people
would
take
two
weeks.
Then
the
infrastructure
people
would
take
two
weeks
and
businesses
were
like.
Oh
well,
I
can't
deliver
that
value
quick
enough,
but
also
it
was
really
expensive
because
it
was
taken
all
of
that
time.
A
So
all
of
the
people
resources
was
adding
up
and
up
and
up
and
up,
and
that
also
led
to
things
being
really
really
inefficient.
There
was
not
much
efficiency
in
that
process
and
I'm
sure
I'm
standing
here
today.
You
can
also
think
of
three
or
four
or
even
probably
more
problems
with
the
way
that
that
model
used
to
be
and
like
the
industry
terminology
for
this,
as
you
all
probably
know,
is
you
throw
it
over
the
wall
right?
A
It's
not
your
responsibility,
so
someone
would
go
out
there
and
the
project
manager
would
do
the
analysis
and
would
do
the
requirements
they
would
be
like
I'm
done,
throwing
it
over
the
wall
to
the
developer.
Who
would
most
likely
do
the
design
and
do
the
development
and
once,
in
this
case,
Finn's
done
had
to
throw
it
over
the
wall
to
the
test
in
the
security
people,
and
then
you
would
just
rinse
and
repeat
all
the
way
until
the
application
was
done,
and
it
just
wasn't
that
efficient.
So
what
happened?
A
Well,
this
whole
shift
left
phrase
in
this
whole
shift.
Left
Paradigm
was
was
per
se
pushed
to
help
solve
a
lot
of
these
problems
now
I
think
if
you
speak
to
one
developer
or
you
speak
to
another
developer,
each
one
of
them
would
most
likely
give
you
a
different
interpretation
on
of
what
shift
left
really
means,
and
you
can
see
a
few
diagrams
here
on
the
screen
to
Aid
you
but
I.
A
Think,
like
the
fundamentals,
stay
the
same,
it's
really
about
enabling
developers
to
have
access
to
a
lot
of
that
data
earlier
in
that
software
development
life
cycle.
So
they
can
find
possible
bugs
problems
issues
earlier.
So
again,
it's
a
lot
more
efficient,
so
going
back
to
the
previous
slide.
Maybe
the
developer
would
actually
have
the
testing
themselves
and
the
security
people
would
per
se
shift
that
left
onto
the
developer.
So
it's
really
about
trying
to
shift
a
lot
of
the
processes
left
in
that
software
development
life
cycle.
A
So
again,
like
all
of
the
shift
left
Paradigm
has
come
about
and
we
started
to
see
it.
We
started
to
see
a
change
right.
We
started
to
see
a
positive
change
and
I
think
that
was
really
noted
and
that's
why
shift
left
has
been
so
predominant
and
I
think
like
what
actually
happened
when
we
started
to
shift
left,
because
when
we
take
a
step
back,
let's
actually
walk
through
what
actually
happened.
So,
let's
start
with
testers
well
again,
previously
a
developer
would
hand
over
to
the
tester
in
the
shift
left
model.
A
A
Are
you
able
to
go
out
there
and
provision
the
infrastructure
too,
like
we're
working
in
an
infrastructure,
Insurance
code
model
and
then
we'd
be
like
yeah,
like
we're,
shifting
left
like
I'm,
more
than
happy
to
go
out
there
and
start
building
the
infrastructure?
That
makes
a
little
sense
so
again,
we've
now
shifted
the
responsibilities
or
a
lot
of
that
work
onto
Finn
and
the
project
manager
again
like
because
we're
now
working
in
likely
more
of
an
agile
way.
Finn
would
also
have
a
lot
more
responsibilities
here.
The
project
manager
will
go
well.
A
I,
don't
really
know
how
all
of
these
user
stories
work
like?
Are
you
able
to
go
out
there
and
write
all
of
these
issues
and
and
pull
it
into
our
kanban
board,
so
we're
able
to
to
track
this,
but
I
also
need
you
to
attend
daily
stand-ups
and
do
everything
there
and
finally
be
like
yeah
like
sure,
like
I'm,
fully
on
board
with
shifting
there
for
sounds.
A
So
again
it
can
be
a
lot
more
more
efficient,
so
Finn
like
are
you
good
to
do
a
lot
of
the
security
stuff
as
well
and
Finn
would
sit
there
and
be
like
yeah
like
okay,
yeah
I'm
on
board,
with
this,
like
I
I,
think
I
know
how
to
fix
log
injections.
I
think
I
know
how
to
do
security
and
again,
like
what
happened
is
as
we
started
to
shift
left
like
these.
A
The
roles
and
responsibilities
of
the
developer
has
grown
over
time,
as
we
have
shifted
left
so
again,
like
Finn,
would
still
partner
with
a
project
manager
in
an
agile
World,
less
of
a
scrum
Master
Finn
would
still
write
the
code
and
again,
if
it's
a
larger
application,
Finn
may
still
partner,
with
some
testers,
to
do
some
more
larger
regression
testing.
But
Finn
is
now
doing
a
lot
of
the
unit
testing
again
like.
A
If
Finn
has
any
questions,
he
will
partner
with
security,
so
these
people
are
still
here
and
these
sort
of
people
were
still
around
to
Aid
and
help.
But
again,
a
lot
of
the
core
responsibilities
of
this
has
now
shifted
onto
Finn
and
like
when
we
think
about
what
this
looks
like.
It
looks
a
lot
like
this
and
if
you
think
now
about
the
touch
points
that
Finn
has
to
go
through
on
a
daily
basis,
then
we
just
went
from
again
in
2005
just
write
in
the
application
source
code
and
nothing
else.
A
But
when
you
look
at
it
today,
Finn
has
to
interact
with
about
a
hundred
different
tools
and
like
working
at
GitHub.
We
see
a
lot
of
these
devops
models
and
there's
a
lot
of
companies
that
come
in
and
like
check
out
this
amazing
devops
model
I've
automated
everything-
and
we
see
these
diagrams
and
I.
Look
at
it
and
I
go
wow.
Your
developers
must
go
through
so
much
context.
Switching
every
single
day
your
developers
have
to
go
between
Trello
to
kubernetes,
to
npm
to
servicenow
all
of
these
different
tools.
A
Your
developers
have
to
go
to
and
then
you'd
have
a
devops
person.
That
goes
everyone
great
news.
We
have
now
added
another
tool
to
this
tool
chain.
We've
automated
UI
testing
we're
going
to
bring
insight
for
us
developers,
I
assume
you're
good
to
maybe
start
writing
some
Cyprus
tests
as
well,
and
they
add
another
tool
so
again,
like
as
we've
shifted
left.
A
Yes,
the
responsibilities
have
grown
but
like
what
that
has
also
meant
is
the
actual
touch
points
and
the
interactions
that
developers
have
to
you
do
on
a
daily
basis
has
also
grown
on
behalf
of
most
of
the
developers
out
there.
This
is
how
it
feels,
and
this
is
what
it
actually
looks
like
there
is
it's
not
the
simple
model
of
writing
code
now
we're
having
to
interact
between
five
or
six
different
tools
and
it's
incredibly
frustrating
and
again,
like
I
mentioned.
A
We
needed
to
stay
to
take
a
step
back
earlier,
but
I
think
this
is
a
really
important
time
for
us
to
maybe
take
it
that
step
back
again
in
this
presentation
and
actually
think
about
what
shifting
left
has
actually
done
over
the
last
five
or
ten
years,
like
I.
Think
it's
really
easy
to
consider
that
up
front
and
the
apparent
value
of
Shifting
left
right.
I
think
we
alluded
to
a
lot
of
the
inefficiencies
to
start
with,
but
do
we
actually
think
about
them?
A
Downstream,
end
user
of
experiences
does
so
often
overlooked
on
the
right
hand,
side
here,
you
can
see
four
core
key
pillars,
so
the
first
one
and
I
mentioned
this
earlier
is
developers
have
now
such
high
context
switching
levels
so
before
they
would
stay,
maybe
within
their
IDE
they
would
stay
within
their
source
code
management
tool
and
their
terminal.
So
three
aspects,
but
today
a
developer
has
to
context
switch
between
their
testing
tool,
their
security
tool.
A
Maybe
they
have
two
or
three
different
types
of
these
tools
and
maybe
again
they're
now
using
a
provider
to
do
a
lot
of
their
infrastructure
as
code,
so
they
have
to
go
there
as
well,
like
developers
have
to
context
switch
between
five
or
six
different
tools,
and
what
does
that
mean?
It
means
that
lack
of
focused
productivity
right,
like
the
developers,
aren't
spending
as
much
time
today
as
they
was
actually
writing
a
lot
of
that
software
and
like
when
we
go
back
to
what
were
some
of
the
problems
that
shifting
left
was
trying
to
solve.
A
A
The
answer
was
no,
so
that
gives
a
sense
of
a
lack
of
empowerment
in
that
developer
community.
So,
as
we
have
shifted,
left
and
increased
them
roles
and
responsibilities,
we
which
increases
them
touch
points.
You
see
these
four
real
key
pillars
start
to
be
more
predominant
on
a
daily
basis
and
I
think
like
let's
actually
go
into
an
example
and
let's
use
a
real
life
scenario
here,
let's
say
five
years
ago,
these
security
tools
were
out
there
and
they
were
really
built
for
the
security.
Persona
right
makes
perfect
sense.
A
Five
years
ago,
security
was
just
a
security
Persona
thing,
so
it
makes
absolute
sense
for
these
security
tools
to
build
their
tool
and
build
their
product
to
meet
their
customer
fantastic,
but
then
shift
left
came
along
right.
We
needed
to
shift
a
lot
of
these
tools
left,
so
we
had
to
shift
the
security
to
the
left
and
that's
what
a
lot
of
companies
done.
They
said.
Okay,
do
you
know
what
we're
really
happy
with
this
tool?
It's
great!
A
Let's
go
ahead
and
shift
that
left
and
let's
shift
that
to
the
developers
and
they
were
like
amazing
done,
I've
gone
ahead
and
I've
shifted
my
tool
left
I'm,
really
looking
forward
to
getting
the
benefits,
my
developers
we're
going
to
be
more
secure,
right
and
I.
Think,
like
you
started
to
see
a
lot
of
these
pain
points
and
like
this
is
what
we
hear
on
a
daily
basis.
Like
developers
are
out
there
and
going.
A
Oh,
my
goodness
me
like
it
tells
me
a
lot
about
the
vulnerabilities
like
it's
great
but
like
I,
have
no
idea
how
to
fix
a
like
a
log
injection
like
like.
Do
you
have
any
code?
Examples
like
again,
like
the
type
of
data
that
a
developer
needs,
is
different
to
a
security
Persona.
The
developer
really
needs
to
know
how
to
fix
this,
and
also
developers
are
out
there
going.
A
How
many
pages
long
like
how
many
vulnerabilities
like
this
is
going
to
take
me
two
or
three
hours
to
actually
look
through
I
have
a
release
coming
up.
So
what
would
happen?
Is
developers
would
look
through
these
these
PDF
reports
and
they
would
lose
trust
in
them
because
again,
there
was
quite
a
few
thought
like
high
false
positive
rates,
so
developers
would
go
out
there
and
be
like
nope,
so
the
next
time
that
PDF
and
that
security
tool
gave
the
data
the
developers
weren't
taking
it
seriously.
A
So
when
that
one
true
vulnerability
did
come
up,
even
though
you
have
a
great
tool
to
give
you
that
information,
your
developers
weren't
taking
it
seriously
because
it
wasn't
given
to
them
in
a
consumable
way.
So
that's
why,
like
as
we
have
shifted
left,
have
we
thought
about
that
end,
user
experience,
change
between
the
security
Persona
and
the
developer
and
like
this?
Is
data
really
backing
up?
Why
it
hasn't
worked
like
there's
me
standing
here
today
telling
you
this
but
like
here
is
a
data
like,
as
you
can
see,
there's
two
graphs
here.
A
The
bar
graph
shows
you
the
number
of
secrets
that
have
been
like
well
like,
as
you
can
see
over
time.
That's
going
up
well,
like
we've
shifted
left
for
a
while
now,
so
if
it
would
have
worked,
I
would
have
expected
that
to
go
down
and,
like
the
other
graph
shows,
you
vulnerabilities
over
time
that
match
the
lines
of
code.
That
is
also
going
up,
but
wait
like
we
shifted
left
to
fix
these
problems.
A
Why
are
we
here
today
in
this
way
of
working,
and
why
have
we
spent
all
this
time
doing
it
if
it
actually
hasn't
quite
worked?
So
I
think
like
it's
really
interesting
to
take
that
step
back
and
realize
we
had
all
the
right
intentions
and
like
it
made
a
lot
of
sense,
but
it
hasn't
quite
paid
off.
Has
it
and
like
if
we
get
real
for
a
minute
and
I.
Think
like
this
example,
when
this
metaphor
really
brings
it
home,
I
have
a
question
for
you.
A
If
you
went
for
surgery
tomorrow,
would
you
be
happy
if
your
surgeon
was
to
use
tools
that
wasn't
actually
built
for
a
surgeon
think
about
how
that
would
affect
the
outcome?
Would
that
make
it
slower?
How
good
would
that
success
rate
actually
be?
And
the
answer
is
no,
you
wouldn't
be
okay.
You
wouldn't
be
confident
so
why
on
Earth,
are
we
okay
with
giving
developers
tools
that
were
not
meant
for
them
and
thinking
magically
we
are
going
to
have
great
success
rates
and
thinking
magically
things
are
going
to
move
faster.
A
The
answer
is
no
like
it.
Just
wouldn't
I
think
this
analogy
really
brings
in
what
we
are
trying
to
Champion
and
trying
to
push
in
this
presentation
is
around
while
shifting
left
is
great.
Have
we
really
thought
about
the
end
users
that
we've
changed
that
experiences
from
and
that's
why
I
think
this
quote
really
summarizes
it?
Well,
it's
so
important
to
focus
on
creating
these
experiences
for
the
people
who
are
affected
by
that
change.
A
You
want
to
make,
but
it's
so
often
overlooked,
because
them
core
problems
that
we
identified
in
the
first
few
slides
were
the
focus
points
of
what
we
were
trying
to
solve,
and
that
really
takes
me
on
to
my
final
few
slides
and
how
I
really
want
to
bring
this
home.
If
you're
going
to
take
two
things
away
from
this
presentation,
it
is
most
likely
this.
A
Firstly,
the
unexpected
consequences
again
think
about
how
you
have
gone
ahead
and
how
you
have
gone
ahead
and
shifted
left
like
what
are
them
consequences
that
maybe
you
haven't
thought
about
like
when
you
do
add
tolling
and
when
you
do
go
out
there
and
you
do
change
them
experiences
like
it's
really
important
to
think
about
how
you
can
be
developer
first
and
how
you
can
focus
on
them,
develop
her
experience.
Don't
let
the
status
quo
of
today
influence
how
you
think
things
should
be
done
tomorrow
again
go
out.
A
There
speak
to
your
developer
community
and,
like
think
about
how
you
want
to
work
tomorrow
and
like
that,
leads
me
on
to
my
second
point,
which
is
all
around
the
tooling.
Whilst
tooling,
is
not
the
foundation
to
this,
the
tooling
heavily
influences
how
developers
work
so
again,
like
whether
you
are
using
GitHub
today
or
not.
It's
really
really
important.
When
a
company
comes
in
and
says
we
can
help
you
automate
this
like
we
can
make
your
developers
so
much
more
efficient.
You
will
be
able
to
deliver
software
a
hundred
times
quicker.
A
We
will
help
you
shift
left.
It's
really
important
for
you
to
take
that
step
back
and
go
okay,
that's
great,
but
what
do
you
actually
do
to
focus
on
actually
improving
the
developer
experience?
Whilst
we
are
changing
process
like
what
do
you
actually
do
to
be
developer?
First,
these
are
the
questions
that
we
as
the
industry
should
now
be
asking.
Yes,
the
principles
of
shift
left
are
fantastic,
but
it's
really
now
as
important
to
be
asking
questions
about.
How
is
this
going
to
affect
my
developers?
A
Are
they
going
to
have
to
context
switch
between
multiple
tools?
Are
they
actually
going
to
become
more
inefficient
when
I
change
these
things?
So
these
are
the
two
key
sort
of
outcomes.
I
want
you
to
take
away.
Firstly,
the
unexpected
consequences:
let's
maybe
start
to
make
them
more
conscious,
let's
actually
think
about
these
consequences
up
front
and,
secondly,
focus
on
the
tooling
and
make
sure
that
if
you
look
at
your
devops
tool
chain-
and
you
look
at
that
tooling-
and
you
say:
do
you
know
what
like
this
isn't
a
great
experience
for
my
developers?
A
This
is
a
great
ways
to
actually
make
things
more
efficient.
The
people
on
the
ground
can
actually
do
things
quicker
and
quicker
here,
so
it's
really
important
to
focus
on
being
developer
first
and
that
developer
experience
so
to
conclude,
I
actually
want
to
go
back
to
the
beginning.
If
you
remember
I
asked
you
a
question:
is
the
shift
left
phrase
the
correct
term
we
as
the
industry
should
be
advocating
for
and
what
you
almost
likely
thought
was
yes
shift
left
is
the
right
thing
to
do.
I
guess
this
power-up!
A
This
presentation
is
going
to
tell
me
otherwise
and
that's
actually
not
what
I
want
you
to
take
away.
I
want
to
share
with
you
my
answer,
the
principles
behind
shift
left.
They
remain
solid.
All
of
the
problems
we
wanted
to
solve
with
shift
left
which
we
identified
earlier.
They
absolutely
remain
solid,
but
it's
not
enough.
We
need
to
focus
on
that
developer
experience.