Providing Flexibility Through Constraint

product engineering meetup @ quizlet

Transcript

1. Providing Flexibility Through Constraint product engineering meetup @ quizlet 3/15
2. Jon Wong @jnwng Frontend Infrastructure @CourseraEng
3. Providing Flexibility Through Constraint
4. Figure out what you care about
5. Like any advice, take the following with a grain of salt. Our context is simply that, ours. 5
6. Here’s our context • We have a lot of cruft and technical debt 6
7. Here’s our context 7 • We have a lot of cruft and technical debt • Our frontend team tends to the junior side
8. 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
9. Building High Performance Web Applications 9
10. 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
11. 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?
12. The Paradox of Choice • Independence without constraint can be detrimental 12
13. The Paradox of Choice 13 • Independence without constraint can be detrimental • Most choices that don’t really matter.
14. 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.
15. Building a Great Developer Experience 15
16. Fix it yourself (or “Google-ability”) 16 • Optimize for discoverability by taking advantage of things like open-source
17. 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
18. 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.
19. YAGNI (You Ain’t Gonna Need It) • Always start with “no” 19
20. YAGNI (You Ain’t Gonna Need It) 20 • Always start with “no” • “Great” doesn’t mean “new” — it means meeting the expectations of developers
21. Deciding when you do need it. 21 • Fundamental paradigm shifts are easy to justify ◦ Vanilla -> jQuery -> Backbone -> React
22. 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?
23. 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
24. Reduce Churn When Possible 24 • Pilot changes before rolling them out. ◦ Ensure you have a rollback plan in place.
25. 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.
26. The Role of Infrastructure 26
27. 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.
28. Good tools are half the work 28 • Your developers need to understand how and why to use these tools
29. 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
30. 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
31. Do you need a team to do this? 31 • These sorts of decisions are already being made implicitly throughout your organization.
32. 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.
33. In Summary 33
34. Provide Constraints to Guide Development 34
35. Say “no” by default 35
36. Figure out what you really care about. 36
37. Thanks! comments / questions / complaints? @jnwng s/o to Gago for editing 37