Sometimes a Controller is Just a Controller

Sometimes a Controller is Just a Controller

E6c6e133e74c3b83f04d2861deaa1c20?s=128

Justin Searls

April 23, 2015
Tweet

Transcript

  1. None
  2. Fancy Code

  3. vs Fancy Code

  4. boring code vs Fancy Code

  5. None
  6. None
  7. None
  8. Boring code is so much easier to read!

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

  10. Slides

  11. None
  12. I am not an artiste

  13. I am not an artiste

  14. I am not an artíste

  15. I am not an artìste

  16. Artists say "I love your slides"

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

    of joy:
  18. "Really, I love that you put so much time into

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

    your slides" " :loudly crying face:
  20. Time

  21. Time ⏰

  22. Time

  23. None
  24. Horological Study:

  25. Horological Study: time -slides= 0

  26. People Won Over

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

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

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

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

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

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

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

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

    20 hours 40 hours 60 hours People Won Over X
  35. 80 / 20 Rule

  36. 0% 20% 40% 60% 80% 100% 1 hour 10 hours

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

    20 hours 40 hours 60 hours People Won Over X
  38. Time ⏰

  39. None
  40. Sometimes a slide is just a slide

  41. "Good" Talk

  42. But anyway

  43. Good Code

  44. 1. tiny units

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

  46. 1. tiny units 1a. no, like hilariously tiny 1b. as

    in, units with one public method
  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
  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
  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
  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
  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
  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
  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!"
  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
  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)
  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
  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
  58. The end.

  59. My name is Justin Searls Please tweet me @searls &

    Say hello@testdouble.com
  60. ( ͠° ͟ʖ ͡°)

  61. ( ͡~ ͜ ʖ ͡°)

  62. My Favorite Way

  63. Your Favorite Way

  64. Your Team's Favorite Way

  65. Your Framework's Favorite Way

  66. Your Boss's Favorite Way

  67. Your Boss's Favorite Way $

  68. Your Boss's Favorite Way ⏰ $

  69. Your Boss's Favorite Way % ⏰ $

  70. Text (video)

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

  72. Good Code

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

  74. Snake oil still sells out as fast as Hacker News

    can stock it Exhibit A:
  75. Projects rarely succeed or fail because of code quality Exhibit

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

    Exhibit C:
  77. If natural selection applies to software, it isn't selecting for

    code quality
  78. None
  79. Good Code

  80. 1. Performs a function

  81. 1. Performs a function 2. Communicates intent

  82. Performs a function

  83. Performs a function &

  84. Performs a function & ⏳

  85. Performs a function & ⏳ (

  86. Functionality is Objective

  87. Functionality is Objective ) :ok hand sign:

  88. Communicates intent

  89. Communicates intent *

  90. Communicates intent * +

  91. Communicates intent * + ,

  92. Communication is Subjective

  93. Communication is Subjective - :flushed face:

  94. Conflating objective & subjective goals makes evaluation hard

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

    palette:
  96. None
  97. No Idea

  98. Otherwise, we emphasize function because measurement is easier

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

    with upwards trend:
  100. No Idea Wrong Idea

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

  102. As individuals 0

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

    was good!
  104. So I made one for you:

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

  106. (video)

  107. (Don't view the source)

  108. Version 2 Announcement:

  109. Version 2 Announcement: 10x developer conversion

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

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

  112. Quantified measurement can soothe our self-doubt Why do scoring, ranking

    & achievements comfort us? Q: A:
  113. Every programmer shares a secret fear

  114. What if my code sucks? 5

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

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

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

    5
  118. [coping intensifies] 5

  119. [coping intensifies] 5

  120. Fear, insecurity, & doubt varies 5

  121. Fear, insecurity, & doubt varies 5 6

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

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

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

  125. Fear, insecurity, & doubt varies introspective persuadable unflinching empathetic indifferent

    self-assured
  126. Let's practice rating me!

  127. 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
  128. 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
  129. None
  130. None
  131. None
  132. Fear, insecurity, & doubt varies introspective self-assured

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

  134. Held to subjective evaluation standards

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

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

    favorably
  137. Communication competence:

  138. Communication competence: effective communicator

  139. Communication competence: effective communicator clear communicator

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

  141. we evaluate code poorly

  142. we evaluate code poorly conscientious coders doubt themselves

  143. we evaluate code poorly conscientious coders doubt themselves callous coders

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

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

    outperform others conscientious coders marginalized and then quit more ^
  146. 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 ^
  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 ^
  148. Guess which group does better at whiteboard interviews?

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

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

  151. Then this talk's for you! Did you groan in realization

    this was a soft talk?
  152. 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
  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
  154. Write Code the Right Way

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

  156. XP System Metaphors

  157. Mystery Men Code

  158. None
  159. ಠ_ಠ

  160. Know your audience

  161. Know your audience , :crystal ball:

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

  163. As a programmer, I want to convert _____ and send

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

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

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

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

    it over ______ using _____ so that I can ______________. Fax to PDF Rails remain employed
  168. 8 best pdf gem rails

  169. 8 best fax gem rails

  170. 9 no results found

  171. 9 no results found : :anguished face:

  172. Why would anyone prefer JavaScript?

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

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

    run? If so, then that's the right way! 7
  175. A Wild West can be liberating!

  176. A Wild West can be liberating!

  177. None
  178. 0 0000 0000000 00000000 00000000 11111 1111111 2

  179. As teams 00000

  180. Ever excitedly try a new approach and team members shot

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

    you down? < :pensive face:
  182. Ever had a team member shoehorn a weird code style

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

    into your project? = :unamused face:
  184. 2 sides of the same coin:

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

  186. ❤ Empathy!

  187. We expend emotional energy compensating for our insecurity

  188. Familiar Novel

  189. Familiar Novel ?

  190. Proven Approach Hacker News Driven Development ?

  191. Proven Approach Hacker News Driven Development @

  192. Stubborn and outmoded Modern Development @

  193. Personal insecurity is a barrier to bridging these divides

  194. Culture Fit

  195. "Culture Fit"

  196. None
  197. "Culture" vs. "Monoculture"

  198. Dirty Secret #1:

  199. Dirty Secret #1: Monocultures work faster!

  200. Proven Approach Hacker News Driven Development ?

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

    ?
  202. "Meritocracies" incidentally reinforce monocultures

  203. ?? ? ? ? ?

  204. ?? ? ? ? ? A

  205. Dirty Secret #2:

  206. Dirty Secret #2: faster != better

  207. The world teaches us that slow == stupid

  208. Teams that overcome differing perspectives are slower

  209. Teams that overcome differing perspectives are slower*

  210. Teams that overcome differing perspectives are slower *but write more

    robust systems *
  211. Proven Approach ?? ? Modern Development @@ @

  212. B Please! Stop Claiming B

  213. "trust us, <Some Practice> is faster in the long run!"

    B Please! Stop Claiming B
  214. Dirty Secret #3

  215. Dirty Secret #3 Most dichotomies are false

  216. ? @

  217. ? C D @ E F

  218. Culture Fit ? D E

  219. Culture Fit ? D E +

  220. What about code? G

  221. None
  222. Functionality

  223. Functionality Communication

  224. Functionality Communication

  225. Priorities functionality communication

  226. Priorities functionality communicate to humans

  227. Priorities communicate to computers communicate to humans

  228. Priorities communicate to computers H communicate to humans

  229. I Priorities communicate to computers communicate to humans

  230. Priorities J communicate to computers communicate to humans

  231. K Priorities communicate to computers communicate to humans

  232. $ Priorities communicate to computers communicate to humans

  233. Functionality Communication

  234. Functionality Communication

  235. How is our code communicating?

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

  237. Indirection Analysis

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

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

  240. Indirection Score For a given code path:

  241. Indirection Score For a given code path: 1. How many

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

    names are encountered? 2. How many source files contribute code?
  243. 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?
  244. 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?
  245. WET DRY Indirection

  246. WET Duplicate Nothing Indirection

  247. Couple Nothing Duplicate Nothing Indirection

  248. Couple Nothing Duplicate Nothing

  249. Couple Nothing Duplicate Nothing Both extremes are costly

  250. Couple Nothing Duplicate Nothing

  251. Couple Nothing Duplicate Nothing E change one thing

  252. Couple Nothing Duplicate Nothing E change one thing L change

    many things
  253. Couple Nothing Duplicate Nothing

  254. Couple Nothing Duplicate Nothing E change many things

  255. Couple Nothing Duplicate Nothing E change many things L change

    one thing
  256. Couple Nothing Duplicate Nothing

  257. Couple Nothing Duplicate Nothing E learn one piece

  258. Couple Nothing Duplicate Nothing E learn one piece L learn

    entire system
  259. Couple Nothing Duplicate Nothing

  260. Couple Nothing Duplicate Nothing L learn one piece

  261. Couple Nothing Duplicate Nothing L learn one piece E learn

    entire system
  262. Couple Nothing Duplicate Nothing

  263. Couple Nothing Duplicate Nothing Yay Nuance!

  264. Explicit vs. Implicit Indirection

  265. Explicit vs. Implicit Indirection ❄

  266. Explicit vs. Implicit Indirection ❄ N

  267. Practice communicating about our code's communication

  268. #thoughtleadering opportunities abound!

  269. 0 0000 0000000 00000000 00000000 11111 1111111 2

  270. As a community 0000000000000000 0000000000000000 0000000000000000

  271. Your team's 6th person

  272. Your team's 6th person ?

  273. Your team's 6th person ?

  274. Your team's 6th person ?

  275. Your team's 6th person ?

  276. Thought Leaders O

  277. Thought Leaders O PQ

  278. Thought Leaders O PQ R

  279. Who does our code talk to?

  280. None
  281. None
  282. ?

  283. ?

  284. S

  285. S :face with cold sweat:

  286. None
  287. None
  288. T

  289. T :disappointed but relieved face:

  290. None
  291. 7

  292. 7 7

  293. Hero Worship

  294. None
  295. None
  296. None
  297. Now that I'm a Certified Keynote Speaker™

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

  299. Your clever code does not impress me

  300. Your clever code makes me feel stupid

  301. Clever code is a symptom of poor understanding

  302. None
  303. Obvious is more impressive than clever

  304. Code design approaches are memes

  305. Code design approaches are memes MVC

  306. Code design approaches are memes MVC BDD

  307. Code design approaches are memes MVC BDD DSLs

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

  309. Code design approaches are memes MVC BDD Fast Specs View

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

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

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

    Presenters Hexagonal Rails DSLs DCI Fat models / Skinny controllers
  313. Memes are ideas competing for attention via natural selection

  314. U

  315. Somebody has idea 0 U

  316. Somebody has idea 0 Experiments with idea 0 U

  317. Somebody has idea 0 Experiments with idea 0 Shares idea

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

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

    with others 00 Idea becomes popular 000 Idea becomes ubiquitous 0000 U
  320. 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
  321. 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
  322. Memes are most valuable when our audience knows them

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

  324. Symbiotic relationships with early adopters who oversell any intrinsic benefits!

    How do design memes ever become ubiquitous?! Q: A:
  325. 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
  326. 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
  327. 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"
  328. 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
  329. 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
  330. 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
  331. Everyone wants their meme to reach ubiquity & may pressure

    you to adopt it
  332. Know your audience , :crystal ball:

  333. 0 0000 0000000 00000000 00000000 11111 1111111 2

  334. 0 0000 0000000 00000000 00000000 11111 1111111 2

  335. As an industry 111111111111111 111111111111111 111111111111111

  336. As an industry 1111111X1111111 111X11111111111 1X11111111X1111

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

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

    Try talking to a businessperson!
  339. None
  340. How can a non-technical person be sure they're hiring good

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

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

    developers? Y Z
  343. Request for Proposals

  344. 5 @

  345. 5 @

  346. 5 @ - Identifies risk, assumptions

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

  348. 5 @ - Identifies risk, assumptions - Emphasizes collaboration -

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

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

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

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

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

    Estimates pessimistically - Higher bid, rarely wins - Rationalizes away risk - Emphasizes competence - Estimates optimistically - Lower bid, often wins
  354. 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
  355. 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
  356. Businesses don't realize asking for proposals biases their decisions

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

  358. Instead, why not admit & educate that software is full

    of uncertainty?
  359. B Construction [

  360. B Construction [ vs

  361. B Construction [ vs \ Surgery ✂

  362. B Construction [ vs \ Surgery ✂ (metaphor credit: Dan

    North)
  363. E Estimates! E

  364. E Estimates! E How much time will it take to

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

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

    build with Good Code™? How much uncertainty and/or risk does it pose? vs
  367. + Estimates! +

  368. + Estimates! + How bad of my Good Code™ will

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

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

    you accept? vs How much uncertainty will you tolerate?
  371. Pick the most uncertain feature

  372. Pick the most uncertain feature Identify risks & unknowns

  373. Pick the most uncertain feature Identify risks & unknowns Execute

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

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

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

    spikes to reduce uncertainty Implement with boring code The Boring Code Discovery Model
  377. 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!
  378. How will we know boring code when we see it?

  379. What even is boring code?

  380. Shared Context Enough What even is boring code?

  381. Shared Context Technical Concepts Minimal Enough + What even is

    boring code?
  382. Shared Context Technical Concepts Domain Concepts Minimal Clear Enough +

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

    of Enough + + + What even is boring code?
  384. Shared Context Technical Concepts Domain Concepts Empathy

  385. Shared Context Technical Concepts Domain Concepts Empathy

  386. Shared Context Technical Concepts Domain Concepts Empathy An Omakase Rails

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

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

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

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

  391. ¯\_(π)_/¯

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

  393. What can we start ☀ doing tomorrow? ☀

  394. Relax your conception of universally Good Code™

  395. How we evaluate code is subjective and flawed

  396. How we evaluate code is subjective and flawed …so fearing

    your code sucks is both natural and pointless
  397. Claiming a Right Way™ may push others away

  398. Seek opportunities to deliberate Kindly and Respectfully with people who

    think differently
  399. Whenever you see the word 'clever', substitute it with 'self-indulgent'.

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

    ~ Don Norman
  401. Metaphors & memes are powerful but limit your audience to

    whoever understands them
  402. When someone doesn't understand your code, assume some responsibility

  403. Kip Thorne, The Science of Interstellar:

  404. “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:
  405. Be Courageous

  406. Be Courageous Write Boring Code

  407. Be Courageous Write Boring Code _

  408. The end. Again.

  409. The end. Again. The end. Again.

  410. My name is Justin Searls Please tweet me @searls &

    Say hello@testdouble.com
  411. Please say hello if your team could use our team's

    help E
  412. Like everyone, we're hiring! Just join@testdouble.com

  413. Please find me, whether to chat or to grab a

    sticker!
  414. My name is Justin Searls Please tweet me @searls &

    Say hello@testdouble.com