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

Build Exciting Things With Boring Technologies

Laura Thomson
November 16, 2017

Build Exciting Things With Boring Technologies

Keynote at php[world] 2017

Laura Thomson

November 16, 2017
Tweet

More Decks by Laura Thomson

Other Decks in Technology

Transcript

  1. Build Exciting Things With
    Boring Technologies
    Laura Thomson
    [email protected] / @lxt
    1

    View Slide

  2. 2

    View Slide

  3. How did we get here?
    3

    View Slide

  4. 4

    View Slide

  5. Many conference war stories involve some kind of heroism, where the
    speaker did something great and everyone thought they were awesome.
    Image credit: https://commons.wikimedia.org/wiki/File:Saint_George_and_the_Dragon_by_Paolo_Uccello_(Paris)_01.jpg
    5

    View Slide

  6. Hint:
    This isn’t that kind of story.
    6

    View Slide

  7. 7

    View Slide

  8. Why?
    Homogeneous and batteries included
    Removes dependency complexity
    Enforces static typing, a consistent data model, and a toolchain that
    leverages both
    Elm is more approachable than React+
    Includes FFI (foreign function interface)
    8

    View Slide

  9. Sounds great, right?
    9

    View Slide

  10. Why not?
    Mostly situational, like many tech decisions:
    Solves the wrong (that is: non-critical for us) problems
    Standardized everywhere else on React
    Limits inter-project mobility and career development
    Backed by smaller team, less adoption, earlier in the tech curve
    No compelling reason to re-write relatively new code
    Anti-dogfooding
    10

    View Slide

  11. 11

    View Slide

  12. People were unhappy
    Not a manager’s job to make this decision
    My take: I agree, but strategic and business input needed
    Each team should choose whatever tools are best for them
    My take: Vehemently, no
    12

    View Slide

  13. This story doesn’t have a happy
    ending.
    Life just goes on.
    Few decisions are forever.
    Image credit: https://pxhere.com/en/photo/1285541
    13

    View Slide

  14. Moral of the story
    Image credit: https://commons.wikimedia.org/wiki/File:Page_39_illustration_to_Three_hundred_Aesop%27s_fables_(Townsend).png
    14

    View Slide

  15. Technology choices are hard.
    15

    View Slide

  16. I’m a stick in the mud.
    16

    View Slide

  17. I’m a stick in the mud.
    17

    View Slide

  18. Some technologies where I have been an early adopter
    18

    View Slide

  19. Some technologies where I have been an early adopter
    19

    View Slide

  20. – me
    “We should ship Firefox like a web app:
    aim for continuous delivery”
    Also
    20

    View Slide

  21. How should I make technology choices?
    And when?
    21

    View Slide

  22. Keeping up
    (with the Joneses/Stock Puppets)
    (and Hacker News)
    22

    View Slide

  23. What’s your stack?
    23

    View Slide

  24. 24

    View Slide

  25. How many of these
    are you using?
    Credit: https://www.hntrends.com/
    25

    View Slide

  26. What about these?
    Credit: https://www.hntrends.com/
    26

    View Slide

  27. Why pay attention to trends?
    Will I ever get another job?
    Will I be able to hire developers to work on my stack?
    Without these things how can I possibly make a good product?
    27

    View Slide

  28. Will I ever get another job?
    (Will it be the job you want?)
    Photo credit: https://www.flickr.com/photos/crash-candy/2310618299
    28

    View Slide

  29. Learning new things == good
    Side projects
    Open Source
    Adoption at work: on what?
    Core product?
    Experiments?
    Tooling?
    29

    View Slide

  30. But beware the Jabberwock
    Which things should I learn?
    Image credit: https://upload.wikimedia.org/wikipedia/commons/d/d0/Jabberwocky.jpg (public domain)
    30

    View Slide

  31. (this is a good book)
    Different technologies lead
    in different career directions
    31

    View Slide

  32. Financial Services
    Big Data
    Android
    32

    View Slide

  33. Startup Consulting
    33

    View Slide

  34. Back on JS Frameworks: Longevity
    Credit: (Great article)
    https://www.bitovi.com/blog/longevity-or-lack-thereof-in-javascript-frameworks
    34

    View Slide

  35. Hiring
    Different types/geography/sizes of applicant pool for
    different technologies, e.g.:
    Harder to attract good applicant pools to “boring” stacks
    Harder to compete for e.g. machine learning in the Bay
    Area
    Hard to scale on a tech with not many developers available
    yet (aka, “I need to hire a hundred Haskell experts”)
    35

    View Slide

  36. What technologies should I use
    to make a competitive product?
    ( ^ core question, right there)
    36

    View Slide

  37. When should I adopt new
    technologies?
    ( ^ core question, right there)
    37

    View Slide

  38. Gartner hype cycle
    38

    View Slide

  39. Factors in early adoption
    Organization type and stage
    Relationship to technology
    What you’re building
    Audience
    Limited options
    Risk appetite/budget
    Standardization
    39

    View Slide

  40. Organization
    Good places to be early:
    Small startup
    Consulting firm / agency
    Big company with R&D
    Academia
    40

    View Slide

  41. Organization
    Hard places to be early:
    Medium sized company
    Not a tech company
    Not your core area of expertise
    41

    View Slide

  42. Relationship to Technology
    Good (best) reasons to be early:
    Dogfooding (but beware NIH)
    Building your reputation / expertise
    42

    View Slide

  43. What you’re building
    Is it your core product?
    Is it a critical tool?
    What is currently not great in the tech you’re
    considering? Does it matter here?
    43

    View Slide

  44. Audience
    Who are you building for?
    Internal tools: developers on $3k laptops with broadband
    Mass market: much wider array of hardware/bandwidth
    How many of them are there?
    Will this new tech scale to that?
    44

    View Slide

  45. Limited options
    This is the only way to solve a problem
    (Or) Huge leap forward in solving a problem
    45

    View Slide

  46. Risk budget
    Every organization has a certain appetite and budget
    for risk
    Is risk of adoption within your budget?
    Is risk of failing to adopt within your budget?
    Is this the place you want to spend it?
    46

    View Slide

  47. Standardization
    If this goes well, can I replace an existing
    technology with it?
    Or am I adding complexity/proliferation to my
    stack?
    47

    View Slide

  48. Time for another story
    (This one has a happy ending)
    Image credit: The Princess Bride
    48

    View Slide

  49. 49

    View Slide

  50. – Dave Herman
    “[W]e were looking for better ways to build
    browsers. We were particularly interested in two
    things: how to build more ambitious parallel
    architectures, and how to implement high-
    performance software without many of the
    pitfalls and vulnerabilities of C++.”
    50

    View Slide

  51. Long term bet in 2009:
    Invent a new programming language to enable
    making better browsers.
    51

    View Slide

  52. Image Credit: Lin Clark
    https://hacks.mozilla.org/2017/11/entering-the-quantum-era-how-firefox-got-fast-again-and-where-its-going-to-get-faster/
    52

    View Slide

  53. 53

    View Slide

  54. Questions?
    [email protected] / @lxt
    Slides will be at https://speakerdeck.com/lauraxt
    54

    View Slide