5 Backend Mistakes That Will Destroy Your Career (Stop Doing These)

Eric Roby

8,310 views • 1 month ago

Video Summary

The video discusses five common but detrimental pieces of advice for backend developers. The first is the "Formula 1 mistake," which involves over-engineering for anticipated future needs that never materialize, leading to complex, unneeded code. The second, the "200 lines of disaster myth," discourages using well-tested libraries for common problems, pushing developers to reinvent the wheel with inferior, bug-prone custom solutions. The third, the "my code works illusion," advocates for writing tests later, resulting in untestable code, significant refactoring, and bug introduction. The fourth, "one-line wonders," encourages writing overly clever, condensed code that sacrifices readability and maintainability for perceived elegance. Finally, the "10,001 query problem" highlights the danger of ignoring performance until it causes critical failures, often due to inefficient database interactions. An interesting fact is that building a generic filtering system that took days was used only for its basic price-filtering functionality, while the advanced features were never utilized.

Short Highlights

Avoid over-engineering by building for current requirements, not imagined future ones, as exemplified by creating a generic filtering system when only price filtering was needed.
Leverage well-maintained libraries for common problems like retries, validation, and date handling, rather than reinventing the wheel, which often leads to over 200 lines of buggy code.
Write tests alongside code development, not as an afterthought, to ensure testability, prevent bugs, and gain confidence for future refactoring.
Prioritize code clarity and readability over cleverness; avoid overly complex one-liners, as code is read more often than written.
Design with potential scale in mind and avoid obvious performance anti-patterns like queries in loops, rather than ignoring performance until critical failures occur, such as a database slowdown caused by 10,001 queries.

Key Details

The Formula 1 Mistake [00:40]

The advice to "make your code reusable" and "don't write the same thing twice" (DRY principle) can lead to over-engineering.
Building a generic filtering system for products (price, category, color, size, brand) took days, but the team only ever needed to filter by price.
Over-abstraction and numerous configuration options make code harder to read, test, and change for features that might never be used.
The rule of thumb: Write code for current requirements, not imagined ones. Implement reusability when a pattern is proven by multiple use cases.

"I had built a Formula 1 race car in the filtering world when all we needed was a bicycle."

The 200 Lines of Disaster Myth [03:38]

The advice to "write it yourself so you understand how it works" for critical functionality, instead of using libraries, is detrimental.
Attempting to build custom retry logic without understanding exponential backoff, jitter, and specific error handling led to a 200-line solution with bugs, whereas a library would have taken minutes to implement.
It's crucial to understand what a library does and if it's safe, not necessarily how to implement it from scratch, especially for common, solved problems.
Utilize well-maintained, popular libraries for solved problems like retries, validation, date handling, and HTTP requests.

"I had wasted time trying to reinvent a wheel that already existed and my version was significantly worse."

My Code Works Illusion [07:57]

The belief that tests can be written "later" after the code is "working" leads to untestable code and significant rework.
"Done" rarely arrives as a definitive point; urgent issues constantly arise, delaying or eliminating test writing.
Writing tests alongside code forces better design, promoting isolation, focus, and clear inputs/outputs.
A "code, test, code, test" approach ensures tests are fresh, the developer remembers edge cases, and provides confidence for refactoring.

"Don't write tests after the code is done. The code is never done. Tests don't slow you down. Ultimately, they speed you up."

One-Line Wonders [12:10]

The temptation to use advanced language features (like list comprehensions, lambda functions) to write overly clever, concise code can be a trap.
Code that feels clever to write often becomes difficult to read and understand later, especially for others or oneself.
Code is read significantly more than it is written; clarity should be prioritized over showing off technical prowess.
While advanced features are valuable, they should be used judiciously to enhance clarity, not obscure it, unless they are common idioms within a team.

"Code that makes you feel clever when you write it often makes you feel stupid when you have to read it later."

The 10,001 Query Problem [14:41]

Ignoring performance considerations entirely until a critical failure occurs can bring down production systems.
A dashboard that worked for 100 users failed drastically when scaling to thousands, due to an N+1 query problem resulting in 10,001 queries.
The distinction between premature optimization (spending weeks on minor gains) and completely ignoring performance is crucial.
Practical approaches include avoiding obvious bad patterns (queries in loops), considering data growth, measuring what matters, and using "free" optimizations like caching.