$30 off During Our Annual Pro Sale. View Details »

Sometimes a Controller is Just a Controller

Sometimes a Controller is Just a Controller

Justin Searls

April 23, 2015
Tweet

More Decks by Justin Searls

Other Decks in Programming

Transcript

  1. View Slide

  2. Fancy Code

    View Slide

  3. vs
    Fancy Code

    View Slide

  4. boring code
    vs
    Fancy Code

    View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. Boring code is so
    much easier to read!

    View Slide

  9. Turns out, that'd
    be a boring talk

    View Slide

  10. Slides

    View Slide

  11. View Slide

  12. I am not an artiste

    View Slide

  13. I am not an artiste

    View Slide

  14. I am not an artíste

    View Slide

  15. I am not an artìste

    View Slide

  16. Artists say "I love your slides"

    View Slide

  17. Artists say "I love your slides"
    !
    :crying with tears of joy:

    View Slide

  18. "Really, I love that you put so
    much time into your slides"

    View Slide

  19. "Really, I love that you put so
    much time into your slides"
    "
    :loudly crying face:

    View Slide

  20. Time

    View Slide

  21. Time

    View Slide

  22. Time

    View Slide

  23. View Slide

  24. Horological Study:

    View Slide

  25. Horological Study:
    time -slides= 0

    View Slide

  26. People Won Over

    View Slide

  27. 0%
    20%
    40%
    60%
    80%
    100%
    1
    hour
    10
    hours
    20
    hours
    40
    hours
    60
    hours
    People Won Over

    View Slide

  28. 0%
    20%
    40%
    60%
    80%
    100%
    1
    hour
    10
    hours
    20
    hours
    40
    hours
    60
    hours
    People Won Over

    View Slide

  29. 0%
    20%
    40%
    60%
    80%
    100%
    1
    hour
    10
    hours
    20
    hours
    40
    hours
    60
    hours
    People Won Over

    View Slide

  30. 0%
    20%
    40%
    60%
    80%
    100%
    1
    hour
    10
    hours
    20
    hours
    40
    hours
    60
    hours
    People Won Over

    View Slide

  31. 0%
    20%
    40%
    60%
    80%
    100%
    1
    hour
    10
    hours
    20
    hours
    40
    hours
    60
    hours
    People Won Over

    View Slide

  32. 0%
    20%
    40%
    60%
    80%
    100%
    1
    hour
    10
    hours
    20
    hours
    40
    hours
    60
    hours
    People Won Over

    View Slide

  33. 0%
    20%
    40%
    60%
    80%
    100%
    1
    hour
    10
    hours
    20
    hours
    40
    hours
    60
    hours
    People Won Over
    X

    View Slide

  34. 0%
    20%
    40%
    60%
    80%
    100%
    1
    hour
    10
    hours
    20
    hours
    40
    hours
    60
    hours
    People Won Over
    X

    View Slide

  35. 80 / 20 Rule

    View Slide

  36. 0%
    20%
    40%
    60%
    80%
    100%
    1
    hour
    10
    hours
    20
    hours
    40
    hours
    60
    hours
    People Won Over
    X

    View Slide

  37. 0%
    20%
    40%
    60%
    80%
    100%
    1
    hour
    10
    hours
    20
    hours
    40
    hours
    60
    hours
    People Won Over
    X

    View Slide

  38. Time

    View Slide

  39. View Slide

  40. Sometimes a slide
    is just a slide

    View Slide

  41. "Good" Talk

    View Slide

  42. But anyway

    View Slide

  43. Good Code

    View Slide

  44. 1. tiny units

    View Slide

  45. 1. tiny units
    1a. no, like hilariously tiny

    View Slide

  46. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method

    View Slide

  47. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction

    View Slide

  48. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction
    2. units can hold & describe a value or perform useful behavior, never both

    View Slide

  49. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction
    2. units can hold & describe a value or perform useful behavior, never both
    3. behavior-ey units can contain logic or depend on other units, not both

    View Slide

  50. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction
    2. units can hold & describe a value or perform useful behavior, never both
    3. behavior-ey units can contain logic or depend on other units, not both
    4. eliminate local variables to an absurd degree

    View Slide

  51. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction
    2. units can hold & describe a value or perform useful behavior, never both
    3. behavior-ey units can contain logic or depend on other units, not both
    4. eliminate local variables to an absurd degree
    4a. start with functional chains

    View Slide

  52. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction
    2. units can hold & describe a value or perform useful behavior, never both
    3. behavior-ey units can contain logic or depend on other units, not both
    4. eliminate local variables to an absurd degree
    4a. start with functional chains
    4b. refactor via functional composition

    View Slide

  53. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction
    2. units can hold & describe a value or perform useful behavior, never both
    3. behavior-ey units can contain logic or depend on other units, not both
    4. eliminate local variables to an absurd degree
    4a. start with functional chains
    4b. refactor via functional composition
    4c. use tap/each as if to scream "Side Effect!"

    View Slide

  54. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction
    2. units can hold & describe a value or perform useful behavior, never both
    3. behavior-ey units can contain logic or depend on other units, not both
    4. eliminate local variables to an absurd degree
    4a. start with functional chains
    4b. refactor via functional composition
    4c. use tap/each as if to scream "Side Effect!"
    5. minimize third-party dependencies and write wrappers around them

    View Slide

  55. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction
    2. units can hold & describe a value or perform useful behavior, never both
    3. behavior-ey units can contain logic or depend on other units, not both
    4. eliminate local variables to an absurd degree
    4a. start with functional chains
    4b. refactor via functional composition
    4c. use tap/each as if to scream "Side Effect!"
    5. minimize third-party dependencies and write wrappers around them
    6. pull side-effects nearer the entry point (imperative shell / functional core)

    View Slide

  56. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction
    2. units can hold & describe a value or perform useful behavior, never both
    3. behavior-ey units can contain logic or depend on other units, not both
    4. eliminate local variables to an absurd degree
    4a. start with functional chains
    4b. refactor via functional composition
    4c. use tap/each as if to scream "Side Effect!"
    5. minimize third-party dependencies and write wrappers around them
    6. pull side-effects nearer the entry point (imperative shell / functional core)
    7. disagree with whatever my pair does every 10 minutes

    View Slide

  57. 1. tiny units
    1a. no, like hilariously tiny
    1b. as in, units with one public method
    1c. extract privates from complex code for the name, not the abstraction
    2. units can hold & describe a value or perform useful behavior, never both
    3. behavior-ey units can contain logic or depend on other units, not both
    4. eliminate local variables to an absurd degree
    4a. start with functional chains
    4b. refactor via functional composition
    4c. use tap/each as if to scream "Side Effect!"
    5. minimize third-party dependencies and write wrappers around them
    6. pull side-effects nearer the entry point (imperative shell / functional core)
    7. disagree with whatever my pair does every 10 minutes
    8. overwhelm people with information so that I get my way

    View Slide

  58. The end.

    View Slide

  59. My name is Justin Searls
    Please tweet me @searls &
    Say [email protected]

    View Slide

  60. ( ͠° ͟ʖ ͡°)

    View Slide

  61. ( ͡~ ͜
    ʖ ͡°)

    View Slide

  62. My Favorite Way

    View Slide

  63. Your Favorite Way

    View Slide

  64. Your Team's Favorite Way

    View Slide

  65. Your Framework's Favorite Way

    View Slide

  66. Your Boss's Favorite Way

    View Slide

  67. Your Boss's Favorite Way
    $

    View Slide

  68. Your Boss's Favorite Way

    $

    View Slide

  69. Your Boss's Favorite Way
    %

    $

    View Slide

  70. Text
    (video)

    View Slide

  71. If you combine everybody's
    favorite way then maybe…

    View Slide

  72. Good Code

    View Slide

  73. There's no such thing
    as Good Code
    Hypothesis:

    View Slide

  74. Snake oil still sells out as fast
    as Hacker News can stock it
    Exhibit A:

    View Slide

  75. Projects rarely succeed or
    fail because of code quality
    Exhibit B:

    View Slide

  76. The industry doesn't seem to
    produce better code over time
    Exhibit C:

    View Slide

  77. If natural selection applies to software,
    it isn't selecting for code quality

    View Slide

  78. View Slide

  79. Good Code

    View Slide

  80. 1. Performs a function

    View Slide

  81. 1. Performs a function
    2. Communicates intent

    View Slide

  82. Performs a function

    View Slide

  83. Performs a function
    &

    View Slide

  84. Performs a function
    & ⏳

    View Slide

  85. Performs a function
    & ⏳ (

    View Slide

  86. Functionality is Objective

    View Slide

  87. Functionality is Objective
    )
    :ok hand sign:

    View Slide

  88. Communicates intent

    View Slide

  89. Communicates intent
    *

    View Slide

  90. Communicates intent
    * +

    View Slide

  91. Communicates intent
    * + ,

    View Slide

  92. Communication is Subjective

    View Slide

  93. Communication is Subjective
    -
    :flushed face:

    View Slide

  94. Conflating objective & subjective
    goals makes evaluation hard

    View Slide

  95. Conflating objective & subjective
    goals makes evaluation hard
    .
    :artist palette:

    View Slide

  96. View Slide

  97. No
    Idea

    View Slide

  98. Otherwise, we emphasize function
    because measurement is easier

    View Slide

  99. Otherwise, we emphasize function
    because measurement is easier
    /
    :chart with upwards trend:

    View Slide

  100. No
    Idea
    Wrong
    Idea

    View Slide

  101. Snowball Effect
    0
    0000
    0000000
    00000000
    00000000
    11111
    1111111
    2

    View Slide

  102. As individuals
    0

    View Slide

  103. If only an app could tell us
    whether our code was good!

    View Slide

  104. So I made one for you:

    View Slide

  105. So I made one for you:
    is my code good.com

    View Slide

  106. (video)

    View Slide


  107. View Slide

  108. (Don't view the source)

    View Slide

  109. Version 2 Announcement:

    View Slide

  110. Version 2 Announcement:
    10x
    developer
    conversion

    View Slide

  111. Version 2 Announcement:
    10x
    developer
    conversion
    4
    4

    View Slide

  112. Why do scoring, ranking &
    achievements comfort us?
    Q:

    View Slide

  113. Quantified measurement
    can soothe our self-doubt
    Why do scoring, ranking &
    achievements comfort us?
    Q:
    A:

    View Slide

  114. Every programmer
    shares a secret fear

    View Slide

  115. What if my
    code sucks?
    5

    View Slide

  116. Everyone else seems
    to have it figured out…
    5

    View Slide

  117. Maybe they know
    something I don't?
    5

    View Slide

  118. Maybe I'll fool them if
    I use more big words
    5

    View Slide

  119. [coping intensifies]
    5

    View Slide

  120. [coping intensifies]
    5

    View Slide

  121. Fear, insecurity, & doubt varies
    5

    View Slide

  122. Fear, insecurity, & doubt varies
    5
    6

    View Slide

  123. Fear, insecurity, & doubt varies
    5
    6 7

    View Slide

  124. Fear, insecurity, & doubt varies
    introspective self-assured

    View Slide

  125. Fear, insecurity, & doubt varies
    introspective
    empathetic indifferent
    self-assured

    View Slide

  126. Fear, insecurity, & doubt varies
    introspective
    persuadable unflinching
    empathetic indifferent
    self-assured

    View Slide

  127. Let's practice rating me!

    View Slide

  128. FORM APPROVED
    OMB NO. 1651-0009
    Customs Declaration
    19 CFR 122.27, 148.12, 148.13, 148.110,148.111, 1498; 31 CFR 5316
    Each arriving traveler or responsible family member must provide the following
    information (only ONE written declaration per family is required). The term
    “family” is defined as “members of a family residing in the same household who
    are related by blood, marriage, domestic relationship, or adoption.”
    1 Family Name
    First (Given) Middle
    8 Countries visited on this
    trip prior to U.S. arrival
    4 (a) U.S. Street Address (hotel name/destination
    (b) City (c) State
    10 The primary purpose of this trip is business: Yes No
    11 I am (We are) bringing
    (a) fruits, vegetables, plants, seeds, food, insects: Yes No
    (b) meats, animals, animal/wildlife products: Yes No
    (c) disease agents, cell cultures, snails: Yes No
    (d) soil or have been on a farm/ranch/pasture: Yes No
    12 I have (We have) been in close proximity of livestock: Yes No
    3 Number of Family members traveling with you
    5 Passport issued by (country)
    6 Passport number
    7 Country of Residence
    2 Birth date Month Day Year
    9 Airline/Flight No. or Vessel Name
    This Space For Offical Use Only

    View Slide

  129. 8 Countries visited on this
    trip prior to U.S. arrival
    10 The primary purpose of this trip is business: Yes No
    11 I am (We are) bringing
    (a) fruits, vegetables, plants, seeds, food, insects: Yes No
    (b) meats, animals, animal/wildlife products: Yes No
    (c) disease agents, cell cultures, snails: Yes No
    (d) soil or have been on a farm/ranch/pasture: Yes No
    12 I have (We have) been in close proximity of livestock: Yes No
    (such as touching or handling)
    13 I am (We are) carrying currency or monetary instruments
    over $10,000 U.S. or foreign equivalent: Yes No
    (see definition of monetary instruments on reverse)
    9 Airline/Flight No. or Vessel Name

    View Slide

  130. View Slide

  131. View Slide

  132. View Slide

  133. Fear, insecurity, & doubt varies
    introspective self-assured

    View Slide

  134. Fear, insecurity, & doubt varies
    introspective self-assured
    6

    View Slide

  135. Held to subjective
    evaluation standards

    View Slide

  136. Held to subjective
    evaluation standards
    paralyzed by
    self-doubt

    View Slide

  137. Held to subjective
    evaluation standards
    paralyzed by
    self-doubt
    rates self
    favorably

    View Slide

  138. Communication competence:

    View Slide

  139. Communication competence:
    effective
    communicator

    View Slide

  140. Communication competence:
    effective
    communicator
    clear
    communicator

    View Slide

  141. Communication competence:
    effective
    communicator
    clear
    communicator
    (to like-minded people)

    View Slide

  142. we evaluate
    code poorly

    View Slide

  143. we evaluate
    code poorly
    conscientious
    coders doubt
    themselves

    View Slide

  144. we evaluate
    code poorly
    conscientious
    coders doubt
    themselves
    callous coders
    outperform others

    View Slide

  145. we evaluate
    code poorly
    conscientious
    coders doubt
    themselves
    callous coders
    outperform others
    conscientious
    coders marginalized
    and then quit

    View Slide

  146. we evaluate
    code poorly
    conscientious
    coders doubt
    themselves
    callous coders
    outperform others
    conscientious
    coders marginalized
    and then quit
    more
    ^

    View Slide

  147. we evaluate
    code poorly
    conscientious
    coders doubt
    themselves
    callous coders
    outperform others
    conscientious
    coders marginalized
    and then quit 5
    7
    5
    5 5
    7
    7
    7
    7
    7
    more
    ^

    View Slide

  148. we evaluate
    code poorly
    conscientious
    coders doubt
    themselves
    callous coders
    outperform others
    conscientious
    coders marginalized
    and then quit
    5
    7
    5
    5 5
    7
    7
    7
    7
    7
    more
    ^

    View Slide

  149. Guess which group does
    better at whiteboard interviews?

    View Slide

  150. Guess which group does
    better at whiteboard interviews?
    NOOOOOOPE

    View Slide

  151. Did you groan in realization
    this was a soft talk?

    View Slide

  152. Then this talk's for you!
    Did you groan in realization
    this was a soft talk?

    View Slide

  153. THE FOLLOWING TALK HAS BEEN APPROVED FOR
    APPROPRIATE AUDIENCES
    BY THE PEOPLE WHO RATE TALKS, I GUESS?
    THE TALK ADVERTISED HAS BEEN RATED
    F FEELS
    SOME STRONG EMOTIONS, EVIDENCE OF
    RELATABLE HUMANITY THROUGHOUT

    View Slide

  154. THE FOLLOWING TALK HAS BEEN APPROVED FOR
    APPROPRIATE AUDIENCES
    BY THE PEOPLE WHO RATE TALKS, I GUESS?
    THE TALK ADVERTISED HAS BEEN RATED
    F FEELS
    SOME STRONG EMOTIONS, EVIDENCE OF
    RELATABLE HUMANITY THROUGHOUT

    View Slide

  155. Write Code the Right Way

    View Slide

  156. Communication can only be
    "correct" for a set of contexts

    View Slide

  157. XP System Metaphors

    View Slide

  158. Mystery Men Code

    View Slide

  159. View Slide

  160. ಠ_ಠ

    View Slide

  161. Know your audience

    View Slide

  162. Know your audience
    ,
    :crystal ball:

    View Slide

  163. Popular belief in a
    "Right Way"
    causes problems

    View Slide

  164. As a programmer, I want to
    convert _____ and send it
    over ______ using _____ so
    that I can ______________.

    View Slide

  165. As a programmer, I want to
    convert _____ and send it
    over ______ using _____ so
    that I can ______________.
    to PDF

    View Slide

  166. As a programmer, I want to
    convert _____ and send it
    over ______ using _____ so
    that I can ______________.
    Fax
    to PDF

    View Slide

  167. As a programmer, I want to
    convert _____ and send it
    over ______ using _____ so
    that I can ______________.
    Fax
    to PDF
    Rails

    View Slide

  168. As a programmer, I want to
    convert _____ and send it
    over ______ using _____ so
    that I can ______________.
    Fax
    to PDF
    Rails
    remain employed

    View Slide

  169. 8 best pdf gem rails

    View Slide

  170. 8 best fax gem rails

    View Slide

  171. 9 no results found

    View Slide

  172. 9 no results found
    :
    :anguished face:

    View Slide

  173. Why would anyone
    prefer JavaScript?

    View Slide

  174. What's the right way to ⛄?
    5

    View Slide

  175. What's the right way to ⛄?
    5
    Does your code run? If so,
    then that's the right way!
    7

    View Slide

  176. A Wild West can be liberating!

    View Slide

  177. A Wild West can be liberating!

    View Slide

  178. View Slide

  179. 0
    0000
    0000000
    00000000
    00000000
    11111
    1111111
    2

    View Slide

  180. As teams
    00000

    View Slide

  181. Ever excitedly try a new approach
    and team members shot you down?

    View Slide

  182. Ever excitedly try a new approach
    and team members shot you down?
    <
    :pensive face:

    View Slide

  183. Ever had a team member shoehorn
    a weird code style into your project?

    View Slide

  184. Ever had a team member shoehorn
    a weird code style into your project?
    =
    :unamused face:

    View Slide

  185. 2 sides of the same coin:

    View Slide

  186. 2 sides of the same coin:
    Fundamental Attribution Error

    View Slide


  187. Empathy!

    View Slide

  188. We expend emotional energy
    compensating for our insecurity

    View Slide


  189. View Slide


  190. View Slide


  191. View Slide

  192. Familiar Novel

    View Slide

  193. Familiar Novel
    ?

    View Slide

  194. Proven Approach Hacker News
    Driven Development
    ?

    View Slide

  195. Proven Approach Hacker News
    Driven Development
    @

    View Slide

  196. Stubborn
    and outmoded
    Modern
    Development
    @

    View Slide

  197. Personal insecurity is a barrier
    to bridging these divides

    View Slide

  198. Culture Fit

    View Slide

  199. "Culture Fit"

    View Slide

  200. View Slide

  201. "Culture" vs. "Monoculture"

    View Slide

  202. Dirty Secret #1:

    View Slide

  203. Dirty Secret #1:
    Monocultures work faster!

    View Slide

  204. Proven Approach Hacker News
    Driven Development
    ?

    View Slide

  205. Proven Approach Hacker News
    Driven Development
    ??
    ?
    ?
    ?
    ?

    View Slide

  206. "Meritocracies" incidentally
    reinforce monocultures

    View Slide

  207. ??
    ?
    ?
    ?
    ?

    View Slide

  208. ??
    ?
    ?
    ?
    ?
    A

    View Slide

  209. Dirty Secret #2:

    View Slide

  210. Dirty Secret #2:
    faster != better

    View Slide

  211. The world teaches us
    that slow == stupid

    View Slide

  212. Teams that overcome differing
    perspectives are slower

    View Slide

  213. Teams that overcome differing
    perspectives are slower*

    View Slide

  214. Teams that overcome differing
    perspectives are slower
    *but write more robust systems
    *

    View Slide

  215. Proven Approach
    ??
    ?
    Modern
    Development
    @@
    @

    View Slide

  216. B Please! Stop Claiming B

    View Slide

  217. "trust us, is
    faster in the long run!"
    B Please! Stop Claiming B

    View Slide

  218. Dirty Secret #3

    View Slide

  219. Dirty Secret #3
    Most dichotomies are false

    View Slide

  220. ? @

    View Slide

  221. ? C D @
    E F

    View Slide

  222. Culture Fit
    ?
    D
    E

    View Slide

  223. Culture Fit
    ?
    D
    E
    +

    View Slide

  224. What about code?
    G

    View Slide

  225. View Slide

  226. Functionality

    View Slide

  227. Functionality
    Communication

    View Slide

  228. Functionality
    Communication

    View Slide

  229. Priorities
    functionality communication

    View Slide

  230. Priorities
    functionality
    communicate
    to humans

    View Slide

  231. Priorities
    communicate
    to computers
    communicate
    to humans

    View Slide

  232. Priorities
    communicate
    to computers
    H
    communicate
    to humans

    View Slide

  233. I
    Priorities
    communicate
    to computers
    communicate
    to humans

    View Slide

  234. Priorities
    J
    communicate
    to computers
    communicate
    to humans

    View Slide

  235. K
    Priorities
    communicate
    to computers
    communicate
    to humans

    View Slide

  236. $
    Priorities
    communicate
    to computers
    communicate
    to humans

    View Slide

  237. Functionality
    Communication

    View Slide

  238. Functionality
    Communication

    View Slide

  239. How is our code
    communicating?

    View Slide

  240. We don't have a good
    vocabulary for this yet

    View Slide

  241. Indirection Analysis

    View Slide

  242. Each {lib, file, method,
    name} is an indirection

    View Slide

  243. Each {macro, reflection, metaprogram}
    is a SUPER indirection

    View Slide

  244. Indirection Score
    For a given code path:

    View Slide

  245. Indirection Score
    For a given code path:
    1. How many names are encountered?

    View Slide

  246. Indirection Score
    For a given code path:
    1. How many names are encountered?
    2. How many source files contribute code?

    View Slide

  247. Indirection Score
    For a given code path:
    1. How many names are encountered?
    2. How many source files contribute code?
    3. How many tests redundantly cover it?

    View Slide

  248. Indirection Score
    For a given code path:
    1. How many names are encountered?
    2. How many source files contribute code?
    3. How many tests redundantly cover it?
    4. How much is handled by dependencies?

    View Slide

  249. WET DRY
    Indirection

    View Slide

  250. WET
    Duplicate
    Nothing
    Indirection

    View Slide

  251. Couple
    Nothing
    Duplicate
    Nothing
    Indirection

    View Slide

  252. Couple
    Nothing
    Duplicate
    Nothing

    View Slide

  253. Couple
    Nothing
    Duplicate
    Nothing
    Both extremes are costly

    View Slide

  254. Couple
    Nothing
    Duplicate
    Nothing

    View Slide

  255. Couple
    Nothing
    Duplicate
    Nothing
    E change one thing

    View Slide

  256. Couple
    Nothing
    Duplicate
    Nothing
    E change one thing
    L change many things

    View Slide

  257. Couple
    Nothing
    Duplicate
    Nothing

    View Slide

  258. Couple
    Nothing
    Duplicate
    Nothing
    E change many things

    View Slide

  259. Couple
    Nothing
    Duplicate
    Nothing
    E change many things
    L change one thing

    View Slide

  260. Couple
    Nothing
    Duplicate
    Nothing

    View Slide

  261. Couple
    Nothing
    Duplicate
    Nothing
    E learn one piece

    View Slide

  262. Couple
    Nothing
    Duplicate
    Nothing
    E learn one piece
    L learn entire system

    View Slide

  263. Couple
    Nothing
    Duplicate
    Nothing

    View Slide

  264. Couple
    Nothing
    Duplicate
    Nothing
    L learn one piece

    View Slide

  265. Couple
    Nothing
    Duplicate
    Nothing
    L learn one piece
    E learn entire system

    View Slide

  266. Couple
    Nothing
    Duplicate
    Nothing

    View Slide

  267. Couple
    Nothing
    Duplicate
    Nothing
    Yay Nuance!

    View Slide

  268. Explicit vs. Implicit Indirection

    View Slide

  269. Explicit vs. Implicit Indirection

    View Slide

  270. Explicit vs. Implicit Indirection
    ❄ N

    View Slide

  271. Practice communicating about
    our code's communication

    View Slide

  272. #thoughtleadering
    opportunities abound!

    View Slide

  273. 0
    0000
    0000000
    00000000
    00000000
    11111
    1111111
    2

    View Slide

  274. As a community
    0000000000000000
    0000000000000000
    0000000000000000

    View Slide

  275. Your team's 6th person

    View Slide

  276. Your team's 6th person
    ?

    View Slide

  277. Your team's 6th person
    ?

    View Slide

  278. Your team's 6th person
    ?

    View Slide

  279. Your team's 6th person
    ?

    View Slide

  280. Thought Leaders
    O

    View Slide

  281. Thought Leaders
    O PQ

    View Slide

  282. Thought Leaders
    O PQ R

    View Slide

  283. Who does our code talk to?

    View Slide

  284. View Slide

  285. View Slide

  286. ?

    View Slide

  287. ?

    View Slide

  288. S

    View Slide

  289. S
    :face with cold sweat:

    View Slide

  290. View Slide

  291. View Slide

  292. T

    View Slide

  293. T
    :disappointed but
    relieved face:

    View Slide

  294. View Slide

  295. 7

    View Slide

  296. 7 7

    View Slide

  297. Hero Worship

    View Slide

  298. View Slide

  299. View Slide

  300. View Slide

  301. Now that I'm a
    Certified Keynote Speaker™

    View Slide

  302. Now that I'm a
    Certified Keynote Speaker™
    [shuddering intensifies]

    View Slide

  303. Your clever code
    does not impress me

    View Slide

  304. Your clever code
    makes me feel stupid

    View Slide

  305. Clever code is a symptom
    of poor understanding

    View Slide

  306. View Slide

  307. Obvious is more
    impressive than clever

    View Slide

  308. Code design approaches are memes

    View Slide

  309. Code design approaches are memes
    MVC

    View Slide

  310. Code design approaches are memes
    MVC
    BDD

    View Slide

  311. Code design approaches are memes
    MVC
    BDD DSLs

    View Slide

  312. Code design approaches are memes
    MVC
    BDD
    View Presenters
    DSLs

    View Slide

  313. Code design approaches are memes
    MVC
    BDD
    Fast Specs
    View Presenters
    DSLs

    View Slide

  314. Code design approaches are memes
    MVC
    BDD
    Fast Specs
    View Presenters
    Hexagonal Rails
    DSLs

    View Slide

  315. Code design approaches are memes
    MVC
    BDD
    Fast Specs
    View Presenters
    Hexagonal Rails
    DSLs
    DCI

    View Slide

  316. Code design approaches are memes
    MVC
    BDD
    Fast Specs
    View Presenters
    Hexagonal Rails
    DSLs
    DCI
    Fat models / Skinny controllers

    View Slide

  317. Memes are ideas competing for
    attention via natural selection

    View Slide

  318. U

    View Slide

  319. Somebody has idea
    0
    U

    View Slide

  320. Somebody has idea
    0
    Experiments with idea
    0
    U

    View Slide

  321. Somebody has idea
    0
    Experiments with idea
    0
    Shares idea with others
    00
    U

    View Slide

  322. Somebody has idea
    0
    Experiments with idea
    0
    Shares idea with others
    00
    Idea becomes popular
    000
    U

    View Slide

  323. Somebody has idea
    0
    Experiments with idea
    0
    Shares idea with others
    00
    Idea becomes popular
    000
    Idea becomes ubiquitous
    0000
    U

    View Slide

  324. Somebody has idea
    0
    Experiments with idea
    0
    Shares idea with others
    00
    Idea becomes popular
    000
    Idea becomes ubiquitous
    0000
    Idea is finally worth using
    U

    View Slide

  325. Somebody has idea
    0
    Experiments with idea
    0
    Shares idea with others
    00
    Idea becomes popular
    000
    Idea becomes ubiquitous
    0000
    Idea is finally worth using
    V⁉
    U

    View Slide

  326. Memes are most valuable
    when our audience knows them

    View Slide

  327. How do design memes
    ever become ubiquitous?!
    Q:

    View Slide

  328. Symbiotic relationships with
    early adopters who oversell
    any intrinsic benefits!
    How do design memes
    ever become ubiquitous?!
    Q:
    A:

    View Slide

  329. Somebody has idea
    U
    0
    Experiments with idea
    0
    Idea becomes popular
    000
    Idea becomes ubiquitous
    0000
    Idea is finally worth using
    V⁉
    Shares idea with others
    00

    View Slide

  330. Somebody has idea
    U
    0
    Experiments with idea
    0
    Idea becomes popular
    000
    Idea becomes ubiquitous
    0000
    Idea is finally worth using
    V⁉
    Shares idea with others
    00

    View Slide

  331. Somebody has idea
    U
    0
    Experiments with idea
    0
    Idea becomes popular
    000
    Idea becomes ubiquitous
    0000
    Idea is finally worth using
    V⁉
    Shares idea with others
    00
    "Evangelists"

    View Slide

  332. Somebody has idea
    U
    0
    Experiments with idea
    0
    Idea becomes popular
    000
    Idea becomes ubiquitous
    0000
    Idea is finally worth using
    V⁉
    Shares idea with others
    00
    Meme Salespeople

    View Slide

  333. Shares idea with others
    00
    Somebody has idea
    U
    0
    Experiments with idea
    0
    Idea becomes ubiquitous
    0000
    Idea is finally worth using
    V⁉
    Idea becomes popular
    000

    View Slide

  334. Shares idea with others
    00
    Somebody has idea
    U
    0
    Experiments with idea
    0
    Idea becomes ubiquitous
    0000
    Idea is finally worth using
    V⁉
    Idea becomes popular
    000
    Aspirational Adopters

    View Slide

  335. Everyone wants their meme to reach
    ubiquity & may pressure you to adopt it

    View Slide

  336. Know your audience
    ,
    :crystal ball:

    View Slide

  337. 0
    0000
    0000000
    00000000
    00000000
    11111
    1111111
    2

    View Slide

  338. 0
    0000
    0000000
    00000000
    00000000
    11111
    1111111
    2

    View Slide

  339. As an industry
    111111111111111
    111111111111111
    111111111111111

    View Slide

  340. As an industry
    1111111X1111111
    111X11111111111
    1X11111111X1111

    View Slide

  341. You think our inability to evaluate
    code makes us uncomfortable?

    View Slide

  342. You think our inability to evaluate
    code makes us uncomfortable?
    Try talking to a businessperson!

    View Slide

  343. View Slide

  344. How can a non-technical person be
    sure they're hiring good developers?

    View Slide

  345. How can a non-technical person be
    sure they're hiring good developers?
    Y

    View Slide

  346. How can a non-technical person be
    sure they're hiring good developers?
    Y Z

    View Slide

  347. Request for Proposals

    View Slide

  348. 5 @

    View Slide

  349. 5 @

    View Slide

  350. 5 @
    - Identifies risk, assumptions

    View Slide

  351. 5 @
    - Identifies risk, assumptions - Rationalizes away risk

    View Slide

  352. 5 @
    - Identifies risk, assumptions
    - Emphasizes collaboration
    - Rationalizes away risk

    View Slide

  353. 5 @
    - Identifies risk, assumptions
    - Emphasizes collaboration
    - Rationalizes away risk
    - Emphasizes competence

    View Slide

  354. 5 @
    - Identifies risk, assumptions
    - Emphasizes collaboration
    - Estimates pessimistically
    - Rationalizes away risk
    - Emphasizes competence

    View Slide

  355. 5 @
    - Identifies risk, assumptions
    - Emphasizes collaboration
    - Estimates pessimistically
    - Rationalizes away risk
    - Emphasizes competence
    - Estimates optimistically

    View Slide

  356. 5 @
    - Identifies risk, assumptions
    - Emphasizes collaboration
    - Estimates pessimistically
    - Higher bid, rarely wins
    - Rationalizes away risk
    - Emphasizes competence
    - Estimates optimistically

    View Slide

  357. 5 @
    - Identifies risk, assumptions
    - Emphasizes collaboration
    - Estimates pessimistically
    - Higher bid, rarely wins
    - Rationalizes away risk
    - Emphasizes competence
    - Estimates optimistically
    - Lower bid, often wins

    View Slide

  358. 5 @
    - Identifies risk, assumptions
    - Emphasizes collaboration
    - Estimates pessimistically
    - Higher bid, rarely wins
    - Blames failures on self
    - Rationalizes away risk
    - Emphasizes competence
    - Estimates optimistically
    - Lower bid, often wins

    View Slide

  359. 5 @
    - Identifies risk, assumptions
    - Emphasizes collaboration
    - Estimates pessimistically
    - Higher bid, rarely wins
    - Blames failures on self
    - Rationalizes away risk
    - Emphasizes competence
    - Estimates optimistically
    - Lower bid, often wins
    - Blames failures on others

    View Slide

  360. Businesses don't realize asking for
    proposals biases their decisions

    View Slide

  361. Comforting myths that code is
    {tangible,quantifiable,fungible}
    only perpetuate this bias

    View Slide

  362. Instead, why not admit & educate
    that software is full of uncertainty?

    View Slide

  363. B Construction [

    View Slide

  364. B Construction [
    vs

    View Slide

  365. B Construction [
    vs
    \ Surgery ✂

    View Slide

  366. B Construction [
    vs
    \ Surgery ✂
    (metaphor credit: Dan North)

    View Slide

  367. E Estimates! E

    View Slide

  368. E Estimates! E
    How much
    time will it take
    to build with
    Good Code™?

    View Slide

  369. E Estimates! E
    How much
    time will it take
    to build with
    Good Code™?
    vs

    View Slide

  370. E Estimates! E
    How much
    time will it take
    to build with
    Good Code™?
    How much
    uncertainty
    and/or risk
    does it pose?
    vs

    View Slide

  371. + Estimates! +

    View Slide

  372. + Estimates! +
    How bad of my
    Good Code™
    will you accept?

    View Slide

  373. + Estimates! +
    How bad of my
    Good Code™
    will you accept?
    vs

    View Slide

  374. + Estimates! +
    How bad of my
    Good Code™
    will you accept?
    vs
    How much
    uncertainty
    will you tolerate?

    View Slide

  375. Pick the most
    uncertain feature

    View Slide

  376. Pick the most
    uncertain feature
    Identify risks
    & unknowns

    View Slide

  377. Pick the most
    uncertain feature
    Identify risks
    & unknowns
    Execute spikes to
    reduce uncertainty

    View Slide

  378. Pick the most
    uncertain feature
    Identify risks
    & unknowns
    Execute spikes to
    reduce uncertainty
    Implement with
    boring code

    View Slide

  379. Pick the most
    uncertain feature
    Identify risks
    & unknowns
    Execute spikes to
    reduce uncertainty
    Implement with
    boring code

    View Slide

  380. Pick the most
    uncertain feature
    Identify risks
    & unknowns
    Execute spikes to
    reduce uncertainty
    Implement with
    boring code
    The Boring Code
    Discovery Model

    View Slide

  381. Pick the most
    uncertain feature
    Identify risks
    & unknowns
    Execute spikes to
    reduce uncertainty
    Implement with
    boring code
    The Boring Code
    Discovery Model
    Certification Program Coming Soon!

    View Slide

  382. How will we know boring
    code when we see it?

    View Slide

  383. What even is boring code?

    View Slide

  384. Shared
    Context
    Enough
    What even is boring code?

    View Slide

  385. Shared
    Context
    Technical
    Concepts
    Minimal
    Enough
    +
    What even is boring code?

    View Slide

  386. Shared
    Context
    Technical
    Concepts
    Domain
    Concepts
    Minimal Clear
    Enough
    +
    +
    What even is boring code?

    View Slide

  387. Shared
    Context
    Technical
    Concepts
    Domain
    Concepts
    Empathy
    Minimal Clear
    Lots of
    Enough
    + +
    +
    What even is boring code?

    View Slide

  388. Shared
    Context
    Technical
    Concepts
    Domain
    Concepts
    Empathy

    View Slide

  389. Shared
    Context
    Technical
    Concepts
    Domain
    Concepts
    Empathy

    View Slide

  390. Shared
    Context
    Technical
    Concepts
    Domain
    Concepts
    Empathy
    An Omakase Rails Project

    View Slide

  391. Shared
    Context
    Technical
    Concepts
    Domain
    Concepts
    Empathy
    A Prime Rails Project

    View Slide

  392. Shared
    Context
    Technical
    Concepts
    Domain
    Concepts
    Empathy
    A Node.js Project

    View Slide

  393. Shared
    Context
    Technical
    Concepts
    Domain
    Concepts
    Empathy
    A Java Project

    View Slide

  394. Shared
    Context
    Technical
    Concepts
    Domain
    Concepts
    Empathy
    An Ember.js Project

    View Slide

  395. ¯\_(π)_/¯

    View Slide

  396. #ymmv
    ¯\_(π)_/¯

    View Slide

  397. What can we start
    ☀ doing tomorrow? ☀

    View Slide

  398. Relax your conception of
    universally Good Code™

    View Slide

  399. How we evaluate code
    is subjective and flawed

    View Slide

  400. How we evaluate code
    is subjective and flawed
    …so fearing your code sucks
    is both natural and pointless

    View Slide

  401. Claiming a Right Way™
    may push others away

    View Slide

  402. Seek opportunities to deliberate
    Kindly and Respectfully
    with people who think differently

    View Slide

  403. Whenever you see the word 'clever',
    substitute it with 'self-indulgent'.

    View Slide

  404. Whenever you see the word 'clever',
    substitute it with 'self-indulgent'.
    ~ Don Norman

    View Slide

  405. Metaphors & memes are
    powerful but limit your audience
    to whoever understands them

    View Slide

  406. When someone doesn't understand
    your code, assume some responsibility

    View Slide

  407. Kip Thorne, The Science of Interstellar:

    View Slide

  408. “Some segments of this book may be
    rough going. That’s the nature of real
    science. It requires thought. Sometimes
    deep thought. But thinking can be
    rewarding. You can just skip the rough
    parts, or you can struggle to understand.
    If your struggle is fruitless, then that’s
    my fault, not yours, and I apologize."
    Kip Thorne, The Science of Interstellar:

    View Slide

  409. Be Courageous

    View Slide

  410. Be Courageous
    Write Boring Code

    View Slide

  411. Be Courageous
    Write Boring Code
    _

    View Slide

  412. The end. Again.

    View Slide

  413. The end. Again.
    The end. Again.

    View Slide

  414. My name is Justin Searls
    Please tweet me @searls &
    Say [email protected]

    View Slide

  415. Please say hello if your team
    could use our team's help E

    View Slide

  416. Like everyone, we're hiring!
    Just [email protected]

    View Slide

  417. Please find me, whether to chat
    or to grab a sticker!

    View Slide

  418. My name is Justin Searls
    Please tweet me @searls &
    Say [email protected]

    View Slide