Golden rules & learnings

Aiming at excellence πŸ’ͺ🏻

Our PR golden rules

  • 🐢 Eat Your Own Dog Food: test your code manually (incl. on mobile format)

  • βœ… All Hail The Green: ensure the specs are passing on the CI server

  • πŸ‡§πŸ‡ͺ Be a Citizen of the World: put all text in the I18n config

  • πŸ“· Tiny Is Beautiful: compress all images and put picture in .JPG format

  • πŸ“ L'Orthographe m'a Tuer: no spelling mistakes will be tolerated

  • β›© Consistency is the New Zen: ensure you respect your own naming and formatting conventions and that of the code

  • πŸ”— You Are Not Alone: watchout for collateral effects in CSS, across products, across helper methods

  • β˜€οΈ Sunshine Test: when we're a $1B start-up what you wrote will be read by thousands

  • 🐰 DRY: it never hurts to repeat that you should never repeat yourself

  • ❀️ Love Your Craft: be proud of what you code

Learnings from the field

  • Watchout for the demons of mental overload! 😈They'll devour you if you have more than 3 cards in WIP 🀯.

  • Never put instance variables within the view! πŸ‘€ Help yourself with helper methods instead πŸ’‘.

  • πŸ”’ Any attempts of improvement made anywhere besides the bottleneck are just an illusion of improvement πŸ”‘πŸ”“.

  • We are what we repeatedly do. Excellence, then, is not an act but a habit πŸ‘¨β€πŸ­. Continued self discipline in the execution of our craft, delivering an outstanding work, this is how we will one day reach perfection πŸ’ͺ.

  • β€‹πŸš€Deploying to production is a non-event. We are a DevOps team working hard on continuous integration and deployment πŸ’£. If you are scared to break everything, you’ve probably waited too long. The added business value is now at risk ⚠️.

  • Always start with the background context. Force yourself to level-up 🚁, structure your thoughts before even trying to come up with words to explain them. Otherwise, only you can understand the πŸ’©you are trying to throw at us πŸ¦€.

  • Silent corrections kill learnings πŸ‘¨β€πŸ«. When reviewing a PR always ask the reviewee to perform all corrections by themselves, so they can learn by doing πŸ‘¨β€πŸŽ“β€‹πŸš€.

  • DRY antipatterns can be far reaching! βœ…A good watchout: avoid duplicating content in the doc AND in the code. That’s why we say that good code is its own documentation πŸ“–.

  • A model must never be responsible for the way it is displayed πŸ‘€. Instead, use a decorator πŸ‘±β€β™€οΈthat will shape the DB according to the context.

  • The view is dumb πŸ§ β€‹βŒand must never contain any business logic πŸ€”. It shouldn’t handle anything else than display flags (show / don’t show) 🚩.

  • A presenter interacts with several models , while the decorator is used to add functionality to a single model (f.e.: CheeseBurgerDecorator πŸ”can decorate the Burger model 🍞).

  • Before diving in to coding πŸ’», make sure to fully understand the business goal of your work πŸ‘¨β€πŸ’Ό! Do not hesitate to ask questions until you know what the needs really are 🎯.