Another kind of over-engineering is speculative optimization (often called "Premature Optimization", but I like to emphasize the speculative nature of it, because that's the heart of the issue). Am I working to make the system faster in response to actual evidence of a performance problem, or am I just guessing about performance?
Over-engineering isn't always bad. It's all about predicting the future and weighing risks, with everything that entails. It's hard, but it's a fundamental part of design, and of life.
Whenever I'm unsure about whether a particular speculative generality or optimization is justified, I try to step back and find implicit assumptions. I try to turn "This might help some day" into "I'll need this if XYZ happens". If I can't do that, it's a bad sign.
And I agree with the original author's point: making mistakes in places where you can afford to fail, or where you can afford to recover, is a great way to learn.
"over-engineering" was not the point anyway. The title is a lie. The point was: dont be afraid of making mistakes (Over-engineering and the likes) when you can afford to, so you can learn from them and aim at high quality discussions on HN.
I have a strong personal opinion of when things become over-engineered, but that means little.
I've worked for smaller companies, which tend to under-engineer due to time restraints.
And I've worked for large corporations with such overkill process that it is amazing anything gets shipped ever. And yet it does, it takes almost forever, and costs far more than it should, but it does eventually ship.
Discussing "over-engineering" may be fine for general interest communities. But I think on HN we should aim higher. I'd love to have a rigorous discussion on how we can identify designs as either over or under engineered.