5 ms·

Writing code that is well designed but not over-designed is a great skill. It is in every engineer to write the gold plated car, as it is in marketing and sale

Writing code that is well designed but not over-designed is a great skill. It is in every engineer to write the gold plated car, as it is in marketing and sales to always need the future tomorrow to gain competitive edge. The number of times I wrote beautiful code are quite numerous, the number of times it is still not used to its potential as well. In the end I spent too much time over engineering for a disastrous moment or extension that never happened, or was never requested by a customer. I have written godforsaken shortcuts that are used so frequently it made me feel proud and ashamed at the same time. Now, I have come to believe that knowing when to stop is the greatest skill of all.

meowface 7y ago
There really needs to be a blog post about this. (I'm sure there have been, but I feel like this isn't talked about enough.) A good percentage of HN readers probably already know most of the advice about bad design, but once you're at that more experienced level, you run into the inverse problem of knowing too much for your own good and wasting cycles over-designing and over-engineering. I've definitely been guilty of this, both at the level of high-level system/project/solution design, and at the level of code design and code abstractions. I've blown a ton of time and effort over-engineering things which never end up getting used or looked at at all years later, or even just to make things look nicer despite no one else ever using, reading, or modifying my code other than me. It can sometimes be hard to really accept YAGNI and be able to just move on even if the code isn't quite as elegant or DRY or abstracted as you might have preferred. When you're creating abstractions upon abstractions, you can lose sight of the original goals. I'm still learning to know when to stop, but I'm getting better.

meowface 7y ago

There really needs to be a blog post about this. (I'm sure there have been, but I feel like this isn't talked about enough.) A good percentage of HN readers probably already know most of the advice about bad design, but once you're at that more experienced level, you run into the inverse problem of knowing too much for your own good and wasting cycles over-designing and over-engineering. I've definitely been guilty of this, both at the level of high-level system/project/solution design, and at the level of code design and code abstractions. I've blown a ton of time and effort over-engineering things which never end up getting used or looked at at all years later, or even just to make things look nicer despite no one else ever using, reading, or modifying my code other than me. It can sometimes be hard to really accept YAGNI and be able to just move on even if the code isn't quite as elegant or DRY or abstracted as you might have preferred. When you're creating abstractions upon abstractions, you can lose sight of the original goals. I'm still learning to know when to stop, but I'm getting better.