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

More Decks by Laura Thomson

Other Decks in Technology


  1. 2

  2. 4

  3. 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
  4. 7

  5. 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
  6. 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
  7. 11

  8. 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
  9. 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
  10. – me “We should ship Firefox like a web app:

    aim for continuous delivery” Also 20
  11. 24

  12. 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
  13. Will I ever get another job? (Will it be the

    job you want?) Photo credit: https://www.flickr.com/photos/crash-candy/2310618299 28
  14. Learning new things == good Side projects Open Source Adoption

    at work: on what? Core product? Experiments? Tooling? 29
  15. But beware the Jabberwock Which things should I learn? Image

    credit: https://upload.wikimedia.org/wikipedia/commons/d/d0/Jabberwocky.jpg (public domain) 30
  16. 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
  17. Factors in early adoption Organization type and stage Relationship to

    technology What you’re building Audience Limited options Risk appetite/budget Standardization 39
  18. Organization Hard places to be early: Medium sized company Not

    a tech company Not your core area of expertise 41
  19. Relationship to Technology Good (best) reasons to be early: Dogfooding

    (but beware NIH) Building your reputation / expertise 42
  20. 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
  21. 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
  22. Limited options This is the only way to solve a

    problem (Or) Huge leap forward in solving a problem 45
  23. 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
  24. Standardization If this goes well, can I replace an existing

    technology with it? Or am I adding complexity/proliferation to my stack? 47
  25. Time for another story (This one has a happy ending)

    Image credit: The Princess Bride 48
  26. 49

  27. – 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
  28. Long term bet in 2009: Invent a new programming language

    to enable making better browsers. 51
  29. 53