4 ms·
A big issue I'm having learning back-end coming from front-end was to gauge if my implementations were correct at all. With front-end you usually get immediate
by Zealotux 5y ago
A big issue I'm having learning back-end coming from front-end was to gauge if my implementations were correct at all. With front-end you usually get immediate feedback: CSS mistakes and infinite rendering loops are easy to spot. With back-end, poorly optimized code can run great in development and even beyond because stacks these days are very forgiving, up to a certain point where you have no idea why things are slowing down/crashes. In a sense: I find back-end to be more abstract, you have to visualize possible issues more and develop skills to stress-test and identify bottlenecks.
A thing that helped me so far was to demystify databases a bit – looking at you, Designing Data-Intensive Applications – but I'm still seriously struggling to be confident in deploying in production.
- radicalbyte 5y agoWrite automated tests for your code as you're writing it. Hitting the entire system is fine. If your code is properly factored then it should be easy to do. If not, then you get to learn how to factor your code. Test your backend with real data, not playsets. So use millions of records instead of 3-4. If you're touching database, then learn SQL, and learn the tooling for your database. Learn how to read a query plan, use the optimiser and design indexes.
- Zealotux 5y agoThanks a lot for the advice, really appreciate it!
- radicalbyte 5y agoMy pleasure. Hope that it helps. If you check out some of the "TDD with .Net guides" or "TDD with Java" (Pluralsight, Youtube) then you can see the flow in action. Backenders struggle with the same thing in the frontend but in reverse. For frontend, you need to be interacting constantly - the shorter the loop between code and frontend, the better.