5 ms·

Most programmers do not follow the Golden Rule, which is to write code you'd like to maintain with minimal training. It's a principle, but there are various ski

Most programmers do not follow the Golden Rule, which is to write code you'd like to maintain with minimal training. It's a principle, but there are various skills involved in doing it successfully, including writing, automation, design, seeking quality peer review, and a few other things. Similarly, writing code that can be deleted is an important skill. Using "good design" and "knowing your language" are fairly nebulous and somewhat tautological goals out of context. What is good design? Design that works well, I suppose? Most code is actually fairly easy to change in the future. Just slap another "if (isLeapDay(today)) dailyProfit * 28 / 29" wherever will solve the immediate bug. Is this a good idea? Nope. Why is it a bad idea? Well, it's the S in SOLID, probably, but the real reason is that someone would be surprised and chagrined to discover that design choice the hard way. Hence the Golden Rule.

UnpossibleJim 7y ago
While I applaud this and would love this rule to be in production, it tends to go against (the majority of) marketing's golden rule of, "I need this done in an unreasonable amount of time with unreasonable requests on functionality" and a management structure that tends to only flex to its subordinates instead of other departments, like they're supposed to.... though, I might be jaded =) I have seen a few very good managers/CTO's in my time and have left companies when they were forced out.
- deleted 7y ago
  [deleted]
zwp 7y ago
> writing code that can be deleted is an important skill Are you saying "I can easily delete this code from the project" is a metric for modularity? That's really interesting, is it your own thought?
- spawarotti 7y ago
  I saw it before. Deletion Driven Development is one of the many names. For me a good rule of thumb is: removal of a feature should result in a diff that deletes a bunch of files (classes in case of oop) completely, and only single lines in other files: the call sites to that feature.
- deleted 7y ago
  [deleted]
- edflsafoiewq 7y ago
  Write code that is easy to delete, not easy to extend: https://news.ycombinator.com/item?id=11093733 https://news.ycombinator.com/item?id=11093733
bastijn 7y ago
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.

UnpossibleJim 7y ago

While I applaud this and would love this rule to be in production, it tends to go against (the majority of) marketing's golden rule of, "I need this done in an unreasonable amount of time with unreasonable requests on functionality" and a management structure that tends to only flex to its subordinates instead of other departments, like they're supposed to.... though, I might be jaded =) I have seen a few very good managers/CTO's in my time and have left companies when they were forced out.

deleted 7y ago
[deleted]

zwp 7y ago

> writing code that can be deleted is an important skill Are you saying "I can easily delete this code from the project" is a metric for modularity? That's really interesting, is it your own thought?

spawarotti 7y ago
I saw it before. Deletion Driven Development is one of the many names. For me a good rule of thumb is: removal of a feature should result in a diff that deletes a bunch of files (classes in case of oop) completely, and only single lines in other files: the call sites to that feature.
deleted 7y ago
[deleted]
edflsafoiewq 7y ago
Write code that is easy to delete, not easy to extend: https://news.ycombinator.com/item?id=11093733 https://news.ycombinator.com/item?id=11093733

bastijn 7y ago

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.