Build Exciting Things With Boring Technologies

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Slide 3

Slide 3 text

How did we get here? 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Sounds great, right? 9

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Technology choices are hard. 15

Slide 16

Slide 16 text

I’m a stick in the mud. 16

Slide 17

Slide 17 text

I’m a stick in the mud. 17

Slide 18

Slide 18 text

Some technologies where I have been an early adopter 18

Slide 19

Slide 19 text

Some technologies where I have been an early adopter 19

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

How should I make technology choices? And when? 21

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

What’s your stack? 23

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Financial Services Big Data Android 32

Slide 33

Slide 33 text

Startup Consulting 33

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Gartner hype cycle 38

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Slide 50

Slide 50 text

– 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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Slide 54

Slide 54 text

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