A personal appeal. Overengineering works against results. Shifting the focus away from results is never good — for personal projects, corporate codebases, or anything in between. Overengineering over indexes on things you know. Overengineering invents new constraints instead of tackling real ones. The made-up constraints we tell ourselves are usually ones we already know how to solve (known-knowns vs unknown-unknowns).
These are good things to keep in mind, but there is still a line to walk here. Under-engineering is possible as well, which might be defined as putting something together quickly that only handles the happy path, no tests, difficult to read/understand/maintain, etc. I would say, write solid code that you’re happy to live with for the medium term, but that doesn’t introduce indirection that isn’t needed for current requirements.
Good lesson for folks who spend too much time editing and don't publish soon enough: don't let "perfect" be the enemy of "awesome."
Title should be changed to "Don't be bad at engineering". Engineering *is* simplicity.
These are good things to keep in mind, but there is still a line to walk here. Under-engineering is possible as well, which might be defined as putting something together quickly that only handles the happy path, no tests, difficult to read/understand/maintain, etc. I would say, write solid code that you’re happy to live with for the medium term, but that doesn’t introduce indirection that isn’t needed for current requirements.