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).
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.