Created
August 7, 2015 16:12
-
-
Save erakor/d30b68d65a4ffe3d125a to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Ten Principles for Effective Front-end Development | |
*by Harry Roberts* | |
## 1. 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. | |
## 2. 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. | |
## 3. 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. | |
## 4. 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. | |
## 5. Pragmatism Trumps Perfection | |
* ‘Good enough’ today is better than ‘perfect’ tomorrow. | |
* Does it work? | |
* Measure features by their business value. | |
## 6. 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. | |
## 7. 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. | |
## 8. Do Not Make Decisions Based on Anecdotal Evidence | |
* Anecdotes are not representative. | |
* Anecdotes are isolated incidents. | |
* Trust data, not stories. | |
## 9. 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. | |
## 10. Expect and Accommodate Change | |
* Always keep adaptable, flexible, and nimble. | |
* Everything is subject to change. | |
* Nothing is set in stone. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment