Licensed civil engineer turned full stack developer building accessible, responsive web applications. I also review code in Frontend Mentor and participate in collaborative projects.
Wow, I just started exploring more into backend and I'm not expecting to learn great real-world topics here. But yeah, I agree. Less code is often good but we must also code what is required and what makes our codebase more robust. Thanks for this!
hey i'm adam. i'm a software engineer who's way too into backend, distributed systems, and hunting down edge cases for fun. also i play piano by ear and math's kinda fun
uh huh, “less code” is only good when it’s removing noise, not when it’s removing safeguards.
Once you start dealing with retries, failures, and multiple instances, robustness becomes part of the design, not an optional extra. And sometimes that naturally makes the code a bit heavier, even if the system is actually better engineered.
im glad it helped — this is one of those things that only really clicks once you’ve seen a few real production failures.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Wow, I just started exploring more into backend and I'm not expecting to learn great real-world topics here. But yeah, I agree. Less code is often good but we must also code what is required and what makes our codebase more robust. Thanks for this!
uh huh, “less code” is only good when it’s removing noise, not when it’s removing safeguards.
Once you start dealing with retries, failures, and multiple instances, robustness becomes part of the design, not an optional extra. And sometimes that naturally makes the code a bit heavier, even if the system is actually better engineered.
im glad it helped — this is one of those things that only really clicks once you’ve seen a few real production failures.