7 ms·

Or the difference between conceiving a child and raising one :)

danielvaughn 4y ago
Ha, love this one.
metaltyphoon 4y ago
I always smile when a green field project starts and then they claim its “Clean Code”. No, you won’t known if it was clean code until years down and the system will need updates. Then and only then you can reflect and see how hard it was to changes things in it.
- tasuki 4y ago
  Fully agreed. No matter how "clean code", the next person or team is immediately going to label it "legacy" and complain endlessly about all the choices made by the original author(s).
  - Jensson 4y ago
    Many dependencies? Updating them is hell, remove dependencies and just write the utilities we need so we can update to latest easily! Few dependencies? Too much reinventing the wheel, delete all that code and add dependencies! There is no perfect code, can always make different trade-offs and move things around.
    - deleted 4y ago
      [deleted]
- tacitusarc 4y ago
  My metric for clean code is how quickly a developer unfamiliar with it can understand it
  - agumonkey 4y ago
    It seems that anything successful, for any given era, is the one thing that minimize time to understanding better than others.
  - simonblack 4y ago
    Much as we denigrate COBOL, that is still its greatest advantage. Yes, it's wordy, yes it's old. Yes, it needs to be really updated. But it's still easier for a new hire to understand the COBOL old code than any other old code.
    - Ygg2 4y ago
      I've never had any problem digging into any Python codebase. Even magic stuff like `@attributes` is easily searchable.
- tomphoolery 4y ago
  I mean, a green field project is about as clean code as you can get. It's (reported) bug-free!
agumonkey 4y ago
raising someone else's that is already 4yo and emotionally harmed
- pojzon 4y ago
  This hits home. You win. Maintaining and cleaning up a mess someone left behind are two different things.
sdashner 4y ago
Whenever I do a big refactor it’s so that it will be messed up my way instead of being messed up their way.

Ha, love this one.

I always smile when a green field project starts and then they claim its “Clean Code”. No, you won’t known if it was clean code until years down and the system will need updates. Then and only then you can reflect and see how hard it was to changes things in it.

tasuki 4y ago
Fully agreed. No matter how "clean code", the next person or team is immediately going to label it "legacy" and complain endlessly about all the choices made by the original author(s).
- Jensson 4y ago
  Many dependencies? Updating them is hell, remove dependencies and just write the utilities we need so we can update to latest easily! Few dependencies? Too much reinventing the wheel, delete all that code and add dependencies! There is no perfect code, can always make different trade-offs and move things around.
  - deleted 4y ago
    [deleted]
tacitusarc 4y ago
My metric for clean code is how quickly a developer unfamiliar with it can understand it
- agumonkey 4y ago
  It seems that anything successful, for any given era, is the one thing that minimize time to understanding better than others.
- simonblack 4y ago
  Much as we denigrate COBOL, that is still its greatest advantage. Yes, it's wordy, yes it's old. Yes, it needs to be really updated. But it's still easier for a new hire to understand the COBOL old code than any other old code.
  - Ygg2 4y ago
    I've never had any problem digging into any Python codebase. Even magic stuff like `@attributes` is easily searchable.
tomphoolery 4y ago
I mean, a green field project is about as clean code as you can get. It's (reported) bug-free!

agumonkey 4y ago

raising someone else's that is already 4yo and emotionally harmed

pojzon 4y ago
This hits home. You win. Maintaining and cleaning up a mess someone left behind are two different things.

sdashner 4y ago

Whenever I do a big refactor it’s so that it will be messed up my way instead of being messed up their way.