4 ms·
As a "full-stack" developer who started out on the backend and took on front-end work later in my career, I used to build back-to-front. You generally end up w
by jcadam 6y ago
As a "full-stack" developer who started out on the backend and took on front-end work later in my career, I used to build back-to-front. You generally end up with a cleaner, more scalable, and stable solution. That nobody wants. I've learned this lesson the hard way.
Start with the UX and work your way backwards. I don't like it from an engineering perspective, but it's the only way to go to build products.
Users just do not care what kind of horrible kludge is running behind the slick UI.
- ab8 6y agoAgreed. Unless it is a pet project for no one but yourself, the biggest challenge is figuring out what the problem is and arriving at a solution that works for the user. Since neither the user nor the programmer knows the right answer, we have to work iterations in. Each iteration is followed by feedback. Given how often we end up being completely wrong, it is best to get to the first feedback as quickly as possible.
- nmfisher 6y agoAgreed. I found that getting as close as possible to the user minimizes the amount of useless/superfluous code. Front-end is pretty much as close to the user as you can get.
- nohuhu 6y ago> it's the only way to go to build products. This! Back-to-front is a good way to build a scalable, performant, cleanly designed software. Front-to-back is the only viable way to build a usable product. > Users just do not care what kind of horrible kludge is running behind the slick UI. For 99.9(9)% of users, the UI is the product. Even those who do know what "back end" means, do not care.