►
From YouTube: Training the Team - GitHub Universe 2015
Description
In this session, Peter Bell will guide us through a range of strategies for knowledge sharing, support, and practice to ensure your team builds the skills required to succeed with GitHub.
About GitHub Universe:
Great software is more than code. GitHub Universe serves as a showcase for how people work together to solve the hard problems of developing software.
For more information on GitHub Universe, check the website:
http://githubuniverse.com
A
Okay,
thanks
everyone
for
coming
out
for
this
session
and
making
it
through
to
four
o'clock
and
still
be
an
awake.
That's
pretty
impressive,
presumably
because
of
the
grain,
coffee
and
another
caffeine
outside
today,
I'm
going
to
be
talking
about
training
the
team.
It
was
interesting
in
Chris's
keynote
this
morning
that
he
talked
about
a
couple
of
things
that
I
think
are
relevant
to
this,
which
is,
he
said,
it's
going
to
be
many
more
people
building
software.
A
If
any
of
you
remember
back
in
the
day
when
you
were
developing
in
Java
or.net,
maybe
a
decade
ago,
and
then,
like
Ruby,
seemed
like
things
were
moving
faster
now,
you
got
node
where
the
the
best
build
system
changes
about
every
60
days.
So
the
question
is:
how
do
we
do
a
better
job
of
adopting
those
technologies
and
that's
what
I
want
to
talk
about?
One
question,
I'll
answer.
First,
though,
is
why
should
you
be
listening
to
me
about
it
so,
just
to
give
her
a
very
brief
background.
A
My
name
is
Peter
Bell
and
there's
a
number
of
reasons
why
I'm
relevant
the
first
is
I
was
a
contract
member
of
the
github
training
team
for
a
number
of
years
and
I
ended
up
writing
and
creating
a
bunch
of
materials.
I
created
the
introducing
github
book
at
o'reilly,
along
with
Brent
Brent
beer
created
the
Pearson,
git
and
github
live
lessons.
Content
created
mastering
github
for
code
school
now,
part
of
pluralsight
and
I
even
teach
MBA
students
at
Columbia,
Business
School.
A
So
congratulations,
you've
decided
to
adopt
some
new
technology.
I'll
use
some
examples
around
adopting
geared
or
github,
but
it
might
be.
You
finally
decided
to
get
into
containerization
you're
moving
to
react.
Jas
for
the
front
end,
you
even
decided
to
move
to
Adam
from
an
IDE
whatever
it
might
be.
So
the
question
is:
what
do
you
do
now?
You
need
to
make
the
decisions
as
to
what
technology
to
adopt,
but
then
there's
a
couple
of
things
you
need
to
think
of
it.
A
One
is
you
need
to
have
clear
objectives
for
your
training
program
for
yourself
or
your
team
or
your
organization,
and
then
the
other
thing
you
need
to
think
about
is
how
do
you
build
meaningful
competence?
So
what
I
want
to
do
over
the
next
thirty
five
minutes
was
always
break
this
down
and
go
through
each
of
these
areas.
So
the
first
one
is
objectives,
and
this
is
something
that
a
lot
of
people
don't
think
through
precisely
I
mean
the
objective
is
I
want
my
team
to
be
good
at
using
this
stuff?
A
Yeah
I
get
that,
but
but
what
does
that
mean
in
terms
of
breaking
it
down?
Will
it
means
you've,
got
to
think
about
roles,
capabilities
and
then
going
to
do
a
needs
assessment
or
a
gap
analysis
if
we
were
to
look
at
Rose
I'll.
Take
the
example
of
github.
Now
you
can
get
as
precise
as
you
want
with
this,
but
if
I
was
to
give
like
a
really
like
broken
down
list,
you
could
think
there
are
stakeholders,
business
people
who
only
really
care
to
be
able
to
see
what's
being
done
and
how
is
it
going?
A
I
just
want
to
see
the
open
pool
requests
the
closed
issues
stuff
like
that.
So
that's
a
relatively
small
subset
of
the
git
and
github
ecosystem.
They
need
to
learn
they.
Maybe
you
ever
collaborator,
somebody
who
might
not
create
content
but
might
give
feedback
on
pull
requests
or
issues
as
the
rest
of
the
team
requires
that
next
it
might
be
a
contributor.
This
might
be
somebody
who
primarily
contributes
through
a
web-based
interface
on
to
a
graphical
interface
like
github
desktop.
A
Then
you
can
I
move
into
the
developer
world,
where
somebody
really
needs
to
be
building
competence
in
using
get
on
the
command
line.
They
wait
and
then
there's
a
few
specialists.
You
might
want
to
have
an
integration
specialist
to
figure
out
how
you
integrate
ldap,
with
your
github
enterprise
in
Stintz,
workflow
consultant
to
rebase
or
not
rebase.
That
is
the
question
even
a
get
guru,
because
you
need
somebody
when
you
reset
hard
head
till
24
and
you
meant
three,
you
need
somebody
who
actually
knows
how
the
ref
log
works.
A
So
you
can
go,
get
that
stuff
back
and
fix
it
for
the
team
or
when
somebody
decides
a
really
good
idea
would
just
be
to
reset
the
last
20
commit
some
force
push
to
master.
So
you
need
somebody
who
can
go
in
and
fix
that
stuff,
and
it's
worth
thinking
about
you
don't
necessarily
need
to
have
all
of
these
on
your
team,
integration
or
implementation.
Specialist
might
be
a
role
that
you
don't
need
ongoing.
Maybe
a
third-party
organization
can
help
you
with
that.
Most
of
the
uneven
the
workflow
you
can
get
some
consulting
on.
A
So
we
talked
about
some
of
the
rows
for
each
one
of
those
rows
you
they
need
to
start
to
think
about
capabilities.
What
skills
should
these
people
have
it's
important
to
realize
that
it's
about
them?
Not
you!
It's
not!
What
stuff
do
I
want
to
teach
them
it's.
What
stuff
do
I
want
to
make
sure
they
can
actually
do
once
I'm
done
with
the
teacher,
so
typically
in
learning,
they
call
this
learning
objectives.
A
For
what
set
of
competencies
to
you
mean
that
somebody
can
collaborate
or
within
a
team,
maybe
they
can
create
a
descriptive,
commit
message
and
then
the
final
part
that
you
ideally
want
to
do,
and
this
isn't
always
practical
is
you
want
to
identify
the
gap
now
that
you've
got
a
set
of
people
that
are
supposed
to
fulfill
a
certain
set
of
rows?
You
wanna
be
like
okay.
How
do
we
determine
how
close
they
are
today?
A
A
So
it's
important
to
take
a
little
bit
of
time
to
think
about
your
objectives
before
you
say:
hey,
let's
just
go
buy
this
book
or
this
video
series,
so
let's
bring
a
trainer
in
they
will
solve
all
our
problems.
Sometimes
we
will,
but
it's
important
to
think
about.
Excuse
me
to
think
about
the
objectives,
Rose
capabilities
and
the
gap.
A
Okay.
So
now,
let's
break
down
the
other
side
of
it.
You
determined
you've
got
this
bunch
of
people
with
a
set
of
skills
that
they
need
to
be
able
to
deliver
on,
and
you
figured
out
the
gap.
What
do
you
do
now?
Well,
you
want
to
build
competence
right.
You
want
somehow
your
team
to
be
competent
so
that
you
trust
them
not
to
force
push
a
bunch
of
stuff
to
master.
A
They
shouldn't
and
it's
worth
thinking
about
this
in
terms
of
two
areas:
there's
the
stuff
you
want
to
somehow
load
into
their
brains,
and
then
there
were
the
specific
techniques
you're
going
to
use
to
load
that
stuff
effectively
efficiently
and
sustainably
into
their
brains.
Unfortunately,
the
the
Microsoft's
aren't
quite
there
yet
so
we're
going
to
have
to
go
on
school
and
actually
teach
people
stuff
first
thing
I
want
to
talk
about
is
the
information,
and
this
is
probably
where
most
training
undertakings
fail.
A
I've
seen
quite
a
few
training
organizations
where
they
do
a
relatively
good
job
of
teaching,
really
bad
ideas
to
fairly
large
numbers
of
people
in
an
organization
to
misquote
William
Gibson.
There
are
best
practices
out
there.
There
are
good
information,
good
resources
on
what
to
do,
but
the
longer
the
more
time
I
spend
teaching
get
the
more
horrified
I
am
about
just
about
everything
else.
I
see
in
public
talking
about
it.
A
I'll
give
you
an
example:
I've
got
to
ask
so
how
many
people
recognize
this
diagram
yep
and
how
many
people
are
using
it
as
the
basis
of
your
flow
yeah
and
and
and
that's
pretty
common,
I
would
say
about
half
the
organization's
they
go
into,
I'm
not
going
to
get
into
it
now,
but
I'm
just
going
to
going
to
love
the
hand
grenade
and
say
this
is
considered
harmful.
This
is
a
gift
flow
model.
It
was
actually
a
great
idea:
I
remember,
loving,
get
flow
when
it
first
came
out.
A
So
this
stuff,
like
this,
that
is
still
being
taught
as
best
practices-
and
you
know
this
must
be
a
good
idea
because
there's
a
whole
bunch
of
articles
and
stack
overflow
telling
you
it
is
I
very
specifically
picked
that
logo
rather
than
another
one
from
Stack
Overflow,
because
it
kind
of
sitting
it's
them
awesome
ideas
there
and
there's
the
other
stuff.
And
the
question
is:
how
do
you
differentiate
one
from
the
other,
so
you
should
be
like?
Well,
that's!
A
Okay,
if
stack,
overflow
doesn't
necessarily
have
all
the
answers
we
know
who
does
there
are
all
these
great
publishing
companies
we
can
go
to
and
I've
worked
with
many
of
them.
The
challenge
is:
there's
a
real
difference
between
and
I've
noticed
this
teaching
one
topic
for
five
years.
There's
a
huge
difference
in
the
cycle.
A
Oh,
you
should
probably
update
that
thing.
So
the
challenges
stuff
published
in
traditional
media
is
not
necessarily
the
latest
best
practices.
So
you
really
need
to
think
about.
How
can
we
get
not
just
information
about
the
tools,
but
also
what
are
the
latest
best
practices
that
people
are
now
using
to
do
this
more
effectively?
I
want
to
call
out
one
specific
example.
A
A
couple
years
ago,
I
was
teaching
a
class
on
Redis
for
a
large
software
company
in
Silicon
Valley
and
usually
what
I'll
do
if
I'm
teaching
a
new
technology
I
download
it
read
a
few
blog
posts,
read
a
couple
of
books
and
I'm.
Like
you
know,
I'll
figure,
the
rest
out
from
there
I
was
very
pleasantly
surprised.
When
I
read
the
reddest.
Anyone
read
this:
just
out
of
interest
read
his
cookbook.
A
If,
for
any
reason,
you
ever
end
up
adopting
radius,
that's
the
book
to
get
because
pretty
much
all
the
other
books
out
there
on
pretty
much
a
dino
sequel,
datastore.
The
vast
majority
of
them
are
like
it
kind
of
feels,
like
the
man
page,
only
printed
right.
It's
like
here's.
The
things
you
should
do
and
here
are
the
options,
and
here
are
the
settings.
This
one
was
like.
Oh
don't
use
that
feature
because
in
production
at
scale,
these
things
go
wrong.
A
The
organizations
that
use
this
regularly
do
this
instead
and
it
was
giving
you
really
detailed
insight
from
somebody
who'd
clearly
spent
years
actually
doing
this
in
production.
So
that's
the
kind
of
information
Europe
you're.
Looking
for
the
only
challenge,
it
sounds
like
I'm
going
to
talk
about.
So
what
you
really
need
to
do
is
find
best
practices.
The
only
problem
with
best
practices
is
there
aren't
any
right
there
aren't
just
well.
This
is
the
way
that
an
engineering
team
should
use
a
workflow.
A
One
of
the
things
has
been
fascinating
to
me
is
I
used
to
think
I
knew
the
right
workflow
to
use
git
and
github,
and
then
I
taught
it
more
and
more
and
more
different
enterprises
with
totally
different
use
cases,
and
it
turns
out
that
almost
everything
you
can
come
across
in
Stack
Overflow
is
a
good
idea
for
someone.
It's
probably
just
not
a
good
idea
for
you,
so
in
fact
you
don't
want
like
this
one
best
practice
like
this
is
the
way
you
shalt
do
it.
A
You
want
to
take
more
of
a
kind
of
decision
tree
approach.
Let
me
give
an
example:
release
branches
who
here
uses
release
branches
yeah,
it's
a
pretty
common
pattern.
A
good
way
of
introducing
release
branches
is
that
you
don't
need
them.
Unless
and
what's
interesting
is
you
can
start
by
saying
we'll
look,
let's
say:
you've
got
master
and
you've
got
a
number
of
commits.
Let's
see
we're
running,
continuous
delivery.
Anything
hits
and
I've
simplified
this,
because
I
really
didn't
have
the
time
the
diagramming
tool
to
bring
out
all
the
feature
branches
of
emerging.
A
In
so
imagine
each
one
of
those
commits
is
really
just
merging
in
a
feature
branch
with
a
number
of
commits.
Well,
if
you
don't
continuous
delivery,
you
really
don't
need
release
branches.
You
just
work
on
something
as
soon
as
you
merge
it
into
master
5
10
minutes
later
it's
in
production,
so
there's
really
nothing
else
to
do.
But
then
what
happens
if
you're,
in
a
situation
where
not
every
single
one
of
those
goes
to
production?
Well,
then
often
it's
a
good
idea
to
create
release
tags.
A
So
then
at
least
you're
tagging
in
the
code
base
to
make
it
clear
which
of
these
were
actually
production
releases
and
which
ones
weren't
so
annotated.
Tags
are
a
good
fit
for
this
and
you
can
even
use
those
to
get
kind
of
sign
off
from
different
departments
and
to
capture
that
within
the
code
base.
So
what
happens?
If
you
have
a
bug
turns
out
that
sometimes
you
get
into
production
and
somethings
about
book.
You
may
create
a
release
branch
either
off
of
the
latest,
merge
commit
or
even
an
earlier
one.
A
You
go
fix
your
changes
because
you
don't
wanna
be
committing
directly
to
master,
and
then
you
fix
those
changes
and
once
you're
done
and
you've
tested
them.
You
emerge
that
into
master.
So
you
have
a
release
branch
for
about
20
minutes
or
two
hours,
and
then
you
throw
it
away
and
in
fact,
the
only
time
you
actually
need
long-lived
release
branches.
A
A
Another
way
of
thinking
about
the
information
you
want
to
be
communicating
to
your
team
is
in
terms
of
trade.
Offs
turns
out
so
I
got
to
ask
it's
one.
So
do
you
rebase
feature
branches
or
not
just
show
our
hands,
how
many
people
will
rebase
a
feature-
branch
yep
and
how
many
people
don't
rebase
a
feature
branch
yeah?
It
depends
upon
the
audience
here.
It's
a
little
heavy
on
rebasing,
but
I,
see
about
5050
across
the
range
of
entities.
I
work
with
turns
out
there's
a
very
simple,
distinct
and
clear
trade-off.
A
The
first
level
heuristic
is:
what
do
you
look
for
your
history
most
get
or
github?
If
you
primarily
want
a
clean,
git
log
history,
you
should
rebase
your
feature
branches,
because
then
it's
going
to
make
it
look
like
you
built
one
feature
at
a
time
which
is
awesome.
If,
however,
you
want
to
see
what
was
done
in
the
last
month-
and
you
just
look
at
the
closed
pull
requests,
you
probably
shouldn't
rebase
your
feature
branches.
Why?
A
Because
all
of
your
line
level
commits
are
going
to
disappear
from
your
pull
request
because
of
the
shower
one
hashes,
the
commits
have
changed
so
there's.
Actually,
this
very
simple
trade
off
or
heuristic,
which
is,
do
you
primarily
look
at
history
as
closed
pull,
requests
or
is
get
log,
and
whichever
one
of
those
you
want
to
optimize
for
in
your
workflow
drives
whether
or
not
you
should
rebase
your
feature
branches
and
again
it's
not
the
stack
overflow
thing
where
this
is
right.
This
is
wrong.
A
So
we've
talked
a
little
bit
here
about
the
information.
The
most
important
thing
you
want
to
do.
Garbage
in
garbage
out
is
make
sure
you
have
great
information
to
share
with
your
team
before
you
work
really
hard
at
getting
them
to
memorize
and
practice.
It
once
you've
done
that,
though,
then
we've
got
to
talk
about
learning.
How
do
we
actually
get
these
best
practices
and
best
ideas
into
ourselves?
And
our
team's
first
point
I
want
to
make.
A
Excuse
me
is
that
teaching
is
not
learning
the
fact
that
I
stand
up
here
and
tell
you
a
bunch
of
stuff-
and
this
is
kind
of
gently
ironic-
that
I'm
standing
up
here
telling
you
a
bunch
of
stuff,
including
telling
you
this,
isn't
a
very
good
way
to
convey
information.
Sorry,
they
didn't
allow
me
to
do
a
hands-on
workshop,
it's
kind
of
hard
to
organize
for
this
many
people
with
Wi-Fi,
but
this
is
actually
a
very
inefficient
way
to
communicate
information.
I
should
have
just
written
a
blog
post
and
save
myself
the
flight.
A
However,
it's
a
relatively
good
way
to
get
people
motivated
to
say,
I'm
not
sure
that
I
remember
everything
he
said,
but
it
sounds
like
this
and
stuff
I
should
think
about
here.
So
now,
I'm
going
to
go,
read
a
blog
post
or
go
look
at
some
companies
and
some
solutions
to
do
this
better
in
the
future.
But
just
standing
up
and
talking
to
your
team,
whether
you
hire
someone
to
do
it
or
do
it
yourself
is
not
enough
to
change
their
capabilities
on
its
own.
So
what
do
you
need?
A
We
need
a
number
of
things,
but
the
key
things
you've
got
to
focus
on
when
you're
thinking
about
getting
people
to
adopt
new
technologies
successfully
and
become
competent
in
them
is
motivation,
active
participation
and
practice.
If
they
don't
care,
there's
no
point
you're
not
going
to
be
to
like
force
the
learning
into
their
skulls.
So
the
first
thing
you've
got
to
do
is
actually
make
a
connection
and
agree.
A
The
number
of
times
I'll
go
into
a
company
and
is:
is
that
one
usually
slightly
older
guy
in
the
corners
like
I,
don't
see
what's
wrong
with
CVS
was
good
enough
for
me
15
years
ago.
Don't
know
why
we're
wasting
their
time
and
in
less
you
can
turn
that
round
and
actually
come
up
with
some
problems
that
they've
had
in
the
past
that
they
care
about
this.
A
A
There's
a
few
other
things.
I
want
to
put
in
one
thing
on
talk
about
with
types
of
learning.
This
is
something
we
don't
always
break
down
from
an
engineering
perspective,
but
there's
a
number
of
different
kinds
of
learning
that
people
need
to
undertake
to
become
competent
with
new
software.
It
varies
for
different
things,
but,
for
example,
conceptual
factual
skills,
acquisition
and
even
cultural
acclimatization.
It's
look
at
that
he's
one
at
a
time,
so
conceptual
learning.
What
is
a
pull
request?
What
is
a
commit?
A
Often
this
is
a
matter
of
like
coming
up
with
good
analogy
so
that
people
can
take
stuff.
They
already
understand.
Oh,
this
is
uber
for
cats.
I
get
it
pull
requests
it's
a
conversation
around
a
branch.
Oh
I
know
what
a
branch
is.
I
know
what
a
conversation
is
now.
That
starts
to
make
more
sense,
and
it's
important,
and
often
to
give
people
multiple
examples
or
analogies
so
that
one
of
them
hits
for
everyone
and
to
give
them
real
practice
like.
So
when
would
you
create
a
pull
request?
When,
wouldn't
you
create
a
pull
request?
A
The
connections
within
the
brain,
so
the
bottom
line
is
quizzes
are
a
really
good
way
to
help
people
to
learn
stuff,
even
to
the
extent
our
one
study,
that's
really
fascinating
was
called
pre-testing
turns
out
that
if
you
ask
somebody
a
bunch
of
questions
about
something,
they
know
nothing
about
and
then
teach
them,
they
will
recall
a
substantially
higher
proportion
of
that
information.
So
actually
there's
value
in
just
going
through
a
quiz
and
like
I
have
no
idea.
You
will
then
actually
your
brain
will
then
do
a
better
job
of
retaining
the
information.
A
After
the
fact
talking
of
facts
and
factual
information,
sometimes
you
just
need
to
remember.
So
what
is
the
command
to
list
all
branches?
How
do
I
throw
away
a
merge
commit
what
command
do
I
use
for
that
and,
in
addition
to
just
giving
this
information,
sometimes
it
makes
sense
to
do
things
like
anke,
for
example,
is
a
tool
that
you
can
use
to
kind
of
build
flashcards.
So
why
not
have
flash
cards
so
you
can
actually
go
through
and
make
it
easier
to
memorize.
A
This
cheat
sheets,
sticky
notes
things
like
that
can
help
you
to
persist
factual
information
more
successfully
for
your
team,
then
we've
got
skills
acquisition,
a
good
example,
maybe
vim
key
combinations
right.
Anybody
who's
ever
moved
from
vim
to
Emacs
or
the
other
way
has
probably
had
an
interesting
experience
that
required
more
than
just
conceptual
understanding
and
retaining
a
few
facts.
You
have
the
muscle
memory
and
it's
wrong.
It's
like
when
you
go
from
IntelliJ
to
visual
studio
or
whatever
it
might
be.
A
So
it's
important
to
think
here
then
about
how
can
you
give
hands-on
exercises
and
actually
build
that
familiarity
with
the
particular
skill
that
you're
trying
to
help
people
acquire
there's
even
things
like
cultural
acclimatization?
One
of
the
biggest
challenges
I
find
within
more
traditional
enterprises,
is
used
to
do
a
bunch
of
agile
coaching
I'm
like
okay,
we're
now
all
going
to
sit
in
a
room
and
admit
all
this
stuff.
A
How
do
I
make
sure
this
developer
can't
edit
that
file
or
can't
see
that
file
or
how
do
I
make
sure
that
nobody
force
pushes
over
marks
stuff?
Okay,
we
got
protected
branches
now,
but
it's
a
fundamentally
different
set
of
cultural
assumptions
underlying
github
than
would
be
underlying
some
traditional
centralized
VC
asses.
A
A
Few
of
the
concepts
I
want
to
throw
in
fairly
quickly
I
want
to
talk
about
something
called
project-based
learning.
This
is
one
that
you
have
to
be
a
little
careful
with,
because
it
doesn't
mean
exactly
what
it
sounds
like
I
would
argue.
Project
based
training
is
something
that
we're
familiar
with
I'm,
going
to
give
you
a
project
or
a
lab,
and
you
go
through
and
do
that
in
educational
circles.
They
call
that
problem
based
learning,
because
it's
kind
of
like
giving
you
the
20
differential
equation.
A
Math
problems
you
have
to
work
through
them
to
become
competent,
project-based
learning
is
actually
selling
a
little
different
and
it's
both
good
and
bad.
With
project-based
learning,
you
take
students
and
you
give
them
an
environment
where
you
say:
let's
figure
this
stuff
out.
Let's
do
some
exploratory
work,
so,
for
example,
I
might
take
a
bunch
of
MBA
students
and,
if
I
really
wanted
them
to
get,
why
bother
with
a
version
control
system?
I
might
start
with
a
thought
experiment.
A
Let's
use
Google
Docs
to
keep
track
of
a
document
and
the
good
news
is:
you
can
track
changes
there
right,
I,
don't
need
no
stinking
VCS
I
got
it
right
in
google
docs
and
then
I'm
like
okay.
So
this
is
great.
So
now
what
I
want
you
to
do,
because
we're
going
to
put
a
bunch
of
documents
in
this
directory
I
want
you
to
make
one
change
atomically
that
affects
three
different
documents.
A
How
could
we
saw
a
problem
where
I
can
be
making
one
set
of
changes
to
a
word
document
and
you
can
be
making
another
set
and
we
could
jump
between
them
and
people
end
up
like
making
different
copies
of
the
files
and
doing
these
things,
so
they
can
kind
of
build
up
and
explore
an
understanding
for
the
problems
that
a
version
control
system
really
solves.
The
good
news
is
this
is
an
incredibly
powerful
way
to
share
new
conceptual
information.
A
Bad
news
is
it's
really
freaking
slow
I
mean
you
can
spend
like
an
hour
learning
prior
version.
Control
system
is
a
good
idea
or
you
can
put
three
bullets
on
a
slide.
So
you
have
to.
This
is
a
great
approach,
but
you
have
to
use
it
carefully,
focusing
only
on
the
cases
where
it
really
matters
and
generally
where
people
have
a
hard
time,
otherwise
retaining
the
information.
A
A
That's
how
it
works,
because
there's
some
people
who
are
like
what's
the
command
line
and
others
are
like
so
I-
wanted
to
ask
you
this
ref
log
question
before
we
get
started,
and
it
turns
out
that
when
you
have
that
breath
that
disparity
of
initial
capabilities,
it's
really
hard
to
do
a
good
job
of
an
instructor-led
training.
So
in
this
case
some
of
the
things
you
want
to
be
thinking
about
is
assessments
so
that
people
can
test
out
hey.
A
You
don't
need
to
do
day,
one
because
you
figured
out
this
quiz
or
you
built
this
project
successfully,
and
we
see
that
you
understand
the
basics
of
the
github
workflow
thinking
about
giving
people
multiple
problems.
So
maybe
you
can
focus
on
a
particular
type
of
content,
but
then
people
can
go
deeper
if
they're
blown
through
the
first
problem
in
five
minutes.
So
differentiated
learning,
I
think,
is
one
of
the
big
challenges
that
we
face
in
terms
of
how
do
we
do
a
good
job
not
wasting
our
team's
time?
A
A
A
One
of
the
things
you
can
do
to
improve
the
effectiveness
of
trading
or
learning
is
to
build
some
kind
of
community.
Sometimes
it's
for
collaboration,
hey
I
want
the
two:
are
you
to
buddy
up
or
I
want
for
you
to
work
on
a
team
and
nobody,
nobody
kind
of
passes
unless
you
all
do
so,
it's
a
way
of
ensuring
the
a
group
of
people
can
help
each
other
to
be
more
successful
with
new
content,
you
can
also
do
competition.
A
It's
why
the
whole
gamification
works,
prove
that
you
know
more
get
than
anybody
else
into
your
company
who's
going
to
be
the
Guru
this
week.
But
what
this
really
is
is
it's
just
a
simply
a
form
of
motivation,
because
it's
kind
of
obligation
you
give
me
a
book
I
might
get
round
to
reading
it.
You
tell
me
that
you're
going
to
compare
my
skills
against
somebody
else
or
get
me
to
work
in
a
team
by
the
end
of
the
week.
I
kind
of
feel
like
I,
have
a
responsibility
to
the
rest
of
the
team.
A
A
Yes,
so
basically
I'm
arguing
that
me
and-
and
we
are
Clippy-
hopefully
we're
just
a
little
better
at
giving
you
the
right
answers,
because
that's
really
what
differentiates
an
instructor
they're
telling
you
the
stuff.
You
need
to
know
in
the
way
that
immediately
answers
the
question
you
have
today,
so
information
telling
the
right
stuff,
plus
learning
ensuring
that
they
adopted
successfully,
is
the
way
that
you
help
your
team
to
build
competence.
A
For
now,
of
course,
because
turns
out
that
the
best
practices
keep
on
changing,
and
then
you
move
from
one
containerisation
strategy
to
another
when
you
move
from
chef
to
ansible
for
your
platform,
as
are
for
your
infrastructure
as
a
service,
so
it's
kind
of
this
ongoing
process,
both
the
tools
you're
familiar
with
and
with
the
ones
that
you're
not
so.
My
goal
today
was
really
just
to
say
that
the
next
time
you
think
about
adopting
a
technology,
whether
it's
getting
github
or
whether
it's
something
else
you
need
to
be
thinking
about.
A
How
are
we
going
to
ensure
the
capabilities
of
the
team?
What
are
our
objectives?
What
kind
of
roles
are
people
going
to
need
to
perform?
What
capabilities,
what
the
learning
objectives
can
be?
What
are
they
going
to
do
once
they're
trained
and
which
of
those
things
can't
they
do
now,
so
we
can
waste
the
minimum
of
their
time,
moving
them
from
their
current
skill
set
to
the
capabilities
they
need
and
then
making
sure
to
take
the
time
to
think
about
the
right
information.