Slide 1
Slide 1 text
break
nothing
move fast
&
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
Move fast and break things
— Mark Zuckerberg, Facebook
“ ”
Slide 4
Slide 4 text
Move fast and fix things
— Mark Zuckerberg, Facebook
“ ”
Slide 5
Slide 5 text
Move fast with stable infra
— Mark Boringberg, Facebook
“ ”
Slide 6
Slide 6 text
Move fast and be bold
“
— Miguel Velazquez, Facebook
”
Slide 7
Slide 7 text
Drop the ‘the’ — it’s cleaner.
“
— JUSTIN TIMBERLAKE SWOOOOOON
”
Slide 8
Slide 8 text
good philosophy
moving quickly and safely is
Slide 9
Slide 9 text
what does it mean
in practice?
Slide 10
Slide 10 text
@ holman
Slide 11
Slide 11 text
@ holman
!
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
got me thinking about
building environments
where
success
is a byproduct
Slide 15
Slide 15 text
code
3 areas
, process& talk
Slide 16
Slide 16 text
code
Slide 17
Slide 17 text
move fast
Slide 18
Slide 18 text
people like fast
better product
Slide 19
Slide 19 text
people like fast
see what works
Slide 20
Slide 20 text
people like fast
momentum
Slide 21
Slide 21 text
break things
and
Slide 22
Slide 22 text
break things
fix later and… stuff
and
Slide 23
Slide 23 text
some things
you can’t
break
Slide 24
Slide 24 text
billing· permissions
· upgrades· migrations
Slide 25
Slide 25 text
how do you
move fast
in dicey code?
Slide 26
Slide 26 text
we redid github’s
permissions code
Slide 27
Slide 27 text
hella scary.
Slide 28
Slide 28 text
.01% errors
unacceptable
=
Slide 29
Slide 29 text
0 errors
mandatory
=
Slide 30
Slide 30 text
how do we ship this
fast + safe?
Slide 31
Slide 31 text
tests are great,
of course
Slide 32
Slide 32 text
production can differ
from what your tests expect
Slide 33
Slide 33 text
production can differ
from what you even expect
Slide 34
Slide 34 text
ensure that your code
doesn’t change production behavior
Slide 35
Slide 35 text
parallel
codepaths
Slide 36
Slide 36 text
request
Slide 37
Slide 37 text
user.old_code
always gets run
request
Slide 38
Slide 38 text
user.new_code
also gets run
request
user.old_code
always gets run
Slide 39
Slide 39 text
user.new_code
also gets run
request
user.old_code
always gets run
response
Slide 40
Slide 40 text
run both,
compare
Slide 41
Slide 41 text
/github/dat-science
p
Slide 42
Slide 42 text
science “new-auth” do | e |
e.control { user.slow_auth }
e.candidate { user.fast_auth }
end
Slide 43
Slide 43 text
science “new-auth” do | e |
e.control { user.slow_auth }
e.candidate { user.fast_auth }
end
always runs and
returns your result
Slide 44
Slide 44 text
can be run as
a percentage
science “new-auth” do | e |
e.control { user.slow_auth }
e.candidate { user.fast_auth }
end
Slide 45
Slide 45 text
collects the
two results
science “new-auth” do | e |
e.control { user.slow_auth }
e.candidate { user.fast_auth }
end
Slide 46
Slide 46 text
attempts vs. mismatches
Slide 47
Slide 47 text
75th and 99th percentile performance
Slide 48
Slide 48 text
quickly iterate
until you can
prove safety
Slide 49
Slide 49 text
existing process
build into your
Slide 50
Slide 50 text
what do you have today
that you can already use?
Slide 51
Slide 51 text
each layer of
process added
is expensive
Slide 52
Slide 52 text
instead grow
process laterally
Slide 53
Slide 53 text
tests rule everything
around me
Slide 54
Slide 54 text
ci as code
maintenance
Slide 55
Slide 55 text
failing test:
removing html class
without cleaning css
Slide 56
Slide 56 text
failing test:
removing css without
removing html class
Slide 57
Slide 57 text
failing test:
adding ![]()
that’s
not on our cdn
Slide 58
Slide 58 text
failing test:
invalid css (scss linting)
Slide 59
Slide 59 text
automates gruntwork
out of code review
Slide 60
Slide 60 text
we test blog posts, too
Slide 61
Slide 61 text
failing test:
images off our cdn
Slide 62
Slide 62 text
failing test:
image non-retina
or too big
Slide 63
Slide 63 text
failing test:
using an oft-used
phrase
Slide 64
Slide 64 text
pro-
cess
Slide 65
Slide 65 text
what’s
important?
Slide 66
Slide 66 text
feature launches need:
· designers
developers
· product managers
· qa
· lawyers
· marketing· ops
Slide 67
Slide 67 text
text files
are rad
Slide 68
Slide 68 text
Slide 69
Slide 69 text
anpp
(apple new product process)
Slide 70
Slide 70 text
(apple new product process)
giant-ass
checklist
anpp
Slide 71
Slide 71 text
(apple new product process)
lists at tim-level
and small team-level
anpp
Slide 72
Slide 72 text
(apple new product process)
happens as
very first step
anpp
Slide 73
Slide 73 text
d
Slide 74
Slide 74 text
d
ship lists
Slide 75
Slide 75 text
d
ship lists
happens often
as last step
Slide 76
Slide 76 text
d
ship lists
all the todos for
teams for their +1
Slide 77
Slide 77 text
No content
Slide 78
Slide 78 text
simple todo lists
make you think less
Slide 79
Slide 79 text
ownership
Slide 80
Slide 80 text
don’t throw code
over the wall
Slide 81
Slide 81 text
tie code to writers
d
Slide 82
Slide 82 text
tie code to writers
d
notifies you
if you screw up
Slide 83
Slide 83 text
No content
Slide 84
Slide 84 text
authors know
their own code
Slide 85
Slide 85 text
authors should
fix their bugs
Slide 86
Slide 86 text
how can
your process
help out?
Slide 87
Slide 87 text
tie code to writers
Slide 88
Slide 88 text
tie code to writers
Slide 89
Slide 89 text
tie code to writers
chrome has
owner files
Slide 90
Slide 90 text
tie code to writers
dictates
responsibility
Slide 91
Slide 91 text
tie code to writers
makes
mentors visible
Slide 92
Slide 92 text
tie code to writers
d
Slide 93
Slide 93 text
tie code to writers
d
per-file
ownership
Slide 94
Slide 94 text
tie code to writers
d
class BranchesController
areas_of_responsibility :git
end
Slide 95
Slide 95 text
No content
Slide 96
Slide 96 text
No content
Slide 97
Slide 97 text
tie code to writers
d
issues get assigned
to the appropriate team
Slide 98
Slide 98 text
talk
Slide 99
Slide 99 text
more
communication!
yayyyyyyyycrap
Slide 100
Slide 100 text
email
meetings
chat
issues
im
on-call
video
al
Slide 101
Slide 101 text
more is good
better is better
Slide 102
Slide 102 text
most things
aren’t emergencies
Slide 103
Slide 103 text
most things
aren’t emergencies
be mindful of time
Slide 104
Slide 104 text
measure impact
of your actions
be mindful of time
Slide 105
Slide 105 text
imagine:
Slide 106
Slide 106 text
1. page a coworker for help
2. they get woken up
3. their phone takes a selfie of them
4. selfie gets posted into chat
Slide 107
Slide 107 text
No content
Slide 108
Slide 108 text
would this make you respect
your coworker’s time more?
Slide 109
Slide 109 text
add empathy to
your process
Slide 110
Slide 110 text
empathy
stems from being
exposedto real pain
Slide 111
Slide 111 text
everyone should
do some support
Slide 112
Slide 112 text
there’s a difference
between
reading about it
helping with it
&
Slide 113
Slide 113 text
institutional
teaching
Slide 114
Slide 114 text
[we] have a responsibility to
be teachers—that this should
be a central part of [our] jobs
“
— Ed Catmull, Creativity, Inc.
Slide 115
Slide 115 text
…it’s just logic that someday
we won’t be here.
— Ed Catmull, Creativity, Inc.
”
Slide 116
Slide 116 text
more productive
if workers are smart
Slide 117
Slide 117 text
how do you teach
without making it lame?
Slide 118
Slide 118 text
chatops:
learning by osmosis
Slide 119
Slide 119 text
app crashes. here’s a normal flow:
Slide 120
Slide 120 text
1. employee gets paged
2. they ssh into… something
3. they fix it… somehow
app crashes. here’s a normal flow:
Slide 121
Slide 121 text
no visibility means no teaching
Slide 122
Slide 122 text
no visibility means no improvement
Slide 123
Slide 123 text
d
HUBOT
Slide 124
Slide 124 text
1. employee gets paged
2. they manage it in a chat room
3. they fix it and people can watch
here’s a better flow:
app crashes.
Slide 125
Slide 125 text
visibility means teaching
Slide 126
Slide 126 text
visibility means improvement
Slide 127
Slide 127 text
real-life debugging
Slide 128
Slide 128 text
github’s wifi is down
floor two, san francisco
(right now!)
Slide 129
Slide 129 text
No content
Slide 130
Slide 130 text
No content
Slide 131
Slide 131 text
No content
Slide 132
Slide 132 text
No content
Slide 133
Slide 133 text
debug in the open
Slide 134
Slide 134 text
feedback
Slide 135
Slide 135 text
blue angels
the
feedback
on
Slide 136
Slide 136 text
No content
Slide 137
Slide 137 text
two-way
street
Slide 138
Slide 138 text
two-way
street
how well do
you receive
feedback?
Slide 139
Slide 139 text
two-way
street
how well do
you give
feedback?
Slide 140
Slide 140 text
improving
feedbackacross an org
Slide 141
Slide 141 text
No content
Slide 142
Slide 142 text
caution
with a degree of
moving fast
Slide 143
Slide 143 text
need to be fast
Slide 144
Slide 144 text
need to be safe
Slide 145
Slide 145 text
takes effort
to achieve both
Slide 146
Slide 146 text
@ holman