$30 off During Our Annual Pro Sale. View Details »

Providing Flexibility Through Constraint

jnwng
March 16, 2018

Providing Flexibility Through Constraint

product engineering meetup @ quizlet

jnwng

March 16, 2018
Tweet

More Decks by jnwng

Other Decks in Technology

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