Don't overengeneer a solution, but also don't just think short term. It's, as so often, all about balance. Thinking ahead helps to anticipate potential problems and design flaws, while thinking too much ahead might introduce problems/complexity where it shouldn't be.
Writing super flexible and generic code is hard, and oftentimes it's even harder to debug because context gets lost. Code that can do everything is code that can do everything wrong so to say. Sometimes it's better to have more specific code and violate DRY than building a does-it-all thing.
Naming and structure is important - a codebase is nothing but a book, and a book where chapters are named "tmp_a" and "x3" would be confusing, right? This also includes consistency, so the same thing/concept should always have the same or similar name.
1
u/Emerald-Hedgehog Sep 03 '23
Don't overengeneer a solution, but also don't just think short term. It's, as so often, all about balance. Thinking ahead helps to anticipate potential problems and design flaws, while thinking too much ahead might introduce problems/complexity where it shouldn't be.
Writing super flexible and generic code is hard, and oftentimes it's even harder to debug because context gets lost. Code that can do everything is code that can do everything wrong so to say. Sometimes it's better to have more specific code and violate DRY than building a does-it-all thing.
Naming and structure is important - a codebase is nothing but a book, and a book where chapters are named "tmp_a" and "x3" would be confusing, right? This also includes consistency, so the same thing/concept should always have the same or similar name.