5 ms·

|Harry Roberts - 10 Principles for effective Front-end Development| https://www.youtube.com/watch?v=8adsZeMQjGQ https://www.youtube.com/watch?v=8adsZeMQjGQ Be

|Harry Roberts - 10 Principles for effective Front-end Development| https://www.youtube.com/watch?v=8adsZeMQjGQ https://www.youtube.com/watch?v=8adsZeMQjGQ Beyond languages and frameworks. One of my favorite speeches on development which I periodically rewatch. It will make you a better developer in general. 1. The simple option is usually the best 2. Reduce the amount of moving parts 3. Understand the Business 4. Care less, care appropriately 5. Pragmatism trumps perfection 6. Think at product level 7. Do not design systems around edge-cases 8. Do not make decisions based on anecdotal evidence 9. Don't build it until you've been asked for it 10. Expect and accommodate change

sethammons 7y ago
I'd like to hear more about not designing around edge cases and what that means. Edge cases have to be accounted for, and accounting for them at design time seems important.
- quickthrower2 7y ago
  Not the op but I take it to mean avoid concrete concepts in code around those edge cases. For example in OO avoid making a derived class for a French tax calculation for your one French customer’s invoice. I’m assuming here that your product is not an accounting package and the tax issue is just for SaaS billing. Instead make the design loose enough that this can be accommodated by data. Maybe even manually enter their tax amount in a free text field. But tying up the code for that edge case (and doing so for every edge case) will lead to a complicated system.
  - macando 7y ago
    Pretty much this. It's especially true in startups where new features and edge cases pile up really fast. Solve a new edge case manually in the beginning (like adding a simple field instead of a smart calculation, like you mentioned) and work from there. It might turn out, in a few months, that that new feature nobody uses anyway so it's dropped. This is easier if you obey: 6) Think at product level

sethammons 7y ago

I'd like to hear more about not designing around edge cases and what that means. Edge cases have to be accounted for, and accounting for them at design time seems important.

quickthrower2 7y ago
Not the op but I take it to mean avoid concrete concepts in code around those edge cases. For example in OO avoid making a derived class for a French tax calculation for your one French customer’s invoice. I’m assuming here that your product is not an accounting package and the tax issue is just for SaaS billing. Instead make the design loose enough that this can be accommodated by data. Maybe even manually enter their tax amount in a free text field. But tying up the code for that edge case (and doing so for every edge case) will lead to a complicated system.
- macando 7y ago
  Pretty much this. It's especially true in startups where new features and edge cases pile up really fast. Solve a new edge case manually in the beginning (like adding a simple field instead of a smart calculation, like you mentioned) and work from there. It might turn out, in a few months, that that new feature nobody uses anyway so it's dropped. This is easier if you obey: 6) Think at product level