►
Description
Becoming a better programmer means more than just learning new technologies.
In this talk, Peter Goodliffe will describe that it means more than practising techniques and idioms. It's about more than passion and attitude. It's the combination of all these things.
About CodeConf
CodeConf improves the software community by providing a forum for thought-provoking talks and forging social connections. The third installment of the CodeConf series took place in Nashville in 2015. Attendees came together to discuss open source, best practices, documentation, and community.
For more information on this year's CodeConf, go to:
https://codeconf.com/
A
Thank
you
very
much,
grace
kind
of
embarrassing,
but
you
know:
okay,
I
won't
bow
to
myself
more
I'll
show
in
a
minute,
and
so
everyone
join
the
conference
so
far,
I'll
see
what
I
can
do
about
that
so
becoming
a
better
programmer.
I
thought
this
talk,
I'm,
giving
it
a
few
different
places
and
more
than
that,
it's
kind
of
one
of
the
oddball
talks.
It's
a
little
bit
sort
of
out
there,
but
the
broad
range
of
stuff
you've
got
going
here.
A
A
Importantly,
I'm,
not
an
expert
I'm,
still
learning.
Very
importantly,
I,
don't
think
I'm,
stratospherically,
clever,
I,
don't
think
I
know
more
than
you
I'm,
just
a
few
rungs
up
the
ladder
learning
what
an
interesting
view
it
is
as
I
get
higher
up,
but
basically
in
20
odd
years,
I've
probably
learned
that,
as
you
get
higher
up
the
ladder
things
get
a
bit
more
wobbly
beat
you
get
slightly
better
view.
It's
cool
I
have
written
a
few
books.
My
first
was
called
code
craft
that
was
about
becoming
a
better
programmer.
A
I
write
a
regular
magazine,
coma
I've
been
doing
that
for
about
17
years.
That's
called
becoming
a
better
programmer
and
so
I.
Then
another
book
and
I
couldn't
think
of
a
title,
so
that
was
called
becoming
a
better
programmer.
So
you
might
think
you
know
I've
either
got
no
originality
all
because
this
talk
is
becau
becoming
a
better
programmer.
It's
a
thinly
veiled
sales
ploy
go
and
buy.
A
My
book
is
great,
but
no,
basically,
this
is
just
something
I'm
really
passionate
about
something
I
really
care
about,
and
so
this
is
what
we're
going
to
do
today.
We're
going
to
work
out
ways
that
each
of
us
can
become
better
program,
so
I
guess
I
should
probably
check
first
of
all
hand,
leave
you
guys
in
the
audit.
Our
programmers
show
me
some
love
good,
good,
good,
good,
good,
ok,
cool
right
I
have
some
raw
material
to
work
with.
A
This
is
a
start,
so
question
number
one:
do
you
as
programmers
or
if
you're,
not
programmers
is
the
spheres
that
you
work
in
because
it
applies
to
you
as
well.
Do
you
want
to
become
better?
Do
y'all
have
a
number
of
programs
hands
up
if
you
do
unanimous
come
on,
make
it
unanimous
cool,
good,
okay,
you're
on
board
you're
on
board,
that's
kind
of
best
best,
one
of
those
and
borne
things,
and
thank
you
for
the
enthusiasm.
That's
cool
question
number
two:
does
it
even
matter?
Does
it
cool?
A
Yes,
why
Cassie
always
goes
quiet,
cuz,
you're,
not
good
enough?
Okay,
that's
cool!
You
should
I
get
some
kind
of
sake.
Answers
one,
not
the
only
answer,
but
one
really
very
good
reason:
it's
because
you
don't
want
to
be
the
guy
that
does
the
makes
people
go.
Then
we've
all
work
with
them
yet
they're
guys
that
just
spew
out
dodgy
code,
the
kind
of
code
that
just
gets
anyway
that
distracts
the
slows
you
down
you
don't
to
be
that
guy.
That's
if
nothing
else,
one
good
reason,
not
just
your
sanity,
but
the
sake
of
humanity.
A
A
It's
a
bit
handsy
and
wavy
touchy-feely
stuff,
I
know.
But
it's
just
my
observation
from
the
people.
I've
worked
with
from
the
people
I've
learned
from
now
a
long
time
ago,
I
was
sort
of
told
a
little
giving
a
little
illustration
and
it
stuck
with
me
for
years
and
it's
attitude
you
can
think
of
it
like
three
axes:
no,
not
those
kind
of
axes,
the
kind
of
axes
of
a
plane.
So
you
know
if
I'm,
not
a
pilot.
A
I
know
people
who
are
helicopter
pilots
and
they
tell
this
isn't
wildly
off,
but
applying
those
on
three
axis
you've
got
the
pitch
the
you're
in
the
roll
don't
know
which
way
around
they
go,
but
you've
got
pitch
your
unroll.
That
is
cool
that
the
cut
the
position
of
a
plane.
The
trajectory
on
those
three
axes
is
called
its
attitude,
and
this
is
the
interesting
thing
if
you
apply
pressure,
if
you
might
power
to
that
plane,
when
it's
even
got
a
slightly
wrong
attitude
that
will
massively
miss
the
mark.
A
I
just
think
it's
an
interesting
illustration
that
if
we
don't
approach
the
act
of
creating
code,
the
act
of
creating
software
with
the
right
attitude,
we
could
massively
miss
the
mark,
cautionary
tale
and
Winston
Churchill
agrees
attitude
is
the
little
thing
that
makes
a
big
difference
now.
You
know.
Just
if
you
want
to
sound
like
you're,
not
you
talk
about
any
talk,
throw
some
good
quotes
up
the
air,
so
Winston
Churchill.
Clearly
you
know
you
got
to
trust
him.
A
British
Prime
Minister
Barrett,
you
know,
but
maybe
maybe
maybe
he
was
just
just
one
guy
agreeing
with
me.
Scottish
playwright,
Walter
Scott
for
success
attitude
is
equally
as
important
as
ability.
This
must
be
true:
okay,
Muhammad
Ali,
another
great
philosopher
to
be
a
champion.
You
must
believe
you're
the
best
if
you're
not
pretend
you
are.
Is
that
a
good
attitude?
A
Okay,
it's
good
to
have
a
can-do
attitude,
it's
good
to
believe
you
can
do
something,
even
if
you
know
you've
not
learnt
this
thing
yet
I
think
I
can
do
it.
On
the
other
hand,
pretending
to
be
good.
It's
that
good,
maybe
not
so
it's
not
just
having
an
attitude,
is
having
the
right
attitude
and
that's
the
kind
of
thing
that
I
just
want
to
spend
this
40
minutes
trying
to
unpack
40
minutes
by
the
way
I
noticed
as
a
luxury
compared
to
some
what
the
other
speakers
have.
A
But
for
me
this
is
I'm
going
to
have
to
condense.
A
condensing
identify,
really
hope.
I
get
enough
information
for
you
in
this
40
minutes,
because
normally
this
talk
take
like
90,
so
his
good
lafe's
taxonomy
of
programming,
shenanigans
in
the
sense
that
you
know
what
we
do
is
technologists.
We
start
from
a
basis
of
knowledge.
We
learn
and
we
learn
facts
and
whatever
about
the
technologies
we
work
in,
then
we
learn
the
idioms
of
how
to
apply
and
use
those
technologies
in
certain
areas.
A
So
the
idioms,
then
we
learn
the
application
of
those
idioms
and
the
technology
to
problems
and
that's
what
we
do
and
it's
great
but
I
again,
I'm
just
resetting
again,
if
we
don't
sort
of
have
there
are
attitudes
if
we're
not
applying
those
things
for
the
right
reasons.
It's
not
like
to
make
me
look
good
because
I
want
to
learn
this,
but
because
it's
the
right
application
of
the
right
technology
in
the
right
place,
then
we're
missing
the
mark
and
we're
doing
the
wrong
kind
of
work.
And
again
that's
that
kind
of
thing.
A
From
going
from
knowledge
to
wisdom,
why
we're
doing
something,
rather
than
just
how
we're
doing
something?
So
how
do
you
get
better?
Do
programmers
like
a
fine
wine
mature
with
age
or
maybe
like
a
cheese?
We
mature,
get
slightly
smellier
and
get
a
few
veins.
Let's
see,
obviously
how
to
get
better
learn
technology.
That's
a
given,
learn
the
idioms.
That's
a
given
learn
how
to
apply
it.
All!
That's
a
given
but,
more
importantly,
work
out
how
to
adjust
your
attitude
or
taking
audit.
A
Let's,
let's
look
at
what
we
do
hand
wavey,
I
know,
but
I,
but
I
think
this
could
have
keys
to
really
help
you
get
better.
Stick
with
me.
It's
the
ninja
level
kind
of
stuff.
If
you
get
a
quote
anyone
I'm
going
to
quote
myself
there.
This
was
for
the
intro
to
my
book,
there's
more
to
being
a
great
coder
and
simple
understanding
of
syntax
and
the
mastery
of
basic
design.
The
awesome
programs,
those
productive
people
who
craft
beautiful
code,
work
affected
with
other
people,
know
far
more.
A
There
are
methods
of
working
attitude,
approaches,
idioms
and
techniques.
You
learn
over
time
that
increase
your
effectiveness.
There
are
social
skills
and
whole
pile
of
tribal
knowledge.
We
need
to
sort
of
gather
all
of
that
up.
All
of
that
up
and
work
at
how
to
improve,
but
the
first
thing
is
to
want
to
improve
and
you've
stuck
your
hands
up.
You
want
to
get
better
yeah,
so
cool
we're
on
board.
This
is
what
I
want
to
try
and
unpack
I'm,
going
to
show
you
a
few
models
of
learning
of
knowledge
acquisition.
A
This
ties
into
attitude
and
we
can
use
these
models
to
help
us
work
out
what
to
learn.
I'm,
not
going
to
give
you
many
very
practical.
This
is
how
you
put
a
semicolon
here,
or
this
is
how
you
should
indent-
or
this
is
the
library
you
should
use
kind
of
stuff.
I
want
to
give
us
a
framework
to
look
at
how
we
can
find
information
and
use
it
to
the
best
of
our
advantage
and
our
projects
advantage.
A
So
then,
we'll
look
at
what
you
should
learn,
maybe
some
specific
topic
if
we
have
some
time
and
then
more
hand-waving
to
wrap
up
so
the
models
of
knowledge
acquisition,
I
think
this
stuff
is
really
fun
and
really
interesting.
So
here
is
a
hypothetical
model
of
learning
it's
bobbins,
but
just
go
with
me.
There's
you
at
some
sort
of
period
in
time.
You
know
what
you
know
now
you
know,
and
it
ranges
from
down
here-
utter
liability.
The
bad
coder
to
super
awesome
guru
genius
programmer
you're
here
at
this
point,
some
point
in
time.
A
This
is
what
you
know
now
and
you
would
like
to
get
better
cool.
Ok,
that's
our
first
model,
it's
rubbish
because
knowledge
applies
not
just
in
one
branch,
not
just
one
area,
but
it's
per
skill.
I
may
know
a
load
about
C++
and
nothing
about
JavaScript
yeah,
so
I
need
to
work
and
learn
differently
in
the
area
of
C++
than
I
do
in
JavaScript,
just
even
understanding
that
will
change
the
way.
You'll
you
absorb
new
knowledge,
but
let's
go
beyond
that.
A
The
next
model
or
an
actual
model,
this
the
full
levels
of
competence,
although
because
I'm,
a
Briton,
my
glass
is
half-empty.
I'd
lightest
hit
the
full
models
of
incompetence,
something
that
was
formulated
in
the
1940s
by
a
psychologist,
called
Abraham
Maslow.
Have
you
guys
heard
of
this?
The
four
levels
of
theory
cool.
So
it
observed
these
four
states
unconscious
incompetence,
conscious
incompetence,
conscious
competence
and
unconscious
competence.
You
repeat
after
me,
yeah,
so
a
good
example
of
this
is
driving
a
car
yeah.
A
When
you
have
two
or
three,
you
have
no
idea
really.
What's
involved
in
driving
a
car
aware
that
your
folks
drive
a
car,
but
you
know
you're
there,
maybe
sitting
on
the
back
with
a
plate
and
you're
doing
this
and
you're
thinking.
You
know
if
I
just
had
the
plate
in
front
seat,
I
could
drive
this
car.
You
have
no
idea
how
you're
so
totally
wrong.
You
do
not
know
that
you
do
not
know
and,
as
you
get
older,
you
know
you
get
closer
to
taking
a
driving
test.
A
You
begin
to
realize
you
begin
to
them
and
you
begin
to
understand
how
much
you
don't
know
about
driving
a
car
there's
so
much
involved.
Now
you
guys
have
it
easy
with
automatics,
but
in
the
UK
we've
got
the
clutch
to
deal
with
as
well.
It's
like
how
many
things
can
move
at
once
and
you've
got
to
be
aware
of
the
road
and
oh,
my
word.
This
is
complicated.
I
now
make
conscious
incompetence,
because
I
know
how
much
I
don't
know.
That's
a
really
good
place
to
be
and
they
get
to
conscious
competence.
A
You
learn
you
practice,
you
learn
you
practice
and
you
become
competent.
You
can
now
do
this
thing.
You're
consciously
competent,
but
the
important
thing
at
this
level,
which
is
another
great
place
to
be,
is
that
in
order
to
exercise
this
skill,
you
actually
have
to
think
about
it.
You
have
to
still
concentrate
and
driving.
So
that's
the
ort
just
party
driving
test
yeah,
if
you
don't
concentrate
booth,
you
ding
the
car
and
finally,
after
you've
been
doing
it
for
so
long.
You
get
to
this
level
of
unconscious
competence.
A
Now,
that's
not
necessarily
the
guru
state-
and
this
is
this-
is
a
piece
of
warning
to
heed.
If
you're,
unconsciously
competent,
you
don't
have
to
think
about
doing
the
thing
you
just
work
on
intuition,
but
as
a
driver,
if
I'm
not
thinking
about
what
I'm
doing
I
may
not
be
paying
full
attention,
I
may
actually
not
notice
the
kid
stepping
out
front
of
the
car
in
front
of
me.
I
might
knock
into
them,
so
sometimes
conscious.
A
Incompetence
can
almost
be
a
dangerous
place
to
be
so
it's
just
an
observation,
but
this
is
that's
a
model
that
we
can
hang
on
learning
off.
Next
one
is
the
dunning-kruger
effect
now
I'm
an
expert
of
this,
which
is
a
hilarious
joke.
If
you
anything
about
the
dunning-kruger
effect,
thank
you
for
laughing,
and
so
during
Krug
effect
is
a
cognitive
bias.
It
was,
it
came
out
of
some
1999
odd
experiments
at
Cornell
University
and
by
Dunning
and
Justin
Kruger,
and
it
works
like
this.
A
Basically,
they
observe
from
a
whole
load
of
study
that
people
who
were
unskilled
this.
This
is
the
four
levels
on
competence
again
the
people
who
are
unskilled
consistently
rated
themselves
below
average,
no
sorry
above
average,
in
the
thing
that
they
were
doing
so
if
you
gave
you
know,
somebody
starts
working
on
JavaScript
and
they
spent
you
know
a
few
weeks
on
it.
They
then
think.
Oh
yeah
I
know
this
all
I'm
really
good
at
it
when
they
know
nothing
and
yet
there's
scale
people
with
the
body
of
knowledge.
They
know
so
much.
A
They
also
know
how
much
they
don't
know.
Those
are
the
guys
that
rate
themselves
under
average,
and
this
is
a
dangerous
thing
and
this
kind
of
explains,
maybe
some
of
the
Oh.
You
look
at
the
composition
of
your
team,
some
of
those
people,
you
might
think,
but
they're,
not
all
that,
but
they
really
think
they
are.
This
has
been
in
Kruger
effect.
They
believed
that
they
were
over
average
because
they
don't
realize
how
much
they
don't
know
unconscious
incompetence.
A
Again,
their
observation
was
the
MIS
calibration
of
the
incompetence
stems
from
an
error
about
itself,
whereas
the
MIS
calibration
of
a
highly
competent
standard
about
an
error
made
on
your
judgement
of
others,
interesting
stuff,
so
Confucius
II,
say
real
knowledge
is
to
know
the
extent
of
one's
ignorance.
This
is
cool.
The
next
model
is
the
Dreyfus
model
of
skills
acquisition.
This
is
the
biggie.
This
is
the
biggie.
This
is
really
interesting.
This
came,
but
this
is
like
a
Seminole
model.
It
came
from
1970s
research,
I.
A
A
There
was
a
way
that
you
that
you
would
think
and
perceive
the
world
and
your
mental
models
were
different
and
the
way
you
needed
to
learn
was
different.
So
this
is
this.
Is
this
is
going
to
disable
pay
attention?
They
split
up
into
sort
of
these
five
levels
of
understanding
where
you
go
from
sort
of
chimpanzee
to
concert,
pianist,
I,
think,
but
there
are
novice
advanced,
beginner,
competent,
proficient
and
expert
I
wish.
I
could
go
into
more
detail
about
this,
but
these
are
all
really
interesting
things
to
unpack.
A
If
you're
a
novice,
you
know
nothing
about
the
subject
at
all.
Obviously,
so
how?
How
do
you
so
I
don't
know
anything
about
how
to
set
up
fabricator
say
so
what
do
I
do?
I,
google,
for
it
I,
find
some
instructions
and
I
follow
those
instructions.
That's
what
I
do
as
a
novice.
I
just
want
a
rote
set
of
rules
and
I'll,
follow
them
and
I'll
following
step
by
step.
I
have
no
idea
the
good
of
narrative
they're
bad
as
long
as
I
get
results.
I'm
happy,
I
want
results.
A
A
Next,
the
advanced
beginner
now
these
guys
sort
of
beginning
to
look
sort
of
understand
the
rules
they
break
them
every
now
and
again,
you
know
all
that
stuff
on
Google
and
I
googled
this
page,
and
it
doesn't
quite
apply
to
what
I'm
doing
so.
I'll
try
and
change
that
configuration
parameter.
Maybe
something
else
and
I
didn't
work.
Okay,
go
back,
try
something
else.
A
The
important
thing
there,
as
well
as
an
advanced
beginner,
knows
where
to
get
answers,
and
here
again
Google
is
our
friend
it's.
It
makes
a
big
difference
to
know
what
the
search
terms
to
look
for.
Even
if
you
don't
know
what
to
what
you
know,
the
the
the
pages
are
telling
you
you've
got
a
handle
on
where
to
find
information.
A
Load
of
us
are
at
this
position
and
as
long
as
you're
aware
that
innate
this,
because
this
is
per
skill
as
long
as
you're
aware,
you're,
advanced
beginner,
so
I
know
nothing
about
no
js',
but
I
know
how
to
kick-start
myself
into
those
areas.
That's
cool,
you're
aware,
then
we
move
on
to
the
competent
level.
Now
this
is
where
most
people
stick
actually
so,
but
you
don't
need
to
follow
rules.
You
have
a
mental
model.
You
can
plan
new
routes
into
problems.
You
don't
have
to
do.
A
This
follow
a
road
set
of
steps
and
you
can
also
begin
to
solve
sort
of
unknown
problems.
Things
that
you
really
weren't
expected
all
that
work
outside
your
frame
of
reference
right
now.
The
competent
level
is
a
really
great
place
to
be,
and
it's
where
most
of
us
get
in
most
skills.
I
expect
that
in
all
of
the
things
you
do,
you
are
competent,
congratulations,
you're,
competent!
So
beyond
that,
we
they
observe
the
proficient
level.
A
Now
this
is,
you
know
you
really
beginning
to
become
an
X,
but
you're
really
beginning
to
delve
into
the
the
solitaire
you,
you
know
how
you
can
expect
the
unexpected.
You
can
begin
to
pull
the
information
together
and
a
bit
you
have
a
bigger
world
picture
you
can
interpret
Maxim's,
which
is
so
rather
than
here
are
the
rules
is
how
you
do
something.
This
is
the
this.
Is
the
general
way
this
works?
This
is
this
is
this?
Is
these
are
our
idioms?
A
These
are
the
ways
we
do
things
and
you
can
begin
to
interpret
those
rather
than
just
follow,
follow
set
rules,
and
it
you
build
up
this,
the
tacit
knowledge.
You
know
the
kind
of
stuff
that
isn't
written
down,
but
after
playing
with
a
technology
for
so
long,
you
begin
to
realize
how
it
works.
Those
proficient
guides
the
people
that,
when
they
leave
your
team,
leave
a
hole,
even
if
you
wrote
got
in
to
do
a
big
document,
write
down
everything,
they
know
that
tacit
knowledge
is
what
you
would
lose.
A
That's
why
these
kind
of
guys
leave
a
hole
in
your
team
and
then
finally
get
that
expert,
the
the
guru
guy
and
it's
not
just
he's,
been
doing
it
for
so
long
or
she's,
been
doing
it
for
so
long
they're
an
expert,
but
it's
Authority,
and
you
understand
how
this
particular
technology
ties
into
all
the
other
technologies
in
the
landscape
that
you
work
in
the
important
thing
about
an
expert
now
you're,
really
working
from
intuition.
You
see
a
problem
and
you
just
kind
of
know
how
to
solve
it.
A
You
can't
even
begin
to
enumerate
the
steps
and
well
obviously
I
thought
I'd.
Do
this
then
I'd
do
this
and
then
I
got
to
this
solution.
You
just
the
solutions
just
there
either
you
and
you
guys
know
this.
Yes,
sometimes
you
have
to
think
through
a
problem.
It's
very
complicate,
and
sometimes
you
just
look
a
problem
and
go
yeah.
That's
the
way
to
do
it
and
you
can't
necessarily
explain
why
that's
that's
kind
of
moving
towards
expert
level.
Now.
Why
is
this
important?
Well,
I.
A
Think
it's
interesting
for
two
reasons
for
us
today:
one
it's
really
helpful
to
use
as
a
framework
for
your
learning
if
you're
coming.
If
you
need
to
learn
about
something
new
as
I
say,
a
new
technology
understanding
where
you
are
on
that
scale
helps
you
to
understand
that
you
need
different
information.
So
if
I
know
nothing
about
that,
it's
all
right
to
Google,
find
a
list
of
steps
and
just
follow
them.
A
Slavishly
understanding
that
your
novice,
whereas
if
you're
advanced,
beginner
or
if
you're
competent,
you're
gonna,
be
looking
for
different
kinds
of
information,
you're
going
to
be
asking
different
questions.
Just
being
aware
of
that
is
important.
Also,
eight
teamwork,
because
you
clearly
an
expert
works
in
a
very
different
way
from
a
novice
or
in
fact
no.
You
can
use
this
for
evil.
If
you
pay
a
program,
it's
really
really
good
fun
to
pair
an
expert
with
a
novice,
because
the
novice
doesn't
understand
the
intuition
that
the
expert
has.
A
The
expert
gets
really
frustrated
with
a
novice,
and
if
you
do
it
really
well,
I
can
in
a
fist
fight.
So
you
can
use
this
stuff
for
evil.
So
that
is
the
Dreyfus
model,
and
it's
really.
This
is
a
really
useful
framework
to
work
it
remembering
again
that
it
is
per
skill,
there's
a
load
of
other
sort
of
frameworks.
We
could
talk
about
just
a
couple
of
others
that
are
that
have
some
value
to
us.
How
many
of
you've
read
the
pragmatic
programmer,
a
theory
yep,
it's
a
wonderful
book,
go
read
it.
A
They
have
one
vivid
metaphor:
I've,
given
this
talk
in
in
banks
and
I've
been
really
fearful,
because
I
know
nothing
about
Finance,
but
they
didn't
quite
laugh
me
at
the
bank
that
the
so
the
products
have
this
picture
of
your
working
sense
of
knowledge
as
an
investment
portfolio,
and
you
need
to
tend
that
investment
portfolio.
If
you
just
ignore
it,
it
will
rot
it.
It
will
decay
because
you're
not
you're,
not
sort
of
investing
you're,
not
curating
it
properly.
Now
a
portfolio
has
a
finite
size.
A
There
are
some
things
that
you're
bringing
in,
and
there
should
be
some
things
that
you're
retiring.
You
want
to
make
a
good
spread
of
investments
in
your
knowledge,
so
there
are
some
things
that
are
probably
not
that
risky
and
investments-
hey
JavaScript.
No,
everyone
needs
JavaScript.
However,
it
it's
not
a
risky
investment,
it's
just
if
you,
if
you
learn
that
you
will
have
you'll,
be
on
the
gravy
train
for
life,
it's
a
worth
on
investment.
On
the
other
hand,
there
may
be
some
other
high
risk
investments
that
worth
adding
on
to
that.
A
So
some
areas
that
you
just
have
no
idea
about
all
that
are
just
fledgling
languages
or
new
technology
stacks
that
may
or
may
not
succeed.
But
if
you
invest
your
time
in
them
right
now
to
learn
them,
you
may
have
a
competitive
advantage
over
somebody
else.
You
should
have
a
nice
spread
of
investment
in
your
portfolio
that
the
safe
investments
and
some
higher
risk
investments
and
the
idea
there
is
curate.
Your
portfolio
purposely
take.
Maybe
some
of
those
high
risk
investments
that
didn't
pay
out
out
and
put
something
else
in
its
place.
A
You
got
to
think
about
your
risk
reward
balance
with
what
you've
got
going
on
there
again,
just
doing
that
practically
really
helps
you
to
improve.
Who
knows
what
this
number
is
hours
10,000
hours?
Yes,
it's
kind
of
bunk
to
be
honest
with
you,
but
it's
good
to
wave
your
hands
and
talk
about
of
it.
The
idea
that
10,000
hours
is
the
num
is
the
number
of
hours
of
deliberate
practice
where
deliberate
practice
is
very
different
thing
from
just
playing
deliberate
practice.
A
That's
required
to
become
an
expert
in
something
that
number
was
made
famous
by
Michael
Gladwell
in
the
book
outliers,
but
it
that
came
from
some
research
done
by
K
Anders
Ericsson
in
Berlin,
I
believe
and
what
Ericsson
did
was
studied.
Highly-Skilled
errors,
I
think
it
was
violent.
Yes,
it
was
violinists
I
liked
concert
violinist
and
at
a
musical
Institute
and
what
they
observed
was
the
guys
who'd
invested,
10,000
hours
of
practice
know
since
they
were
knee-high
to
a
grasshopper.
A
Those
were
the
experts,
those
were
the
virtuosos,
the
guys
who
put
8,000
hours
in
and
again,
it's
not
much
difference
really
of
2,000
hours
is
quite
a
lot
of
practicing.
The
violin
frankly,
but
you
know
by
the
time
you're
that
good
you're
probably
doing
any
sleep,
so
that's
fine
ate
that
were
right.
A
Showing
sure-
and
the
thing
that
makes
me
laugh
is
the
four
thousand
hours
people
they
put
down
as
good
enough
to
be
music
teachers,
which
I
think
my
piano
teacher
wouldn't
particularly
like,
but
the
interesting
thing
from
that
study,
and
so
the
number
is
up
for
debate.
Ten
thousand
yeah
I
mean
I,
think
Eirik
s'en
himself
didn't
necessarily
it
is
ten
thousand.
So
it's
what
the
studies
showed
it's
kind
of
the
shape
of
the
problem,
but
it
kind
of
goes
against
in
some
ways
the
the
notion
of
inherent
capability.
A
Some
people
are
just
born
to
be
programmers
and
others
aren't
well
known.
Yet
to
be
an
expert
in
any
field.
You
really
have
to
try.
You
really
have
to
invest
expertise
you
have
to
until
you
have
to
invest
practice,
deliberate
practice,
so
shove
that,
in
your
learn,
C++
been
24
hours,
Pike
and
smoke,
it
frankly
back
10,000
hours.
So
there's
a
debate
over
it,
but
you
know
that's
basically,
three
hours
a
day
for
ten
years.
A
That's
a
lot
of
effort
so
and
their
observation
was
basically
you
know
you
have
to
start
to
be
an
expert
in
something
you
really
have
to
start
practicing
as
a
kid
and
work.
Your
way
up,
all
that
is
saying
is
now.
If
you're
going
to
learn
something
new,
don't
necessarily
set
your
sights
so
high.
You
think
you're
going
to
become
an
expert.
Maybe
you
will,
but
it's
all
right
not
to
be
because
in
order
to
invest
the
amount
of
time
you
would
needs
to
become
an
expert.
A
A
You
get
a
banana,
so
denial,
anger,
bargaining,
depression,
acceptance.
My
observation
is
that
learning
is
like
grief,
they're,
both
better
when
you've
got
over
it,
but
stick
with
me
on
this
one
I've
got
a
problem
of
it.
Herself
I,
don't
know
how
to
solve
it.
I've
got
a
new
technology.
I
need
to
learn
new
problem
denial.
First
of
all,
I,
don't
know,
I,
don't
need
to
learn
about
that
thing.
I
can
solve
the
home
without
it.
No
no
need
it's
going
to
take
too
long.
It's
fine
anger,
no
I
have
to
learn
this
thing.
A
That's
really!
It's
going
to
waste
me
loads
of
time,
I'm
bargaining
right,
okay,
I'm,
going
to
learn
as
a
little
about
that
as
I,
possibly
can
just
to
get
by
depression.
Oh
cripes,
it's
too
big,
I'm,
good,
I'm,
never
learned
all
this
stuff.
Is
it's
gonna.
Take
me
forever.
Wait.
Wait!
Wait,
wait!
Okay,
it's
not
that
bad!
After
all,
now
I
actually
think
that's
a
thing
that
we
go
through,
but
we
do
mini
ones
are
those
daily
and
over
weeks
we
did.
We
do
this
with
we
do
this
all
the
time.
A
This
sort
of
denial,
anger,
bargaining,
depression,
acceptance,
cycle
on
learning,
new
technologies,
as
I
tell
people,
and
one
of
the
guys
in
my
office
when
I
first
said
this
one
I've
just
done
that
today,
I've
gone
through
it
twice
in
one
day.
This
is
like
yeah,
it's
what
we
do,
so
these
are
things
that
we
do,
but
these
are
things
that
we
have
to
do
in
order
to
become
better
okay.
A
So
those
five
six
models
are
the
three
pillars
that
the
rest
of
this
talk
is
based
on,
which
is
what
should
you
learn
now,
so
remembering
that
that
you
understand
your
sort
of
taxonomy
of
learning,
where
you
are
and
skills
and
how
you
need
to
learn
in
those
skills?
What
should
you
learn?
Where
should
you
invest
that
10,000
hours
of
deliberate
practice?
Well,
here
programming
is
such
a
huge
and
vast
field.
This
is
actual
one
of
the
reasons
why
I
love
praying,
there's
always
something
new
to
learn.
A
There's
always
something
differently:
I'm,
never
stuck
in
one
row.
I
never
have
to
just
plow
one
furrow.
Yes,
my
book
is
there,
because,
basically,
this
is
the
point
of
the
book-
was
to
unpack
areas
that
you
can
learn
to
become
a
better
programmer.
So
whilst
it
would
be
easy,
if
you
to
just
buy
it-
and
that's
you
know
that
save
you
ten
thousand
hours,
clearly
the
areas
that
I
identified
there,
that
as
programmers,
we
can
invest
an
effort
in
writing
code,
clearly
the
practice
of
programming,
personal
skills
and
how
we
work
with
others.
A
So
by
writing
code
and
here's
the
thing
as
I
just
sort
of
run
through
a
list
of
a
few
things
think
which
of
these
may
apply
to
you
the
most
right
now.
Are
there
some
things
you
think
yeah
I've
got
that
down?
Pat,
that's
fine,
but
there
are
some
things
that
you
think
I
could
invest
some
time
in
that,
like
code
presentation,
avoiding
a
necessary
complexity,
writing
robust
code
working
with
familiar
code,
good
design,
removing
Co
handling
air
as
well.
All
this
con
stuff,
the
act
of
writing
physical
lines
of
code.
This
is
our
bread.
A
This
is
our
butter.
This
is
what
we
do
day
in
day
out,
if
you're
not
purposefully,
investing
effort
into
trying
to
do
that.
The
best
you
can
identify
areas
that
you
know
I'm
good
here,
but
I'm
a
bit
weak.
There
I'll
put
some
time
in
I'll,
try
to
learn
from
some
other
people,
then
you're
not
doing
yourself
a
service.
Basically,
so
then
we
said
why
do
the
practice
of
programming
those
things
rather
than
just
the
lines
of
code,
but
the
ways
the
way
is
the
techniques
that
we
fit
around
them.
A
The
development
practices,
the
the
skills
that
the
sort
of
the
the
way
we
work
is
a
tribe.
So
knowing
kind
of
what
the
software
development
really
is,
it's
not
playing
with
code.
It's
something
so
much
bigger
how
to
use
your
brain,
how
to
solve
problems
in
a
sensible
way,
rather
than
just
running
a
problem,
and
just
going
for
the
first
Ellucian
that
occurs
to
you
effectively
to
version
control.
A
Some
people
work
github,
okay,
cool
some
people
suck
at
this
kind
of
thing,
ideas
of
working
with
QA,
for
example,
treating
them
as
equals,
not
as
a
team
leave
throw
code
over
the
wall
to
them
fully
embedded
code
reuse.
What
does
it
really
mean?
Is
it
something
that
we
that
we
just
try
to
build
in?
We
first
write
a
piece
of
code,
or
is
it
something
that
emerges
ways
of
making
good
software
releases
the
tribal
skills
inside
your
organization?
A
All
those
kind
of
things
are
another
whole
area
that
we
need
to
focus
on
and
purposefully,
invest,
effort
and
time,
then
personal
skills
how
to
learn.
So
this
is
kind
of
what
this
talk
is
about,
how
to
actually
learn.
If
you,
if
you
don't,
have
a
framework
that
you
can
gather
knowledge
and
take
new
knowledge
in
with
then
you
know,
I've
read
about
offer
ghosts,
acting
ethically
seriously.
That's
an
interesting
one
for
the
programmers
and
was
one
of
the
reasons
my
book
got
commissioned
how
to
how
to
so
how
to
soul
problems?
A
A
A
But
it's
how
you
deal
with
conflict,
you
don't
you
can
you
can
treat
conflict
as
as
a
source
for
good
as
a
way
to
get
to
better
designed
as
a
way
to
work
better
together
or
it
could
just
be
the
worst
thing
if
you
could
destroy
your
team
and
then
ultimately
ruin
your
software
project.
So
there
we
go
so.
A
That's
that's
just
me,
seeing
a
whole
load
of
stuff.
We
haven't
looked
at
anything
in
particular
and
basically,
in
the
time
we've
got,
I
can't
unpack
a
whole
load
of
things.
Have
it?
Let's
just
look
at
a
few,
perhaps
understanding
that
again,
we
know
how
we
learn.
We
have
this
model
and
we
desire
to
get
better.
We
desire
to
program
better
and
with
my
underlying
thing,
but
it's
it's.
The
attitude
rule
that
we
do
these
as
well,
rather
than
just
some
kind
of
techie
thing.
I'll
just
learn
this
and
Annalee
better.
A
A
few
little
areas
that
are
worth
thinking
about.
First
is
writing
less
code
and
two
programmers.
This
seems
like
an
oxymoron.
Why
would
on
a
write,
less
code,
but
no,
it's
perfectly
possible
to
write
less
code
and
to
have
more
software.
Do
agree
with
me
that
we
work
with
so
many
people.
That's
a
right
so
much
boilerplate,
so
much
scaffolding.
So
many
rapid,
pointless
comments
that
just
got
in
the
way,
so
many
bits
of
woefully
pointless
logic
that
just
could
have
been
reduced
to
a
simple.
A
You
know
virtual
dispatch
on
it
on
a
function
or
something
we
can
use
our
tools
better
right,
fewer
lines
of
code
where
there
are
fewer
bugs
and
have
more
software.
That
is
something
we
should
strive
for
definitely
a
case.
One
of
those
things
are
working,
smarter,
not
harder,
so
cool,
then
the
ninja
level
beyond
that
is
improving
code
by
removing
it.
A
How
many
people
are
delighted
when
they
remove
code
and
make
things
better,
yeah
you're
with
me
just
the
other
day,
I
took
some
code
from
a
BART
coder
hundreds
of
lines
of
the
staffs
spaghetti
logic
thought
this
was
for
loading
files.
It
defined
virtual
hierarchies
of
things
and
families
of
file
classes
and
pre
file,
loading,
callbacks
and
post
file
loading
callbacks.
It
was
all
unused,
pointless
rubbish,
removed
the
whole
lot,
replace
it
with
three
functions:
low
day's,
low
file,
a
low
file,
B
load
files.
C.
A
When
you
can
read
the
code,
you
could
actually
that
we've
removed
a
whole
load
of
bugs
in
the
process,
so
yeah
improving
code
by
removing
knowing
and
so
then
we
think
about
the
attitude
knowing
when
to
do
it,
how
to
do
it
well
and
the
attitude
we
have
to
the
coder.
Who
did
that?
Were
they
an
imbecile
who
wrote
stupid
code?
Who
I
should
then
look
on
with
derision
and
despair
or
were
they
less
experienced?
A
Maybe
they
were
an
advanced
beginner
and
didn't
know
better,
or
maybe
they
were
solving
a
problem
that
was
about
to
exist.
They
wrote
the
code
and
then
for
various
reasons
that
project
that
so
the
reason
for
it
went
away.
So
there's
your
attitude
thing:
how
do
you
deal
with
that?
G
write
a
Rin,
snotty
checking
message
saying:
remove
this
crap?
A
A
Now
here's
the
thing
you
may
not
know
this
software's
quite
complicated
yeah,
that's
why
we
pay
the
mega
bucks.
Yet
there
are
kind
of
two
commits
of
two
types
of
complexity
in
software.
There
is
the
necessary
complexity
that
is
the
bit
that
we
paid
the
mega
box
for
and
kind
of
in
the
same
way
as
those
meaningless,
woefully
pointless
lines
of
code.
A
Appropriately
complex
design
solves
the
problems
of
gear,
gives
you
a
framework
and
an
ability
to
defer
unnecessary
complexity.
The
problems
you
may
not
need
to
solve
complexity
manifests
and
many
levels
in
lines
of
code
in
the
designs
of
our
class
hierarchies
and
the
global
scale
in
the
architecture.
So
here's
a
suggestion,
strife
and
simplicity,
but
again
this
is
the.
This
is
the
experience
this
is.
This
is
what
we
learn
as
we
go
through
the
programming
game.
A
If
you
just
go
for
simplicity,
if
you
just
aim
for
simplicity,
you
might
you
might
miss
and
get
simplistic,
and
it's
understanding
that
where,
yes,
you
don't
want
to
write
needlessly
general
code
or
implement
features
that
aren't
needed
right
now
and
may
never
be
needed.
On
the
other
hand,
if
you
omit
something,
that's
really
important
or
do
a
slightly
bad
job
because
it
was
going
to
get
too
complicated
for
me,
then
you
end
up
with
simplistic
code.
A
You
get
code
that
doesn't
work
and
again
learning
to
understand,
identify
and
and
have
a
feel
for
that
kind
of
stuff.
Sometimes
it's
intuition,
and
sometimes
it's
something
you
really
have
to
work
on.
How
good
are
your
that
kind
of
stuff
think
about
the
Dreyfus
model?
So
where
do
you
sit
in
this
sort
of
area
of
skill
in
this
area
of
programming?
A
Maybe
up
there,
maybe
down
here
another
one.
Now
this
this
is
cool
and
it's
very
unpro
grammar
the
art
of
good
communication
programming
is
all
about
communication.
Yeah
code
is
communication,
we're
talking
to
the
compiler
to
tell
it
what
to
do
or
to
the
interpreter
to
tell
her
what
to
do
to
the
scripting
engine
to
tell
her
what
to
do,
but
we're
also
talking
to
other
Prohm
is
explaining
how
the
system
works
and
where
we're
going
forward
and
how
they
can
extend
this
code.
We're
also
talking
to
ourselves
10
years
down
the
line.
A
A
Do
you
understand
how
the
different
communication
mediums
sort
of
play
out
once
it
better
to
codify
something
in
well
literally
to
codify
something
in
the
code
to
put
it
in
comments
or
documentation?
Next
to
the
code?
When
is
it
appropriate
to
have
a
conversation
in
email?
When
is
it
more
appropriate
to
use
Skype
or
to
phone
someone
up
when?
Is
it
more
appropriate
to
go
around
to
someone's
desk
with
a
baseball
bat?
A
You
know,
there's
different
communication
mediums
and
it's
genuinely
a
skill
to
use
the
right
one
in
the
right
context,
to
talk
to
people
in
the
right
way
as
well
with
respect,
but
clearly
something
you
need
to
get
problem
solved
and
I
know
some
guys,
you
just
kind
of
steamroller
in
there
and,
like
guns,
blazing
up
to
the
desk
and
you're
never
going
to
get
to
a
solution.
You
know
going
to
solve
a
problem.
You
never
come
to
collaboratively
work
together,
who's,
not
showing
respect
you're,
not
listening.
A
Handling
Mexico
I
find
this
one,
a
good,
a
good
example
again
of
the
programmer
attitude
and
how
how
it
affects
what
you
do.
John
Paul
Sartre
almost
said
hell
is
other
people's
code
yeah.
How
often
do
you
pick
up
some?
You
know
you
check
out
a
project
you
looking
and
go.
Oh
I
can
probably
use
it,
but
I
want
to
done
it
like
that.
In
fact,
if
I'm
going
to
use
it,
I
have
to
rewrite
the
whole
lot.
A
Maybe
you
do
but
then
again,
maybe
as
soon
as
you
do
that,
what's
the
judgment
call
you
make,
do
you
look
at
the
other
coder?
Did
you
or
do
you
look
down
on
the
other
code
again?
Do
you
think
imbecile
I
could
do
that
better?
Maybe
you
can't
do
that
better,
maybe
there's
a
good
reason
for
it
to
be
in
the
shape.
It
is
in,
don't
make
snap
judgments,
but
then
once
you've
done
that,
do
you
replace
the
code
wholesale?
A
There
are
many
approaches
you
could
take
and
the
right
approach
would
be
dependent
on
the
context
and
that
we
depend
on
your
experience
and
your
maturity
and
your
attitude.
It's
collaborative
working
to
get
the
best
software
possible
to
work
as
a
team
as
best
as
you
can,
thanks
to
my
last
one,
avoiding
stagnation.
A
Now
you
guys
I
mean
this
is
what,
when
the
kind
of
the
audience
that
comes
to
a
conference
that
wants
to
learn
about
stuff
you're,
not
the
guy
at
the
moment,
a
likely
to
stagnate.
You
want
to
learn
new
stuff.
You
want
to
exchange
ideas.
You
want
to
meet
up
with
other
coders.
You
want
to
be
fired
up.
You
want
to
be
engaged
and
encouraged
to
keep
going
in
this
cool
career
that
we've
got
awesome.
On
the
other
hand,
you
do
kind
of
have
to
be
aware
that
some
days
are
better
than
others.
A
A
Maybe
you're
deliberately
practicing
some
really
techie
kind
of
complicated
skill.
Ask
boring
the
pants
off
of
you
now
and
yet
it
hasn't
become
fun
anymore.
You
really
even
make
the
promise
yourself.
You
want
to
learn
this
thing,
but
it's
becoming
a
drag.
Maybe
that's
you
know
you
leaving
you
to
be
in
dangerous
sort
of
falling
out
of
love
with
programming.
Maybe
it's
time
to
reassess.
Maybe
it's
time
to
change.
A
Look
at
something
else,
it's
kind
of
all
about
being
passionate
about
loving
what
you're
doing
I
genuinely
believe
that's,
but
so
those
kind
of
attitudes
that
define
good
programmers,
the
humility,
the
the
caring
back
coding,
the
wanting
to
work
well
together,
one
of
the
key
ones
is
being
passionate
about
what
you're
doing
desperately
loving
to
write
the
best
code.
You
can
because
that's
the
that's
your
source
of
enjoyment,
that's
your
source
of
engagement,
whatever
you
can
do
to
stoke
the
passion
drinking
with
other
coders
is
a
great
one.
A
We've
looked
at
some
areas
due
to
the
wide
gamut
of
areas
that
we
could
become
better
in
and
I'd
like
you
to
sort
of
genuinely
walk
away
and
think
about
some
specific
things.
Thinking
some
specific
area
get
better
it
and
we
sort
of
shot
through
some
specific
ones
as
well,
but
as
I
say,
here's
the
thing
Oh
another
eminently
quotable
person.
You
know
you
can
I
think
most
every
quote
on
the
internet
probably
attributed
to
Albert
Einstein
at
some
point
or
other.
A
A
Every
talk
should
have
a
quote
from
dr.
Zeus,
because
dr.
Zeus
is
cool.
The
more
that
you
read
the
more
things.
You'll
know
the
more
that
you
learn.
The
more
places
you'll
go.
Learn,
learn,
learn
remembering
this
all
about
attitude.
So
this
good
attitude
as
we're
learning
shapes
your
code.
It
shapes
your
trick,
career
trajectory.
It
shapes
your
team.
It
shapes
what
you're
doing
so.
We're
aiming
for
it's
healthy
attitudes
that
foster
a
a
real
desire
to
learn
to
be
better
to
work
better
to
craft,
better
code.
A
Chinese
proverb
learning
is
like
rowing
upstream,
not
to
advances
to
drop
back.
If
you're,
not
learning.
If
you're
not
trying
to
improve
yourself,
you
are
dropping
back.
You
are
going
to
stagnate,
you're
going
to
become
a
code
dinosaur
I'm,
going
to
be
quite
cool
to
be
Stegosaurus,
I
suppose,
but
you
don't
to
be
a
code
dinosaur
whatever
I
say
so
again,
I
ask
you
genuinely
do
you
desire
to
become
better?
Do
you
want
to
work
better?
Do
you
want
to
write
better
code?
Is
that
is
that
what
you
want
to
do?
A
What
kind
of
areas
you've
been
to
this
company
you've
seen
a
whole
load
of
different
technology
whole
lot
of
different
things.
Some
of
those
things
you
you're,
not
a
novice
in
some
other
things,
you're
an
advanced
beginner
or
you're
competent.
Those
are
the
things
you
know
about.
It
was
interesting,
it
was
informative,
but
it
wasn't
new.
Some
of
those
areas
were
entirely
novel
to
you.
Some
other
mill
of
piqued
your
interest
invested
in
the
knowledge
portfolio.
Look
at
some
of
those
things
and
go
right.
That
looks
cool
science.
A
Hacks,
that's
cool
I'm,
going
to
do
that,
some
things
you
need
to
retire
from
a
portfolio
so
consciously
retire
them
remembering
that
this
is
sort
of
per
skill
in
the
competence,
so
think
about
some
things.
Maybe
from
this
conference
that
over
the
last
two
days,
your
novice
in
and
commit
to
putting
some
time
to
learn
more
about
it.
A
A
You
have
to
do
this.
I
can
I
can
sound,
enthusiastic
and
I
can
talk
about
learning
and
stuff,
but
unless
you
engage
it
unless
there's
a
specific
thing
that
you
want
to
do
that,
you
identify
that
you
can
do
and
you
commit
to
doing
it.
Then
it's
just
been
a
talking
with
words.
So
another
suggestion
to
help
you
sort
of
put
wheels
on
this
become
a
countable
so
on
in
to
improve
in
that
skill
level.
So
say:
I
want
to
improve
in
in
teamwork,
I
think
I,
don't
listen
to
people
well
enough.
A
I
realize
that
I'm
going
to
become
accountable
to
someone
I'm
going
to
say
right.
This
is
narrow.
I
want
to
work
in
I
want
to
learn
in
a.
If
you
see
me
not
working
well
here.
Tell
me
and
be
ask
me
in
a
month's
time
what
I've
done
about
it?
Accountability
will
really
help
you
improve
in
here.
So
skip
those
again,
it's
just
it's
this
practical
question:
what
are
you
going
to
do
now?
What
are
you
going
to
do?
A
A
Now,
I've
got
no
idea
if
the
nurse
runs
in
the
UK
translate
to
the
US
I'm,
really
hoping
they
do,
or
this
isn't
going
to
work,
but
some
premise,
my
daughter:
she
needs
to
go
to
sleep
and
you
know
I
need
to
teach
her
to
code,
so
Kersal
mary
had
a
little
lamb.
Do
you
guys
know
that
cool?
Okay?
This
is
how
it
goes.
Mary
had
a
little
lamb
de
his
function
was
pure
but
slow
and
everywhere
that
mary
applied
it.
The
lambda
was
sure
to.
A
Eventually,
return
a
result:
now
you
kind
of
get
the
idea
you
kind
of
get
where
this
is
going
here.
One
more-
and
this
is
this
is
this-
is
why
this
is
what
I
want
to
try.
Humpty
Dumpty
this
works
as
well,
yeah
cool
and
you
sang
I
heard
you
sing.
So
here
we
go
I
need
you
to
sing
along
with
me.
Okay,
you
game,
yeah,
Humpty,
Dumpty
Bilco
with
all,
but
Humpty's
code
was
not
clean
at
all.
All
the
teams
code
is
both.