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 🎯.