Slide 1

Slide 1 text

Providing Flexibility Through Constraint product engineering meetup @ quizlet 3/15

Slide 2

Slide 2 text

Jon Wong @jnwng Frontend Infrastructure @CourseraEng

Slide 3

Slide 3 text

Providing Flexibility Through Constraint

Slide 4

Slide 4 text

Figure out what you care about

Slide 5

Slide 5 text

Like any advice, take the following with a grain of salt. Our context is simply that, ours. 5

Slide 6

Slide 6 text

Here’s our context ● We have a lot of cruft and technical debt 6

Slide 7

Slide 7 text

Here’s our context 7 ● We have a lot of cruft and technical debt ● Our frontend team tends to the junior side

Slide 8

Slide 8 text

Here’s our context 8 ● We have a lot of cruft and technical debt ● Our frontend team tends to the junior side ● This is mostly about managing the JavaScript ecosystem

Slide 9

Slide 9 text

Building High Performance Web Applications 9

Slide 10

Slide 10 text

Figure out One Way™ to do things 10 There’s a lot of decisions that go into building a high-performance web application. ● How to fetch data ● How to render your application ● Dealing with user interaction

Slide 11

Slide 11 text

Figure out One Way™ to do things 11 There’s a lot of decisions that go into building a high-performance web application. ● How to fetch data ● How to render your application ● Dealing with user interaction Is it worth solving these problems more than once?

Slide 12

Slide 12 text

The Paradox of Choice ● Independence without constraint can be detrimental 12

Slide 13

Slide 13 text

The Paradox of Choice 13 ● Independence without constraint can be detrimental ● Most choices that don’t really matter.

Slide 14

Slide 14 text

The Paradox of Choice 14 ● Independence without constraint can be detrimental ● Most choices that don’t really matter. ● Provide extension points where it makes sense to.

Slide 15

Slide 15 text

Building a Great Developer Experience 15

Slide 16

Slide 16 text

Fix it yourself (or “Google-ability”) 16 ● Optimize for discoverability by taking advantage of things like open-source

Slide 17

Slide 17 text

Fix it yourself (or “Google-ability”) ● Optimize for discoverability by taking advantage of things like open-source ● Be a part of the community that has brought so much change to JavaScript 17

Slide 18

Slide 18 text

Fix it yourself (or “Google-ability”) 18 ● Optimize for discoverability by taking advantage of things like open-source ● Be a part of the community that has brought so much change to JavaScript ● Spend less time building things others have already solved.

Slide 19

Slide 19 text

YAGNI (You Ain’t Gonna Need It) ● Always start with “no” 19

Slide 20

Slide 20 text

YAGNI (You Ain’t Gonna Need It) 20 ● Always start with “no” ● “Great” doesn’t mean “new” — it means meeting the expectations of developers

Slide 21

Slide 21 text

Deciding when you do need it. 21 ● Fundamental paradigm shifts are easy to justify ○ Vanilla -> jQuery -> Backbone -> React

Slide 22

Slide 22 text

Deciding when you do need it. 22 ● Fundamental paradigm shifts are easy to justify ○ Vanilla -> jQuery -> Backbone -> React ● What determines a paradigm shift? ○ Does it change how you think and develop your product?

Slide 23

Slide 23 text

Deciding when you do need it. 23 ● Fundamental paradigm shifts are easy to justify ○ Vanilla -> jQuery -> Backbone -> React ● What determines a paradigm shift? ○ Does it change how you think and develop your product? ● Lateral movements are usually not worth it. ○ Switching between different flavors of Flux

Slide 24

Slide 24 text

Reduce Churn When Possible 24 ● Pilot changes before rolling them out. ○ Ensure you have a rollback plan in place.

Slide 25

Slide 25 text

Reduce Churn When Possible 25 ● Pilot changes before rolling them out. ○ Ensure you have a rollback plan in place. ● Optimize for fewer breaking changes. ○ Stopping the world is very expensive. ○ Incremental adoption ensures that you’re always in a working state.

Slide 26

Slide 26 text

The Role of Infrastructure 26

Slide 27

Slide 27 text

Solving problems for the 80% 27 Benefits from the One Way™ Moving between teams is like moving between states, not moving between countries. Most of the problems you’re solving are generalizable anyway. Improvements can be shared across your whole organization.

Slide 28

Slide 28 text

Good tools are half the work 28 ● Your developers need to understand how and why to use these tools

Slide 29

Slide 29 text

Good tools are half the work 29 ● Your developers need to understand how and why to use these tools ● Don’t just help, educate ○ Biweekly forums, workshops where you build stuff from scratch

Slide 30

Slide 30 text

Good tools are half the work 30 ● Your developers need to understand how and why to use these tools ● Don’t just help, educate ○ Biweekly forums, workshops where you build stuff from scratch ● Engineers in pain build the best solutions

Slide 31

Slide 31 text

Do you need a team to do this? 31 ● These sorts of decisions are already being made implicitly throughout your organization.

Slide 32

Slide 32 text

Do you need a team to do this? 32 ● These sorts of decisions are already being made implicitly throughout your organization. ● Have a North Star to guide your development ○ Having an opinion is different than knowing what you care about.

Slide 33

Slide 33 text

In Summary 33

Slide 34

Slide 34 text

Provide Constraints to Guide Development 34

Slide 35

Slide 35 text

Say “no” by default 35

Slide 36

Slide 36 text

Figure out what you really care about. 36

Slide 37

Slide 37 text

Thanks! comments / questions / complaints? @jnwng s/o to Gago for editing 37