My talk from Conferencia Rails in Madrid Spain, in pdf format with my notes included.

1. Hola,
thank
you
for
having
me
here
today!
I’m
going
to
be
telling
you
a
story,
my
story.
I
hope
you
get
something
out
of
it,
and
if
not
I
hope
it
amuses
you.
Before
I
tell
you
about
myself,
I’m
going
to
ask
you
some
ques>ons.
I
know!
Audience
par>cipa>on
at
a
soBware
conference,
how
awful
of
me!
And
just
before
lunch
too!
Don’t
worry
they
are
not
ques>ons
about
food!
Also,
everyone
has
heard
the
term
“code
smell
before
right?”
1

2. Just
for
fun,
how
many
of
you
are
rock
climbers?
2

3. Like
Rails!
Especially
ones
that
follow
or
teach
us
maintainable
paNerns
and
prac>ces
of
ways
to
structure
code.
3

4. What
is
at
the
end
of
the
Road?
What’s
the
light
at
the
end
of
the
tunnel?
I
love
descrip>ve
analogies,
especially
ones
that
come
with
a
picture
of
a
dog!
So
which
is
it?
I
think
I
made
this
preNy
obvious,
but
just
in
case.
4

5. What
is
this?
This
is
my
story.
I’m
going
to
be
telling
you
about
my
experiences
with
code,
the
Good,
the
Bad
,and
the
Goofy!
This
explains
my
ques>ons.
I
was
wondering
who
out
there
has
a
similar
background
to
mine.
I
went
to
university
for
computer
science,
I
worked
as
a
business
consultant
doing
custom
development
in
the
MicrosoB
stack,
and
now
I
work
as
the
lead
Ruby
developer
for
Blue
Box
Group.
I’ve
worked
with
lots
and
lots
of
code
of
different
varie>es,
and
each
of
the
three
different
places
where
I
have
wriNen
and
had
to
maintained
code
I’ve
learned
something
different
about
what
makes
for
good
code
and
what
makes
for
bad
code.
Using
my
hound
sniffing
analogy,
you
can
say
my
code
sniffing
ability
grew
with
each
step
of
my
journey.
5

6. At
university
I
did
a
lot
of
java
and
C
programming
Though
we
were
using
java
to
learn
about
objects,
most
of
the
code
I
wrote
and
learned
from
was
procedural
in
nature
and
had
lots
of
condi>onals:
A
situa>on
I
like
to
refer
to
as
if-­‐else-­‐death.
Working
with
teams
was
vile,
Tests
were
unheard
of
And
I
rarely
every
looked
at
code
that
was
quote
”finished”
–
ie:
code
for
a
completed
assignment
(in
fact
I
had
trouble
finding
code
from
that
>me
to
make
this
awful
picture
of
java
code
for
this
talk)
So
with
my
dog
analogy:
a
dog
with
a
refined
sniffer
at
this
point
would
look
at
my
code
and
need
a
gas
mask….
6

7. So
what
did
I
learn
about
code
from
University?
Of
course
I
learned
the
basics:
how
to
solve
a
programming
problem
(don’t
underes>mate
this!)
<Read
1st
bullet>
unless
I
interview
with
Google
(linked
list,
Back-­‐Tracking
Search,
Bubble
Sort,
etc…)
I
did
ACM
compe>>ons,
Top
Coder
compe>>ons,
etc…
I
certainly
got
skills
from
doing
that,
but
they
were
not
skills
about
how
to
create
maintainable,
and/or
scalable,
applica>ons.
I
was
a
CS
TA
for
3
years,
and
found
teaching
to
be
the
best
way
for
me
to
learn
myself.
(Not
really
anymore…)
I
really
loved
javadoc
when
I
got
out
of
school,
I
thought
that
was
the
best
and
only
way
to
document
code!
How
awesome
is
that,
something
creates
docs
right
from
your
comments!
HAHA
ok
enough
with
the
java
already!
This
is
a
RoR
conf!
7

8. So
what
am
I
going
to
talk
about
next?
C#...
As
a
consultant,
one
of
my
favorite
projects
was
building
a
financial
forecas>ng
system
for
a
very
large
organiza>on
from
scratch
in
C#
.Net.
It
was
a
service
oriented
web
applica>on
that
was
going
to
save
all
of
their
financial
analysts
tons
and
tons
of
>me.
We
used
the
Windows
Workflow
Founda>on
framework
for
structuring
the
app.
Anyone
familiar
with
the
WWF?
Hehe
I
like
to
refer
to
that
acronym
because
it’s
reference
to
the
world
wrestling
federa>on
is
appropriate
–
It’s
a
big
show,
and
very
few
people
get
hurt.
We
had
lots
and
lots
and
lots
of
code.
But
it
wasn’t
horrible
code,
it
was
very,
very
structured
code.
Everything
with
a
similar
purpose
was
grouped
together,
you
knew
where
to
look
for
a
par>cular
ac>on,
naming
conven>ons
and
code
paNerns
for
methods
were
strictly
enforced….
Even
when
they
didn’t
really
make
sense…..
Our
hound
in
this
picture
is
just
sneezing,
he’s
not
terribly
sick,
but
this
somewhat
nicely
paNerned
behemoth
of
code
never
actually
went
into
produc>on…
Also,
our
“test
suite”
was
actually
a
team
of
testers
with
scripts
they
would
run
through
any
>me
the
app
changed.
That
is
preNy
typical
big
corpora>on
waste
from
what
I
have
seen.
8

9. So
What
did
I
learn
about
code
here?
Consistently
adhering
to
paNerns
makes
code
wriNen
by
different
team
members
separately
adhere
together
nicely.
I
certainly
learned
about
single
responsibility
and
abstrac>ons,
but
there
were
paNerns
beaten
into
me
that
never
really
clicked:
Always
make
your
if
statements
posi>ve,
and
you
must
always
have
an
else
when
there
is
an
if.
What?
Why?
Well
now
I
can
say
I
understand
that
if
you
have
an
if,
you
are
branching
your
code,
and
puong
the
else
there
makes
that
other
branch
explicit,
therefore
giving
someone
who
comes
aBer
more
informa>on
about
what
your
code
does.
I
can
see
the
argument,
but
I
would
say
now
get
rid
of
the
branch
and
use
polymorphism
–
objects
are
your
friends!!!
But
again,
this
wasn’t
Ruby,
the
framework
wasn’t
Rails,
and
this
was
enterprise
level
business
prac>ces
–
a
much
more
restric>ve
environment
than
most
of
us
in
the
RoR
community
work
in.
9

10. So
what
was
next?
Ruby!
Rails!
Legacy
Code?
Best
way
to
understand
OO
design
principles
is
to
work
with
code
that
doesn’t
follow
any.
But
it’s
a
rails
app,
it
has
MVC
structure
and
separa>on
of
concerns
at
those
layers,
right?
The
model
I’ve
excerpted
here
has
2,533
lines
The
dog
in
this
picture
says
it
all….
So
what
do
you
do?
This
is
produc>on
code,
that
the
business
and
the
customers
depend
on.
There
are
bugs.
(Did
I
really
need
to
say
that?)
but
really
there
are
bugs
that
need
fixing
and
feature
requests
that
need
implementa>on.
You
goNa
deal
with
it,
you
goNa
do
it
–
That’s
how
I
learned
to
smell
code.
10

11. make
sure
there
are
tests!
–
Get
the
business
requirements
(AGAIN)
from
the
end
user
–
if
it
works
in
produc>on
that
does
not
mean
“don’t
change
it”,
that
means
“Good
the
end
users
know
the
business
process,
and
we
can
easily
re-­‐capture
what
this
cluster
is
trying
to
do,
and
re-­‐do
it
beNer”.
11

12. All
of
my
first
code
looks
like
C#,
because
that’s
the
last
language
I
knew,
and
there
weren’t
any
good
paNerns
to
follow.
I
fought
with
Rails
about
how
it
structures
data
–
I’m
a
db
girl,
who
all
of
a
sudden
isn’t
supposed
to
worry
about
the
database
anymore….
When
I
found
myself
wri2ng
just
as
nasty
(in
terms
of
maintainability)
code
I
looked
for
help.
12

13. 13

14. Rails
paNerns
are
geong
beNer
and
beNer:
Coffee
Script
–
makes
our
js
less
smelly
–
and
there
will
be
emerging
new
paNerns
here
for
maintaining
all
the
gobs
of
client
side
code
we
are
all
wri>ng
14

15. I
talked
about
paNerns
to
follow
–
here
I’m
talking
about
not
following
a
paNern
–
when
you
follow
an
an>-­‐paNern
you
will
learn
something
–
work
with
someone
else
who
has
a
different
paNern
and
learn
together
with
them.
The
least
smelly
programmers
are
pair-­‐programmers
15

16. If
you
have
never
seen
the
anit-­‐paNerns
or
code-­‐smells
talked
about
here,
they
may
not
click,
but
then
re-­‐read
it.
This
is
a
reference
manual,
not
a
one-­‐>me-­‐read.
16

17. Same
idea
here
–
this
book
is
men>oned
in
Clean
Code
–
read
all
the
books
in
clean
code’s
bibliography
–
I
have
not
goNen
through
all
of
them
yet.
17

18. Lastly
–
pick
up
a
hobby
–
you
learn
really
cool
things
about
what
you
do
everyday
when
you
do
something
else.
From
Rock
climbing
I’ve
learned
this
about
OO
design
paNerns:
It’s
like
learning
to
belay
–
you
learn,
you
become
a
good
belayer,
It
becomes
muscle
memory,
but
you
don’t
really
get
it,
un>l
one
day
it
clicks
–
you’ve
caught
lots
of
falls,
you’ve
both
lead
climbed
and
caught
a
leader
fall
–
you
get
how
the
system
works
and
why
the
paNern
/
the
rules
you
follow
are
there.
That
is
when
you
can
evolve
and
modify
the
system.
You
know
when
to
follow
the
paNern
and
when
to
improvise.
Do
this
with
your
code
and
help
others
do
it
–
follow
a
couple
good
design
paNerns,
make
them
muscle
memory,
and
one
day
it
will
click,
and
then
you
can
evolve
your
own
paNerns
that
will
push
the
field
forward.
–
If
you’ve
followed
lots
of
good
paNerns,
you
will
know
how
to
make
a
good
new
one.
18

19. Not
everyone
has
the
same
experiences
you
do,
some>mes
you
need
to
write
a
bit
of
C#
in
ruby
to
figure
out
that
ruby
shouldn’t
be
wriNen
that
way.
I’ve
found
that
these
three
things
that
are
about
learning
and
flexibility
are
more
important
to
crea>ng
scentless
code
than
anything
else.
For
#
4
:
It’s
my
pet
peeve
–
I’m
allowed
one
soap-­‐box
per
talk,
and
this
is
it.
every
point
in
Chapter
17
(smells
and
heuris>cs)
that
is
made
about
comments
is
100%
true.
I’ve
seen
all
of
them,
I’ve
done
a
number
of
those
things
with
comments
myself.
JUST
STOP!
Make
your
code
document
itself,
no
one
who
comes
aBer
you,
who
changes
what
your
code
does,
will
update
your
comments,
but
they
will
update
your
names
and
method
signatures.
And
trust
your
source
control
–
use
Git
for
your
comments
–
it’s
a
much
beNer
place
for
them.
All
of
us
think
about
the
appropriate
place
for
our
code
to
go,
think
about
the
appropriate
place
for
your
comments.
19

20. 20