►
From YouTube: How the right tools helped EY and Duolingo's developers write code faster and more efficiently
Description
In the world of “do more with less”, it's critical that your development tools don't get in the way. In this panel, we'll talk with James Zabinski, EY Developer Tools Leader, Client Technology at EY and Michael Sobczak, Engineering Manager at Duolingo, to learn how to maximize the efficiency of integrated development environments (IDEs) and tools to write high-quality code. You'll leave this session with a better understanding of how EY and Duolingo's developers produce and deliver solutions to their customers quickly and securely.
Stay up-to-date on all things GitHub by subscribing and following us at:
YouTube: http://bit.ly/subgithub
Blog: https://github.blog
Twitter: https://twitter.com/github
LinkedIn: https://linkedin.com/company/github
Instagram: https://www.instagram.com/github
TikTok: https://www.tiktok.com/@github
Facebook: http://fb.com/github
About GitHub
It’s where over 100 million developers create, share, and ship the best code possible. It’s a place for anyone, from anywhere, to build anything—it’s where the world builds software. https://github.com
A
Hello,
everyone
and
thank
you
for
joining
us
today.
I'm
Virginia,
Bryant
and
I
lead
customer
marketing
at
GitHub,
which
means
I
have
the
incredible
honor
of
working
with
and
learning
from.
Our
customers
today
is
no
exception,
as
I'm
joined
by
James
zabinski
developer
tools
for
client
technology
at
ey
and
Michael
sobzik
engineering
manager
at
Duolingo.
Thank
you
both
for
being
here
during
this
session.
We're
going
to
chat
about
ey
and
Duolingo
are
enabling
their
developers
to
focus
on
writing
and
shipping
high
quality
and
secure
products
and
solutions
instead
of
managing
tooling
and
overhead.
A
Before
we
jump
in
I,
do
want
to
go
over
a
few
housekeeping
items
while
I
have
some
questions
that
I'd
love
to
cover
with
James
and
Michael.
This
session
is
really
meant
to
be
interactive,
so
please
submit
your
questions
in
the
Q.
A
tab
you'll
find
that
in
the
upper
right
of
your
screen,
I'll
ask
some
as
we're
going
along
as
they're.
Relevant
and
I
also
save
a
big
chunk
of
time.
At
the
end.
For
us
to
really
dig
into
those
questions,
questions
we
do
have
chat
moderators
in
the
chat
with
you.
A
If
you
need
any
assistance,
also,
if
you
have
questions
for
the
GitHub
team,
please
don't
hesitate
to
hit
the
request
a
demo
or
schedule
meeting
button
on
the
top
of
your
screen
and
someone
will
get
back
to
you
after
this
session.
Finally,
this
is
being
recorded
and
will
be
available
next
week
on
the
Galaxy
page,
so
the
learning
doesn't
stop.
A
Finally,
at
the
end
of
the
session,
we're
going
to
put
up
a
QR
code,
that'll
Pro
that
will
allow
you
to
scan
it
and
provide
some
feedback,
so
we
can
continue
to
improve.
So
please
consider
taking
a
moment
to
share
your
thoughts
with
us
and
with
that,
let's
dive
in
James
Michael.
Thank
you
again
for
joining
me.
Thank.
B
A
I'd
like
to
begin
by
understanding
the
lay
of
the
land
at
ey
and
Duolingo,
so
it'd
be
great.
If
you
could
each
briefly
tell
us
a
bit
about
your
developer
organization,
you
know
just
kind
of
what
it
looks
like
and
what
tools
you're
leveraging
as
part
of
your
devops
workflow
James.
Would
you
be
willing
to
kick
us
off
sure.
B
So
at
ey
we're
a
fairly
large
company
about
480
000
employees
worldwide
for
developers
we
have
multiple
types
of
developers.
We
have
our
internal
developers
that
build
solutions
for
you
why
we
also
have
a
cons,
client
serving
developers
working
in
our
Consulting
practice,
as
well
as
citizen
developers,
just
people
that
work
around
ey
that
that
build
things
to
help
them
improve
their
own
way
of
life
from
a
tool
perspective
I,
think
it's
important
to
think
in
terms
of
capabilities.
B
Our
goal
is
to
ensure
that
we
have
the
right
tools
to
enable
the
entire
devops
lifecycle.
So
shifting
left
as
much
as
possible
is
key.
Our
goal
is
to
reduce
friction
for
solution
delivery
as
much
as
possible.
If
you
shift
left,
but
you
add
a
heavy
process,
you
can
disrupt
the
natural
flow
of
the
developer,
which
could
lose
any
gains
you
would
have
received
by
introducing
tooling,
potentially
even
making
things
worse.
B
So
we
use
tools
like
Advanced
security,
GitHub
event,
security
depend
about
which
shifts
left
inside
of
the
developer's
natural
flow,
so
it
automatically
scans
there's
nothing
that
they
have
to
do
to
trigger
that
scan
to
happen.
If
it
finds
any
issues,
it
will
automatically
submit
a
pull
request
for
them
to
review,
so
that
very
naturally
follows
the
normal
developer
flow.
It
doesn't
introduce
any
additional
disruptive
processes
and
it
helps
them
to
reduce
friction
and
deliver
a
more
secure
solution.
B
So
we
we
have
other
capabilities
that
we're
enabling
through
tooling,
obviously
we
have
build
and
deploy
automation.
We
have
the
ability
to
trace
from
requirements
to
Value
using
our
Better
Together
strategy
with
Azure
devops
boards
working
with
GitHub
we've
used
infrastructure
as
code.
We
have
continuous
testing
for
the
full
testing
pyramid
with
unit
testing,
API
testing
and
UI
testing.
All
automated
I
think
one
one
of
the
keys
that's
often
overlooked
is
database
devops.
You
know
we
focus
a
lot
on
code
because
it's
easy,
but
database
is
hard
to
do
and
even
harder
to
devops.
B
So
it's
important
to
support
your
developers
with
tools
to
do
that
code.
Quality
is,
is
key.
You
want
to
make
sure
you're
not
developing
bad
code
quickly
and
then
having
security,
testing,
container
security,
testing,
Dynamic
security,
testing,
static
security,
testing
and
also
you
know
we
configuration
management
to
ensure
you're,
not
drifting,
your
either
security
posture
or
your
configuration
of
your
environment.
So
that's
just
an
example
of
things
that
we're
working
on
within
UI.
C
Also
even
things
like
enforcing
development,
best
practices,
you
know
having
within
a
repo
a
single
repo.
We
have
you
know
a
bunch
of
kind
of
standard,
off-the-shelf
tools
you
can
use
to
do
lending
pre-commit
checks
all
of
those
things,
and
once
you
move
to
a
microservice
architecture,
there's
you
know
it's
much
harder
to
kind
of
centralize
and
standardize
on
all
those
best
practices.
C
So
we
use
a
lot
of
the
tools
that
that
James
mentioned
I
mean
we.
We
make
heavy
use
of
CI
CD
pipelines.
You
know
automated
checks
on
pull
requests
and
things
like
that.
We're
also
kind
of
continuously
exploring
solutions
to
harmonize
the
development
of
our
different
micro
services,
but
still
retain
the
benefits
of
kind
of
having
that
development
decentralized.
So
one
tool
we've
been
rolling
out
and
exploring
with
is
platform
Ops
level
that
allows
you
to
check,
applied
checks
and
campaigns.
C
To
you
know
a
bunch
of
different
services
and
assign
them
to
teams
and
kind
of
get
centralized,
looks
another
huge
advancement
in
the
last.
Maybe
half
a
year
or
year
has
been
GitHub
code
spaces.
You
know
one
of
the
problems
that
you
run
into
when
each
kind
of
service
is
its
own
repository
with
its
own
libraries.
Its
own
Tech
stack
is
it's
kind
of
a
big
ask
to
share
service
ownership.
You
know
somebody's
got
their
development
environment
all
set
up
and
ready
to
go
to
get
another
developer
involved.
C
It's
now,
you
know
running
running
a
service
that
you
haven't
touched
before
just
reviewing
or
testing
a
PR
is
now
a
matter
of
a
couple
minutes,
and
then
you
have
a
code
space
up
and
running
with
the
right
version
of
python.
It
ran
the
right,
install
hooks.
It's
got
the
right,
Docker
image
and
you
as
kind
of
a
new
developer
onboarding
to
this
repo.
C
Don't
really
have
to
think
about
any
of
that.
You
know
it
kind
of
just
works
and
provides
a
place
where
we
can
easily
plug
in
kind
of
best
practices
without
asking
too
much
of
developers.
So
like
something
we've
done
in
a
lot
of
our
code,
space
configurations
is
have
copilot
be
installed
by
default
on
that
code,
space
and
that's
been
great
for
getting
people
to
just
try
it.
You
don't
have
to
tell
people
hey,
go
to
this
page
download
this
plugin.
You
know
as
soon
as
they
use
a
code
space.
C
A
Yeah,
that's
really
interesting,
I
mean
it
seems
like
core
themes
for
for
both
of
you
and
thinking
about
how
you're
enabling
your
developers
are
really
around.
You
know
in
giving
people
the
right
tools
and
solutions,
they
need
to
just
focus
on
the
work
and
not
on
all
of
the
overhead
and
the
process
and
the
things
that
need
to
happen
to
make
sure
you
know
the
final
product
is
high
quality
and
you
know
James
you.
A
You
touched
on
sort
of
that
shifting
left
and
and
shifting
security
left
to
really
ensure
that
you
know
the
work.
That's
being
done
is
meeting
all
those
quality
standards
from
the
beginning,
and
then
you
know
with
with
Michael
and
the
code
spaces
you're,
really
like
kind
of
leveling
the
playing
field
to
an
extent
for
folks
who,
as
you
said,
might
be
early
career
or
early
in
their
time
at
Duolingo.
You
don't
have
to
have
as
much
like
organizational
operational
knowledge
to
be
able
to
start
being
successful
and
making
meaningful
contributions.
So
that's
really
interesting.
A
I
guess,
like
I'd
love,
to
understand
a
bit
about
how
devops
and
kind
of
the
the
devops
has
evolved
in
the
way
you're
approaching
it
over
over
time.
So
you
know
is
this:
is
this
something
that's
been
really
front
and
center
in
the
way
that
you've
operated?
For
you
know
many
many
years
now
or
was
there
kind
of
like
a
inflection
point
where
your
team
decided
to
start
making
changes
to
to
Really
optimizing
your
devops
or
tooling
infrastructure
James.
Do
you
want
to
kick
it
us
off
again
sure.
B
So
you
know
I
think
we've
been
for
the
last
15
years,
working
on
standardizing
and
and
managing
a
central
kind
of
approach
to
tooling
I
think
around
2018
was
is
where
we
really
kind
of
focused
and
shifted
to
a
devops
and
a
continuous
integration
and
delivery.
Our
pre
pre.
That
point.
You
know
there
was
a
lot.
B
We
knew
going
much
earlier
than
that
that
that's
something
that
we
were
trying
to
get
to,
but
if
you
think
you
know
for
a
company
like
ey,
where
you
know
we're
very
risk-averse
right.
So
when
you
start
talking
about
Automation
and
you
start
taking
things
that
were
previously
in
the
hands
of
people
that
had
the
the
gates
in
place
to
make
sure
that
things
happen
the
way
they're
supposed
to
in
a
secure
way.
It's
not
always
just
about
the
tooling
of
like
here's,
a
tool
that
can
automatically
deploy
your
your
software.
B
So
it
took
some
time
to
kind
of
change
the
way
people
thought
about
how
what
risk-averse
means
like.
Is
it
actually
risk-averse
to
do
it
manually
or
are
we
introducing
risk
because
we're
doing
it
manually,
you
know?
So
if
you
think
about
you
know,
we
would
have
our
deployment
weekends,
which
you
know.
If
we
had
an
application
that
was
getting
deployed,
we
would
have
to
spend
weeks
documenting
the
step-by-step
process
in
a
Word
document
or
a
PowerPoint
or
a
a
project,
Microsoft
Project
file
with
hundreds
of
steps
of
first.
B
That's
500
times
going
through
those
same
steps
right,
so
it
really
was
becoming
unmanageable.
So
that
helped
kind
of
change.
The
way
that
that
we
were
thinking
about
things,
because
in
that
going
through
hundreds
of
steps
on
500
servers,
one
server,
you
forget
to
run
one
script
in
the
middle,
and
suddenly
you
have
intermittent
issues
with.
Why
does
the
application
seem
to
work
sometimes
and
doesn't
work?
Other
times
and-
and
it
really
helped
to
understand
that
it
wasn't
being
Risk
aversed
by
avoiding
the
automation.
B
So
that's
really
what
the
inflection
point
was
that
we
needed
a
way
that
we
could
do
what
we
were
already
doing.
We
were
already
taking
the
time
to
break
it
down
step
by
step,
but
how
do
we
do
that
in
a
way
that
is,
is
truly
risk-averse
and
can
handle
deploying
to
hundreds
of
servers
and
ensuring
that
all
of
those
Gates
that
people
were
in
charge
of
were
being
still
addressed,
but
using
the
right
and
and
proper
tooling.
A
Yeah,
that's
really
great
context.
I
I
know
we'll
talk
about
this
a
little
bit
more,
but
you
know
the
idea
that
it's
not
just
setting
getting
the
right
Tools
in
place,
but
actually
enacting
the
change
that
goes
around
it
within
a
culture
because,
ultimately,
like
develop,
you
know,
there's
a
people
element,
there's
a
there's,
a
cultural
element
to
making
change
to
how
you
build
collectively
so
that'll
be
something
that
I'd
love
to
talk
more
on
as
we
as
we
continue
to
dig
in
Michael.
What
about
you.
C
So
I
kind
of
touched
that,
on
the
touched
on
that
on
the
the
previous
point,
with
shifting
from
a
monolith
to
microservices
has
been
kind
of
a
huge,
you
know
defining
aspect
of
of
development
over
the
past
years.
You
know
and
another
big
one
is
duolingo's.
Rapid
growth
has
meant
that
many
new
Engineers,
especially
including
new
grads,
so
not
necessarily
people
with
a
ton
of
you
know
previous
industry.
Experience
need
to
be
onboarded
quickly
effectively
and
be
able
to
start
contributing.
You
know,
Duolingo
doesn't
have
a
ton
of
employees.
C
Shipping
things
quickly
and
urgently
is
you
know
a
really
heavy
operating
principle
and
part
of
the
culture
and
something
we
all
take
very
seriously,
and
you
know
I
for
a
personal
experience
with
this.
Had
a
new
hire
joined,
my
team,
maybe
a
month
or
so
back
and
like
anyone
with
engineering
experience
going
to
a
new
job,
pre-code
space
that
was
usually
a
day
or
two
process
to
set
up
your
laptop
run,
the
you
know,
maybe
more
or
less
half-baked
automation,
scripts
that
were
there
discover
problems
with
them.
C
That
would
be
your
first
issue
of
fixing
the
existing
problems
with
the
install
guide
or
updating
docs,
and
then
you
know,
maybe
after
a
couple
days,
you'd
have
like
a
functional
environment
and
when
brought
on
and
onboarded
a
new
member
to
the
team,
you
know
showed
him.
Here's
how
you
set
up
the
code
spaces,
the
the
repositories
he
was
working
on
were
already
configured,
and
you
know.
Within
a
half
hour
he
had
a
working
environment
that
he
was
able
to
just
run.
C
C
You
know
quite
right
the
first
time,
and
so
you
know
having
that
ability
to
just
onboard
people
and
get
them
working
really
fast.
You
know,
within
less
than
an
hour,
has
been
huge
game.
Changer
I
mean
I
I
kind
of
hadn't,
experienced
anything
like
that
in
terms
of
how
the
onboarding
process
went
from
super
painful
to
basically
trivial
or
not
really
part
of
the
you
know
per
person's
first
week
plan
because
it
kind
of
just
just
happens
when
they
click
the
button.
B
Quick
yeah,
if
I,
can
jump
on
to
what
you're
saying
there
I
think
the
other
thing
you
know,
I,
don't
know
if
you
you
experienced
this
Mike,
but
you
know
when
we
have
not
just
onboarding
new
to
the
company,
but
we
have
developers
that
may
be
working
on
one
product
and
then
they
shift
to
working
on
another
product
and
then
there's
a
whole
ramp
up
period
of
well.
These
are
the
tools
and
the
configuration
that
we
used
on
the
product
that
was
before.
B
Oh
this
other
product
doesn't
use
those
same
things
or
the
same
configuration,
and
so
you
know
that
transition
from
one
team
to
the
other
can
sometimes
take
weeks
and
add
the
friction
of
getting
the
the
new
configuration
for
laptop,
so
code
space.
You
know
you
just
jump
into
the
repo
and
push
a
button
and
then
you're
up
and
running
so.
C
Yeah
and
it's
it's
been
I
mean
it's
now.
You
know
leaned
in
heavily
to
code
spaces,
and
you
know,
there's
now
been
probably
six
or
seven
different
services
or
repositories
that
I've,
like
reviewed,
PR's,
run
codon
and
the
the
code
has
never
even
been
cloned
to.
My
laptop,
you
know,
was
able
to
all
be
done
kind
of
on
the
cloud,
and
you
know
like
I
was
saying
with
wanting
to
Push
Service
ownership
and
how
that
can
be
difficult
in
a
micro
service
environment,
it's
so
great
to
drop
that
hurdle
where
people
aren't
thinking.
C
A
C
So
I
mean
we've
seen
so
you
know,
code
spaces
are
still
pretty
new.
It's
not
like
you
know
everyone
at
duolingos,
only
running
on
code
spaces
or
anything
like
that
and
I
think
you
know
I
think
a
good
approach
to
take
with
something
like
that.
Is
you
know
if
you
like
your
current
workflow,
you
can
keep
your
current
workflow.
You
know
a
lot
of
the
people
that
have
been
here
since,
before
code
spaces
rolled
out,
they've
they've
got
something
on
their
laptop.
You
know,
they've
got
an
environment,
they
know
what
to
do.
C
We've
really
seen
like
where
a
big
uptick
happens
is
when
they're
kind
of
faced
with
what
we're
talking
about
of
okay.
You
need
to
go
contribute
to
this
other
project
or
shift
teams,
and
they
kind
of
think
to
themselves
of
you
know,
am
I
really
gonna
have
to
go
through
this
whole
setup
and
everything,
and
that
that's
often
where
you
really
see
people
kind
of
at
least
try
out
code
spaces,
because
you
know
they
can
avoid
that
pain
Point.
C
C
So
it's
currently
a
hybrid
approach.
I
mean
it's
a
lot
of
the
stuff
we've
done
over.
Maybe
the
past
six
months
has
been
the
people
that
are
kind
of
champions
of
code
spaces.
You
know
myself
being
one
and
others
at
Duolingo
have
done
a
little
bit
of
the
maybe
leg
work
to
show:
hey
here's
how
you
can
just
configure
this
Json
file
that
lives
in
your
repo
and
here's,
how
you
set
up
things
with
codespace
or
helping
other
teams.
You
know
I
have
randomly.
C
You
know
worked
with
one
of
the
data
science
teams
to
help
them
set
up
one
of
their
code,
spaces
to
have
the
right
credentials
or
libraries,
and
you
know
kind
of
help
to
push
it
Forward,
because
you
know
all
of
these.
The
users
are
developers.
So
a
lot
of
it
is
just
you
know,
showing
them
that
initial
example
or
hey
here's.
C
What
it
looks
like
it's
really,
not
that
bad
and
then
once
that's
done
a
lot
of
stuff
is
just
kind
of
people,
see
the
value
of
it
and
then
they're
able
to
kind
of
be
Off
to
the
Races
on
their
own.
So
you
know
having
kind
of
champions
of
the
service
to
get
it
off.
The
ground
is
good,
but
you
know
what
we've
seen
like
with.
C
If
you
do
have
a
good
product
that
is
really
actually
enhancing
productivity
and
making
the
developer
experience
easier,
you
know
it
doesn't
take
a
massive
push
or
some
kind
of
like
imposition
from
the
top
down.
A
lot
of
it
is
just
enabling
people
to
see
the
benefits.
Try
them
out
in
a
way
that
doesn't
cost
them
a
ton
of
time
or
resources,
and
then
you
know
let
let
them
kind
of
build
off
from
there.
A
Absolutely
so
you
know,
as
more
and
more
organizations
are,
are
sort
of
becoming
tech
companies.
You
know
from
grocery
chains
that
are
now
viewing
themselves
as
technology
organizations,
or
you
know,
we've
spoken
with
Autumn
Automotive
manufacturers
who
are
referencing
that
the
cars
are
more
software
than
Hardware
these
days.
A
You
know
how?
How
are
you
thinking,
I
guess
through
either
you
know
being
able
to
address
the
fact
that
there
really
is
still
a
shortage
of
developer
talent
in
this
space?
You
know
there's
more
and
more
demand,
and
there
are
not
you
know,
necessarily
graduates
that
are
coming
out
in
a
in
such
a
high
volume
to
meet
that
demand.
So
how
do
you
think
about
kind
of
through
the
lens
of
productivity
and
the
the
current
economic
climate
and
all
the
innovations
that
are
happening
around
things
like
AI?
A
C
So
I
mean
Duolingo
is
a
tech
company
that
produces
software.
As
you
know,
the
primary
thing
so
can't
really
speak
to
to
that
aspect.
James
will
probably
be
better
on
that
one,
but
you
know
still
faced
by
Duolingo
of
relatively
small
company.
Like
I
mentioned,
you
know
hundreds
of
Engineers,
but
millions
and
millions
of
daily
users-
and
you
know
lots
of
things-
we're
exploring
and
trying
to
support
so
developer.
Productivity
is
at
least
you
know.
C
Developer
productivity
is
one
of
the
places
where
a
company
like
Duolingo
can
have
an
extremely
high
amount
of
Leverage,
and
you
know,
like
we
mentioned
with
code
spaces
or
code
Pilots.
Any
of
these
tools
that
make
developers
even
a
bit
more
productive
is
huge
value
for
the
organization.
An
organization
like
Duolingo,
where
you
know
the
software
kind
of
is
the
product
yeah.
B
Yeah
so
I
guess
for
me,
you
know
I
think
from
a
you
know,
continue
to
invest
perspective,
I
think
if
you're,
not
moving
forward
in
technology,
you're
falling
behind
so
I
think
it's
critical
to
always
be
looking
at
what
you
know.
What
is
the
next
thing
you
know
knowing
code
spaces
is
coming
and
how
that
can
improve
developer
productivity,
knowing
copilot
is,
is
coming
and
how
that
can
improve
productivity.
So
I
think
it's
always
important
for
somebody
in
my
position
to
be
always
understanding.
B
What's
what's
on
the
horizon,
so
that
we're
we're
not
falling
behind.
You
know
if
you,
if
you
wait
until
after
it's
it's
that
already,
the
the
the
solid
thing
then
you're
already
behind
the
eight
ball
and
having
and
always
playing
catch-up,
I
think
the
impact
that
we've
seen
you
know,
I
think
I
talked
before
about
are
deployment
weekends,
where
we
would
spend
two
days
doing
a
deployment
today.
Our
award-winning
devops
practice
runs
over
7
000
pipelines
per
day
for
devops.
B
So
from
a
impact
perspective,
if
you
just
look
at
it
in
straight
man,
hours
right,
7,
000
pipelines-
let's
say
you
say
one
pipeline
saved
on
average
one
man
hour,
that's
a
pretty
conservative
effort.
You
know
amount
of
effort.
You
would
think
for
what
a
pipeline
might
do
right
so
one-man
hour.
7
000
pipelines
means
that
we
would
be
doing
875
man
days
of
work
per
day.
That's
over
two
years,
two
man
years
of
work
every
day.
B
If
you
look
at
that
from
a
just
from
an
infrastructure
as
code
perspective,
we
build
our
infrastructure
of
code
infrastructure
as
code
templates
with
security,
reviewing
them
and
certifying
that
those
configurations
are
secure.
So
just
think
about
the
time
that
you
would
save
reusing
those
templates
at
that
scale
now
think
about
the
effort.
B
It
would
take
to
secure
that
many
ad
hoc
configurations
or
Not
only
would
we
be
saving
the
time
but
think
about
the
security
posture,
the
the
confidence
that
we
can
have
now
that
our
environment
is
secure,
because
we
know
that
what
we're
deploying
and
how
we're
deploying
it
is
secure.
What
about
testing,
if
you
think
about
the
effort
involved
in
testing
that
many
solutions?
B
What
if
you
were
doing
that
manually
like
how
many
tests
would
somebody
have
to
be
going
through,
just
to
make
sure
that
the
applications
were
or
each
feature
is
doing
what
it's
supposed
to
do
right,
not
only
the
time
but
think
about
the
quality?
You
know
you
have
different
people
doing
the
tests.
Are
they
doing
them
the
same
way?
Are
they
getting
the
same
results?
Is
it
validating
what
you
expect
it
to
be
validating?
B
So
what
would
the
quality
be
like
if
you
weren't
using
tools?
If
you
look
at
speaking
of
quality,
if
you
just
look
at
code
quality,
how
do
you
even
measure
code
quality
without
a
tool
whether
you
have
somebody
going
through
every
line
by
line
and
say?
Oh
no.
This
isn't
a
good
way
to
do
that
type
of
function,
but
you
know
there's
no,
there's
no
way
to
realistically
look
at
code
quality
before
tooling.
The
way
we
measured
quality
was
bucks
right.
B
How
many
bugs
did
this
have,
but
bugs
don't
measure
quality
they
measure
functionality.
You
could
have
zero
bugs
because
it
does
exactly
what
it's
supposed
to
do,
but
it
fails
every
10
minutes
because
the
code
was
written
terribly
right.
So
you
need
a
way
to
know
whether
the
code
was
written.
Well,
we
scan
and
analyze
regularly
over
27
27
million
lines
of
code.
So
you
can
imagine
what
that
would
be
like
without
tooling
application
security.
B
Imagine
the
effort
that
you'd
have
to
go
through
to
manually
review
that
many
applications
what
it
and
what
are
they
checking
for?
How
are
they
checking
and
what
kinds
of
recommendations
are
they
making?
How
would
you
even
certify
that
many
deployments
or
what
would
that
do
to
impact
our
security
posture
so
of
all
of
those
things,
I
think
the
biggest
measure
for
impact
is
time
to
Value
right.
B
So
what's
the
potential
Revenue
loss,
if
we
can't
get
the
feature
or
the
product
out
the
door,
how
do
we
win
the
business
if
we
don't
have
the
tooling
the
thing
that
we're
trying
to
to
deliver
doesn't
exist?
If
it's
stuck
behind
a
Security
review
or
a
security
failure
or
a
or
a
you
know,
we
couldn't
get
the
infrastructure
built
in
time.
In
my
opinion,
you
really
can't
afford
not
to
do
devops
in
this
day
and
age.
B
Both
we
have
a
central
devops
practice,
so
we
consistently
Implement
devops
across
all
of
the
teams,
but
those
devops
practitioners
are
embedded
into
the
product
teams
because
they
have
to
be
part
of
the
team
that
they're.
You
know
it
doesn't
make
sense
to
have
somebody
fly
in
to
try
to
figure
out
hey
what
are
we
making
today
and
how
do
we
get
it
deployed?
They
need
to
understand
what
what
it
is
that
the
team
is
delivering,
but
they
also
need
to
understand
the
best
practices
of
how
we
do
devops
and
ey.
A
One
of
the
things
that
I
find
really
interesting,
I
mean
and
James.
You
made
a
incredibly
compelling
case
for
the
importance
of
devops
and,
as
you
can
see,
you
know
in
the
audience
the
the
bigger
the
scale
the
more
critical
these
are.
You
know
the
things
that
you
can
kind
of
patch
together
when
you're
working
with
a
team
of
25
or
50
developers
don't
work.
A
When
suddenly
you
know
you
have
gigantic
organizations
and
there's
a
lot
of
productivity
loss
and
there's
a
lot
of
you
know
inherent
risk
in
that
too,
because
you're,
you
aren't
able
to
monitor
for
code
quality
and
for
security,
vulnerabilities
and
things
that
can
make
it
to
production.
When
you
don't
have
these
really
regimented
checks
and
processes,
and
so
you
know
by
putting
that
all
left
and
having
that
be
part
of
the
developer,
workflow
you're,
also
removing
that
kind
of
moment
of
friction
that
often
happens
between
developer
organizations
and
security.
A
So
there's
all
of
these
real,
tangible
benefits
of
just
having
this
great
tooling,
and
these
best
practices
for
building
software
up
front,
but
I
think
the
thing
I
I
came
up
with
most
from
what
you
were
saying:
James
and
I'd
love
to
hear
Michael
if
you've
seen
this
within
Duolingo
as
well.
But
it
sounds
like
just
the
total
amount
of
stuff,
like
the
total
amount
of
new
code
and
new
customer
experiences
and
product
experiences
that
you
were
ultimately
able
to
deliver
to
your
end.
A
B
You
know
that
the
it
was
it
was
very
difficult
to
get
features
released.
So
I
think
you
know
now
the
the
teams
are
able
to
focus
on
value
and
and
how
they
can
deliver
that
value
as
quickly
as
possible.
We
do
make
an
effort
to
make
time
available
for
Innovation
so
that
we
can
take
some
of
the
the
time
that's
been
saved
by
introducing
all
of
these
tooling
and
give
it
back
to
the
developers
so
that
they
can
spend
time
working
on.
You
know
how
can
I
improve?
You
know
our
lives
as
developers.
B
How
can
I
improve
the
product
or
you
know,
do
those
kinds
of
things
so
I
think
it's
important
I,
don't
think
it'll
happen.
Naturally,
if
you
just
save
the
time
and
continually
add
features
to
the
backlog,
then
the
developers
will
do
the
features
that
are
on
the
backlog
and
they're
not
necessarily
going
to
make
their
own
space
to
work
on
Innovation.
So
I
think
it's
important
as
Leaders
to
recognize
that
you
have
saved
this
time
and
how
are
you
going
to
invest
that
back
into
making
things
continually
improve?
C
I
I
thought
it
was
interesting
too.
The
part
you
said
about
having
the
devops
people
embedded
on
the
team,
so
I
think
Duolingo
hits
a
pretty
good
balance
of
providing
centralized
teams
that
are
sort
of
experts
in
the
domain,
so,
whether
that's
infrastructure
as
code
or
developer
infrastructure,
or
you
know,
Jenkins
or
anything
like
that,
and
are
able
to
provide
tools
that
then
developers
can
really
use
in
a
kind
of
self-service
fashion
for
the
most
part.
C
C
If
you
happen
to
do
something
on
your
project
that
is
generally
applicable,
they're
sort
of
already
an
established
path
to
integrate
that
back
into
these
centralized
areas
where
the
rest
of
the
organization
or
other
teams
you
know
or
future
Services
can
benefit
from
this.
So
having
that
kind
of
feedback
loop
and
having
a
good
balance
of
centralization
to
provide
expertise
but
decentralization
to
give
developers,
flexibility,
so
they're,
not
constantly
being
frustrated
or
slowed
down,
is,
has
worked
pretty
well.
C
I
know
for
me
personally,
when
copilot
came
out,
or
just
even
any
of
the
GPT
based
tools.
Oftentimes
the
Articles
you
would
read
or
or
press
releases
will
show
what
are
maybe
for
lack
of
a
better
word,
almost
like
magic
tricks
like
just
with
one
line,
it'll
Implement,
like
a
neural
network.
You
know
gradient
descent
algorithm
that
you
wouldn't
even
know
how
to
do,
and
that's
amazing
I
mean
that
is
extremely
impressive.
But
that's
you
know
where
I
see
the
value
in
co-pilot
and
from
people
who
have
started
using.
C
C
You
know
all
throughout
the
day,
all
throughout
the
code
and
it's
hard
to
really
articulate
that
to
somebody
that
that
hasn't
really
tried
it
because
I
think
a
lot
of
people
who
maybe
haven't
tried
it
yet
are
on
the
fence
are
thinking
well,
how
often
do
I
need
to
automatically
generate
like
complex
algorithms-
and
you
know-
sometimes
they
can't
do
that
I
mean
co-pilot
will
still
surprise
me
sometimes
on
how
much
it's
able
to
do.
But
it's
really
something
where
you
know
getting
in
the
hands
of
developers
and
see.
C
Oh
I
would
have
had
to
go.
Look
up
the
docs
for
the
syntax
on
bash
shift
statements,
because
I
only
write
one
bash
script
a
year
and
I,
never
remember
the
syntax.
That
would
have
been
20
seconds
to
Google,
find
some
examples,
but
now
that's
instant
and
you
know
not
a
huge
saving
there,
but
it's
those
wins
kind
of
just
come
rolling
in
Non-Stop,
so
the
effort
has
just
really
been
get
developers
to
try
it.
C
You
know
once
I'm
kind
of
convinced
that
once
people
try,
it
they'll
see
the
value
of
it,
and
so
the
real
push
has
just
been
make
it.
So
it's
enabled
automatically
here
developers
know
where
they
can
get
it.
They
can.
You
know
we
have
slack
channels
where
people
can
share
cool
things,
that
they
were
able
to
do
with
copilot
and
kind
of
just
lessen
that
barrier
to
just
trying
it
out
and
seeing
that
is
really
the
way
to
you
know:
push
adoption
yeah.
A
Great
way
to
to
get
people
to
try
new
things,
I
do
think
that
something
that
I
found
really
interesting
in
what
you
said
is
you
know?
Not
only
is
it
is
it
those
little
moments
that
it
can
kind
of
help
complete
something
that
you
would
you
would
you
know
how
to
write
you
can
write,
but
just
that
little
Time
Savings,
but
you
know
those
places.
I
think,
there's
a
great
point
about
what
you
said
about.
A
That's
theoretically
20
seconds
to
find
can
actually
be
a
massive
loss
of
flow
and
productivity.
So
I
think
that's
probably
one
of
the
most
exciting
things
to
me
about
copilot
is
really
keeping
you
in
this
in
that
state
you're
like
you're,
not
breaking
flow
you're,
not
screen
bouncing,
and
you
can
actually
like
invent
instead
of
doing
the
the
Rope
kind
of
syntax
or
framework
stuff
that
you
need
to
do
as
a
developer,
so
really
cool
thanks
for
sharing.
A
C
C
I
I
mean
it's
hard
to
say
it's.
It's
just
and
that's
I
think
one
of
the
reasons
why
you
know
people
need
to
try
it
because
it's
hard
to
even
point
to
some
dramatic
time
where
it
saved
me
like
seven
hours,
it's
more
just
like
all
these
tasks
that
would
have
taken
five
minutes
and
I'll
take
20
seconds,
so
yeah
I
mean
I,
definitely
feel
way
more
productive
with
it
and,
like
you
mentioned
too,
not
just
getting
distracted
with
slack,
you
know
breaking
that
flow
of
going
out
of
the
IDE
you're,
not
writing.
C
Code
anymore.
You
know,
part
of
whatever
context
was
in
your
head:
Slips
Away!
You
got
to
reload
it
so
I
mean
I,
don't
know
what
to
attach
as
a
percentage
to
it.
You
know
maybe
40
or
something,
but
it
feels
like
just
an
indispensable
tool.
I
mean
it's
kind
of
hard
for
me
to
imagine
not
using
something
like
this.
Now
that
I've
had
I,
don't
know
six
or
so
months
of
kind
of
experience
with
it.
A
C
And
something
too
that's
been
really
cool
to
see
is
enabling
people
that
maybe
have
some
technical
experience,
but
not
wouldn't
be
comfortable
writing
an
application
from
scratch.
I
mean
there
are
non-developers
now
utilizing
these
tools
to
write
bash
scripts,
where
they
wouldn't
have
done
that
without
copilot.
They
would
have
done
it
manually
or
something
like
that,
or
you
know,
people
that
aren't
even
Engineers
using
GPT
or
copilot
to
generate
SQL
queries,
so
they
don't
have
to
go
bother
a
data
scientist
to
run
whatever
report
they're.
C
A
That's
great
I
can't
wait
to
see
where
you
go
from
here
sounds
like
four
I
mean
I,
wouldn't
complain
about
being
40
faster
at
my
job,
so
I
wanna
head
to
questions
from
the
community
pretty
shortly
here,
but
before
I
I
would
love
to
just
ask
I.
Guess
one
one
more
question
around
this,
which
is
you
know,
putting
the
best
tools
or
the
best
processes
into
the
hands
of
your
developers
is
really
only
half
the
battle.
A
So
how
do
you
think
about
really
helping
to
to
educate
people
to
helping
to
drive
adoption
to
helping
to
make
you
know,
tool,
changes
and
process
changes
as
simple
and
frictionless
as
possible
for
your
employees
so
that
they
can
stay
focused
on
on
building
Innovation,
instead
of
all
the
other
work
that
can
bog
down
a
developer
James?
Why
don't
we
start
with
you
on
this
one.
B
Sure
I
mean
I,
think
that's
a
great
question
and
I
think
you
know
it
starts
with
having
having
your
your
developer
tools,
your
devops
tools,
kind
of
first
class
in
your
organization.
You
know
I,
think
for
for
ey
we
make
developer
tools,
First
Class
part
of
our
ey
fabric
platform,
to
to
really
make
it
so
that
it's
it's
it's
just
part
of
part
of
how
you
do
business
right.
B
So,
if
you
think
about
you
know,
if
you
were
a
world-class
developer,
not
not
co-developer
but
like
building
developer,
you
wouldn't
just
expect
people
to
show
up
at
your
job
site
with
you
know
the
hammer
that
they
borrowed
from
their
neighbor
right.
You
want
them
to
be
using
the
right
tools
to
build
to
build
world-class.
You
know
buildings
right,
so
you
wouldn't
you
wouldn't
do
that
in
in
the
in
the
building
world.
You
shouldn't
do
that
in
the
development
world.
B
The
other
thing,
though,
is
it
doesn't
where
the
difference
between,
like
a
hammer
or
a
a
nail
gun,
you
could
give
a
nail
gun
to
to
an
inexperienced
Builder
and
they
could
build
and
experience
things
faster,
but
a
lot
of
the
tools
in
this
space
really
help
to
improve.
So
if
you
don't
have
the
experience
they
can
help,
you
get
do
a
better
job,
a
lot
to
make
sure
that
the
thing
that
you're
building
is
going
to
pass
code.
B
You
know
we
talk
about,
you,
know,
shifting
left
security
or
compliance
or
things
like
that,
but
really
the
tools
enable
the
the
developer
to
to
do
their
job.
Better
I
think
the
other
thing
to
think
about
is
I.
Think
there's
a
best
in
breed
fallacy
with
tooling,
where
you,
when
you
go
into
the
space
you
look
at
okay.
Well,
this
is
the
best
tool
for
x
and
this
is
the
best
tool
for
y
and
you
just
throw
them
all
together
into
a
big
toolbox
and
they
don't
fit
together.
B
You
have
you
know
you
have
you
know
Legos
and
Duplo,
and
they
don't
fit
right.
So
your
toolbox
ends
up
being
disruptive
to
the
people
that
are
trying
to
use
it.
So
I
think
in
order
to
have
developers
that
really
kind
of
want
to
use
what
you're
offering
you
need
to
think
about
it
as
a
developer
would
and
have
an
ecosystem
that
these
are
tools
that
work
well
together.
So
they
make
my
life
easier
right.
B
If,
if
you're
giving
me
tools
that
I
have
to
change
context
in
order
to
use
this
other
tool,
then
I'm
not
going
to
want
to
do
that,
because
I
want
to
stay
in
the
headspace.
That
I'm
in
I
want
the
tools
that
are
going
to
work
together.
So
I
think,
even
though
we're
talking
about
how
do
you
change
the
culture,
I
think
it's?
It
really
starts
with
making
sure
you're
selecting
the
tools
that
work
well
and
well
in
the
context
of
the
developer
and
your
organization.
B
I
think
the
other
thing
that's
critical
is
listening
to
your
developers
right,
they
didn't
start
developing
when
they
walk
through
the
door.
They
likely
have
been
developing
for
quite
a
while
and
that's
why
you
hired
them
to
work
for
you
as
developers,
so
they
probably
know
what
tools
they
like
to
use
and
why
they
like
to
use
them
or
what
things
they've
had
trouble
with
in
the
past.
That
they'd
like
to
to
not
have
trouble
with
so
talking
to
your
teams
to
understand
what
are
the
problems
that
you're
facing
when
you're
doing
development?
B
B
B
You
know
the
the
the
saying
a
rising
tide
lifts
all
boats,
but
only
if
you're
in
the
same
ocean
right,
if
you
have
everybody,
that's
in
you
know
you're
in
an
ocean
you're
in
a
lake
he's
in
a
pond
right,
then
you
introduce
a
new
capability
like
copilot
or
Advanced
security
or
actions,
or
something
like
that,
and
it
only
affects
the
people
that
are
in
that
body
of
water
and
the
rest
of
the
organization
doesn't
get
any
benefit
from
from
those
tools.
You
know
I
think
when
we
launched
Advanced
security.
B
We
didn't
have
to
do
a
big
effort
to
get
everybody
on
board
right.
Everybody
already
is
using
GitHub
and
so
by
turning
on
event,
security
automatically
proactively.
It's
scanning
for
vulnerabilities
in
your
open
source
code
that
you
have
it's
automatically
scanning
for
secrets
that
you've
inadvertently
exposed
in
your
code,
and
that
happens
for
just
because
you're
in
the
environment.
You
didn't
have
to
take
an
extra
step
to
do
that.
We
just
launched
GitHub
actions.
B
All
of
that
just
comes
with
you
know:
you're
in
the
game,
you
get
the
you
get
all
of
the
toys
that
the
rest
of
us
are
already
getting.
So
really
I.
Think
that's
where
the
key
is.
You
know,
if
you
have
everything
kind
of
you
treat
it
as
a
strategic
part
of
your
of
your
organization,
and
you
put
intentional
thought
into
what
should
we
be
using
and
why
and
you're
making
sure
you're
listening
to
the
developer
so
you're
addressing
their
concerns,
then
the
rest
just
comes
with
it.
C
That
before
we
go
to
questions,
yeah
I'll
make
it
quick.
I
want
to
Echo
a
lot
of
the
things.
James
said:
I
mean
I,
think
Sympathy
for
the
developers
or
empathy
for
the
developers
is
really
important,
and
you
know
if
you
have
some
tool
as
manager
or
devops
person,
that
you
think
is
a
huge
deal,
huge
win
and
you're,
not
seeing
any
adoption
by
developers.
You
know
first
off
maybe
question
you
know:
they're,
probably
not
avoiding
adoption,
just
to
be
difficult,
so
maybe
reevaluate.
C
If
it's
actually
the
big
win,
you
think,
or
maybe
there
were
things
you're
missing
and
you
know
I
want
to
Echo
what
James
said
too.
You
know
Developers.
If
provided
with
a
tool,
that's
genuinely
helpful,
you
don't
need
to
impose
it.
I
mean
they'll,
they'll
use
it
like.
If
Ides
just
came
out
and
they
were
using
notepad,
you
wouldn't
have
to
impose
that
it
would
they
would
adopt
it.
C
And
you
know
a
big
part
of
it
is
understanding
what
the
actual
pain
points
are
and
lowering
the
barriers
as
much
as
possible.
You
know
if
it's
an
actually
good
tool
you
make
sure
people
are
educated
on
it,
it's
as
easy
as
possible
to
access
it.
Then
the
rest
should
kind
of
be
letting
the
product
speak
for
itself.
You
know
or
letting
the
tool
speak
for
itself.
A
That's
great:
well,
let's
go
to
some
of
the
questions
from
our
audience
and
thank
you
all
for
dropping
those
in
throughout
the
conversation.
I
love
this
one.
How
do
you
communicate
the
business
case
around
budget
increase
that
a
code
space
environment
creates
compared
to
local
development,
so
Michael
I
think
that
one's
probably
for
you.
C
If
my
work
laptop
got
stolen
and
hacked
right
now,
none
of
Duolingo
source
code
would
be
at
risk
right.
They
wouldn't
have
my
GitHub
two-factor
authentication.
They
wouldn't
be
able
to
connect
to
any
of
my
code.
Spaces
and
I
know
that's
a
big
deal
for
you
know
people
at
the
organization,
so
yeah
I
mean
it's
it.
Depending
on
your
your
use
case
or
situation,
it
could
be
a
tough
sell
but
I
think
it's.
You
know
one
of
those
things
where
it's
not
just
an
extra
cost.
C
B
B
I
think
the
other
thing
and
I
you
didn't
touch
on
it.
Maybe
it's
not
as
much
of
an
issue
for
you,
but
you
know
when
you,
you
have
to
think
about
develop
like
the
the
laptop
itself
right,
if
you're
developing
locally
generally
developers
need
a
more
powerful
laptop
right,
so
I
think
part
of
the
the
business
case.
B
If
you
can
drive
the
adoption
of
of
code
spaces
is
that
you
don't
necessarily
need
the
super
powered
laptops
and
how
you
decide
on
what
a
developer
laptop
is
because
it
becomes
less
of
the
machine
that
you
need
the
power
on
where
you
can
build
the
power
into
the
cloud
where
it's
it's
easier
to
get
the
power
when
you
need
it.
The
other
thing
code
spaces
does
a
really
nice
job,
I,
think
of
metering
itself.
So
if
you're
not
actively
using
it,
it
will
go
to
sleep.
B
So
you
know,
unlike
a
VM
where
you
might
be
thinking
of
you,
know
a
virtual
desktop
or
something
like
that,
where
or
where
and
equating
that
to
code
spaces.
It's
not
the
same.
If
you're
not
actively
using
your
code
space,
it
doesn't
cost
the
money.
It
will
recognize
that
you're
not
using
it
right
now
and
it
will
go
to
sleep
so
you're
only
paying
for
the
minutes
that
you're
actually
actively
using
it
for
development,
give
or
take
15
or
30
minutes.
I
forget
what
the
timeout
is.
A
C
Yeah,
well
so
don't
necessarily
have
experience
in
working
in
those
environments,
but
I
think
it
touches
on
a
important
kind
of
point
of
using
copilot
as
a
tool
or
using
any
generative
AI
as
a
tool
where
you
want
to
be
careful
to
you
know
having
co-pilot
write
some
code
for
you
and
then
you
ship
it
and
then
later
you
realize
their
security.
Vulnerability
is
sort
of
like
the
nightmare
scenario,
where
this
tool
actually
contributed
negatively
and
I.
C
C
You
know
domain
kind
of
functions
that
you're
more
likely
to
be
correct
and
another
huge
part
of
it
is
you
know,
having
testing
so
assuming
you
have
kind
of
reasonable
test
coverage
of
your
system
and
how
it's
supposed
to
work
and
what
the
specs
are
that
should
catch
when
just
in
the
same
way
that
it
catches
when
a
human
developer
creates
bad
code,
which
you
know.
So
it's
not
like
bad
code
being
generated
is
somehow
unique
to
co-pilot
right.
C
It
can
definitely
happen
because
maybe
you're
not
reading
the
outputs
but
like
any
bad
code
catching
you
know,
a
huge
part
of
it
is
knowing
ahead
of
time
what
your
inputs
and
outputs
should
be
having
test
coverage
for
that.
But
it's
definitely
something
that
yeah
you
have
to
get
used
to
with
co-pilot
and
try
to
kind
of
mitigate
that
by
narrowing
each
snippet
as
much
as
possible.
C
You
know
if
you're,
using
copilot,
to
complete
three
lines
of
code
that
is
much
easier
to
kind
of
verify
than
if
you're
having
copilot
generate
a
40
line
function
for
you.
You
know
but
I
think
the
main
solution,
because
it's
not
realistic
to
read
every
line,
that's
being
output
by
it
is
going
to
have
to
be
some
kind
of
testing
or
specs.
You
know
that
you're
able
to
kind
of
make
sure
it's
good
against.
B
Yeah
I'll
say
honestly:
we
we
because
of
the
you
know
potential
implications
of
using
AI,
that's
one
of
the
the
barriers
to
entry
for
a
company
like
ours.
So
it's
definitely
something
that
requires
the
right
people
with
the
right
skills
to
look
at.
You
know
from
a
legal
perspective
from
a
security
perspective.
You
know
it's
not
not.
The
individual
use
of
this
particular
I
used
it
to
evaluate
this
code.
But
what
is
the
impact
if
I
turn
on
copilot?
B
A
Great
I
think
we
are
down
to
probably
only
having
time
for
one
or
two
more
questions
James.
This
one
is
for
you
I'd
love
to
hear
more
about
the
Azure
pipelines
versus
GitHub
action
story,
I
see
more
future
proof
and
GitHub
actions,
but
I'm
in
the
early
stages
of
using
Azure
pipelines,
and
then
someone
else
asks
how
the
switch
was
going.
So
can
you
tell
us
a
little
bit
about
that.
B
You
know
I
think
when
I
talked
earlier
about
ecosystem
GitHub
and
Azure
devops
work
very
well
together
right,
but
GitHub
works
better
with
itself
than
any
other
external
tool,
including
Azure
devops.
So
you
know
when
you
look
at
things
like
like
Advanced
security
code,
ql
or
or
gating,
or
required
Branch
protection
policies.
Github
works
much
better
with
GitHub
actions
than
it
does
with
any
external
tool.
There's
ways
to
make
it
work,
so
you
can
get
the
same
capabilities,
but
it
will
work
much
better
with
itself.
B
We've
also
noticed
that
it's
much
more
flexible
in
terms
of
if
you're,
if
you're,
building
your
own
kind
of
shared
or
reusable
components
for
your
actions
for
your
workflows,
there's
much
more
like
if
you,
if
you
dig
in
behind
the
under
the
hood
of
what
you
can
include
in
your
output
of
your
pipelines,
it's
very
robust.
You
know,
I
think
you
know.
B
Github
could
do
better
with
their
own
examples
of
how
to
use
some
of
those
features,
because
it
seemed
at
first
glance
to
not
be
as
robust
as
Azure
pipelines,
but
as
we
dug
in,
we
found
that
it
actually
was
much
more
robust
than
what
we
could
do
with
actual
pipelines.
So
we're
at
the
we're
at
the
early
stages
of
our
official
conversion.
But
everybody
that's
been
using.
Github
actions
loves
it.
A
Well,
we
are
at
our
time
for
our
session.
Thank
you
both
so
much
for
joining
and
having
this
wonderful
conversation,
I
really
enjoyed
the
time
and
I'm
I
think
our
audience
did
as
well.
We
will
put
up
that
QR
code
for
the
folks
in
the
audience.
If
you
could
just
take
a
second
grab,
a
screenshot
of
our
little
I
guess
a
phone
grab
of
that
and
take
a
couple
of
moments
just
offer
us
some
feedback
that
really
helps
us
to
make
sure
that
we're
making
these
sessions
as
impactful
as
possible
moving
forward.