Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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. "Really, I love that you put so much time into

    your slides" " :loudly crying face:
  2. 0% 20% 40% 60% 80% 100% 1 hour 10 hours

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

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

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

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

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

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

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

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

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

    20 hours 40 hours 60 hours People Won Over X
  12. 1. tiny units 1a. no, like hilariously tiny 1b. as

    in, units with one public method
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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!"
  20. 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
  21. 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)
  22. 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
  23. 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
  24. 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
  25. 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
  26. we evaluate code poorly conscientious coders doubt themselves callous coders

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

    outperform others conscientious coders marginalized and then quit more ^
  28. 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 ^
  29. 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 ^
  30. 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
  31. 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
  32. As a programmer, I want to convert _____ and send

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

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

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

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

    it over ______ using _____ so that I can ______________. Fax to PDF Rails remain employed
  37. What's the right way to ⛄? 5 Does your code

    run? If so, then that's the right way! 7
  38. Ever had a team member shoehorn a weird code style

    into your project? = :unamused face:
  39. ? @

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

    names are encountered? 2. How many source files contribute code?
  41. 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?
  42. 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?
  43. ?

  44. ?

  45. S

  46. T

  47. 7

  48. 7 7

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

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

    Presenters Hexagonal Rails DSLs DCI Fat models / Skinny controllers
  51. U

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

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

    with others 00 Idea becomes popular 000 Idea becomes ubiquitous 0000 U
  54. 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
  55. 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
  56. 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
  57. 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
  58. 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"
  59. 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
  60. 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
  61. 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
  62. 5 @

  63. 5 @

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

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

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

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

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

    Estimates pessimistically - Higher bid, rarely wins - Rationalizes away risk - Emphasizes competence - Estimates optimistically - Lower bid, often wins
  69. 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
  70. 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
  71. E Estimates! E How much time will it take to

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

    build with Good Code™? How much uncertainty and/or risk does it pose? vs
  73. + Estimates! + How bad of my Good Code™ will

    you accept? vs How much uncertainty will you tolerate?
  74. Pick the most uncertain feature Identify risks & unknowns Execute

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

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

    spikes to reduce uncertainty Implement with boring code The Boring Code Discovery Model
  77. 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!
  78. How we evaluate code is subjective and flawed …so fearing

    your code sucks is both natural and pointless
  79. “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: