Ten Principles for Effective Front-end Development

Ten Principles for Effective Front-end Development at dotCSS, Paris. November 2014.

Transcript

1. Ten Principles for Effective Front-end Development Harry Roberts – dotCSS, November 2014
2. About Me Harry Roberts Consultant Front-end Architect I help companies write better UIs @csswizardry
3. Why this talk? Code is only a small part of our job. My focus shifted for the better. Specifics are good, but aren’t always transferrable.
4. #10CSS
5. 01. The Simplest Option Is Usually the Best 01. L’option la plus simple est souvent la meilleure
6. The Simplest Option Is Usually the Best Faster and cheaper to implement. Easier (for other developers) to understand, inherit, maintain, debug. Less likely to fail or break. Lessens the amount of cognitive overhead when working at scale.
7. 02. Reduce the Amount of Moving Parts 02. Réduisez le nombre de variables
8. Reduce the Amount of Moving Parts Get rid of as much as you can. Every moving part is a potential point of failure. You’re inviting the chance for something to go wrong. Reduce both features and code.
9. 03. Understand the Business 03. Comprenez les enjeux
10. Understand the Business Code itself is unimportant: it’s a means to an end. Understand the business cost and value of your work. Don’t waste other peoples’ money.
14. 04. Care Less, Care Appropriately 04. Ne vous souciez que des choses importantes
15. Care Less, Care Appropriately No one cares about your code more than you do. Pick the right battles. Remain objective. Balance the needs of everyone. Be less selfish. There is a much bigger picture to look at.
16. The User The Business The Team
17. The User The Business The Team
18. The User The Business The Team
19. The User The Business The Team
20. 05. Pragmatism Trumps Perfection 05. Le pragmatisme vaut mieux que la perfection
21. Pragmatism Trumps Perfection ‘Good enough’ today is better than ‘perfect’ tomorrow. Does it work? Measure features by their business value.
22. 06. Think at Product Level 06. Pensez produit
23. Think at Product Level Your job isn’t just to reproduce designs anymore. Do not put yourself in a bubble. Get involved with everyone else’s issues. Do what’s right for the product.
24. 07. Do Not Design Systems around Edge-cases 07. Ne concevez pas un système autour de cas particuliers
25. Do Not Design Systems around Edge-cases Don’t let the minority lead the majority. Build for the most common scenario first. Solve edge-cases separately.
26. 08. Do Not Make Decisions Based on Anecdotal Evidence 08. Ne prenez pas de décisions sur des anecdotes
27. Do Not Make Decisions Based on Anecdotal Evidence Anecdotes are not representative. Anecdotes are isolated incidents. Trust data, not stories.
30. 09. Don’t Build It until You’ve Been Asked for It 09. Ne développez pas tant qu’on ne vous l’a pas demandé
31. Don’t Build It until You’ve Been Asked for It You’ve caused yourself work, and cost the business money. No spec, so how do we know it’s right? How do we test it? Could end up influencing the rest of the project. Now you have to maintain something that no one even wanted. Solve each problem as you encounter it.
32. 10. Expect and Accommodate Change 10. Anticipez et adaptez-vous aux changements
33. Expect and Accommodate Change Always keep adaptable, flexible, and nimble. Everything is subject to change. Nothing is set in stone.
34. Ten Principles for Effective Front-end Development The Simplest Option Is Usually the Best Reduce the Amount of Moving Parts Understand the Business Care Less, Care Appropriately Pragmatism Trumps Perfection Think at Product Level Do Not Design Systems around Edge-cases Do Not Make Decisions Based on Anecdotal Evidence Don’t Build It until You’ve Been Asked for It Expect and Accommodate Change
35. Thank you Harry Roberts @csswizardry