Build Exciting Things With Boring Technologies

Keynote at php[world] 2017

Transcript

1. Build Exciting Things With Boring Technologies Laura Thomson laura@mozilla.com / @lxt 1
3. How did we get here? 3
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
6. Hint: This isn’t that kind of story. 6
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
9. Sounds great, right? 9
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
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
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
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
15. Technology choices are hard. 15
16. I’m a stick in the mud. 16
17. I’m a stick in the mud. 17
18. Some technologies where I have been an early adopter 18
19. Some technologies where I have been an early adopter 19
20. – me “We should ship Firefox like a web app: aim for continuous delivery” Also 20
21. How should I make technology choices? And when? 21
22. Keeping up (with the Joneses/Stock Puppets) (and Hacker News) 22
23. What’s your stack? 23
25. How many of these are you using? Credit: https://www.hntrends.com/ 25
26. What about these? Credit: https://www.hntrends.com/ 26
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
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
29. Learning new things == good Side projects Open Source Adoption at work: on what? Core product? Experiments? Tooling? 29
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
31. (this is a good book) Different technologies lead in different career directions 31
32. Financial Services Big Data Android 32
33. Startup Consulting 33
34. Back on JS Frameworks: Longevity Credit: (Great article) https://www.bitovi.com/blog/longevity-or-lack-thereof-in-javascript-frameworks 34
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
36. What technologies should I use to make a competitive product? ( ^ core question, right there) 36
37. When should I adopt new technologies? ( ^ core question, right there) 37
38. Gartner hype cycle 38
39. Factors in early adoption Organization type and stage Relationship to technology What you’re building Audience Limited options Risk appetite/budget Standardization 39
40. Organization Good places to be early: Small startup Consulting firm / agency Big company with R&D Academia 40
41. Organization Hard places to be early: Medium sized company Not a tech company Not your core area of expertise 41
42. Relationship to Technology Good (best) reasons to be early: Dogfooding (but beware NIH) Building your reputation / expertise 42
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
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
45. Limited options This is the only way to solve a problem (Or) Huge leap forward in solving a problem 45
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
47. Standardization If this goes well, can I replace an existing technology with it? Or am I adding complexity/proliferation to my stack? 47
48. Time for another story (This one has a happy ending) Image credit: The Princess Bride 48
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
51. Long term bet in 2009: Invent a new programming language to enable making better browsers. 51
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
54. Questions? laura@mozilla.com / @lxt Slides will be at https://speakerdeck.com/lauraxt 54