3 ms·

I wish I could get this point across to my team. They will happily write: db.insert(record); // save the record to the database But when they write some crazy

I wish I could get this point across to my team. They will happily write: db.insert(record); // save the record to the database But when they write some crazy off-the-wall code (that's usually because they didn't understand the proper way to do something) I have to check the logs to see who wrote it and ask them why. Just the other day I was debugging an application that had a 6 second sleep at the end of the main() function. I just figured it was some dumb thing left in for debugging and deleted it, because there's no good reason to do that. The next day, the dev who put it in messaged me and said he put it there because the application was exiting before it had logged it's completion to our logging system. So I explained that the proper way to do this is to flush the log, not just hang the application for 6 seconds so that the last messages just happen to go through. If there was a comment explaining why there was a 6 second sleep, I could have just fixed it and educated the developer without causing any grief.

weatherlight 4y ago
thats a legit case of, "its impossible to gleam that fact from the code and the code alone." (although I would have left that as a comment for the reviewer in the PR) so if theres a conversation around that decision, it would have been captured there.)
- still_grokking 4y ago
  The discussion in the PR does not help the next guy… All why answers belong into the code, as comments.
layer8 4y ago
> I just figured it was some dumb thing left in for debugging and deleted it, because there's no good reason to do that. Look up Chesterton’s Fence. :) (I made similar errors more than once.)
- hbrn 4y ago
  You should be very careful applying Chesterton’s Fence to software engineering. Oftentimes the knowledge why fence exists is more valuable than the fence itself. And the best way to (re-)obtain this knowledge is to remove the fence and see what breaks. I've seen people get stuck for months being afraid to change a complex piece of code because nobody understands how it works anymore. The best course of action was to admit that knowledge is lost forever and the fastest way to gain it again is to repeat past mistakes. Of course, don't do this if your software is responsible for landing airplanes. But most of us are not landing airplanes here.
  - layer8 4y ago
    When you look at the original quote [0], it doesn’t necessarily disagree. You’re free to test what happens when removing the code, and when it then breaks you’ll know why the code was there, and can then decide what to do. However, when everything still seems to work after removing it, that is dangerous, because you’re likely to overlook some edge case or some unconsidered use case that may come back to bite you later. Of course, Chesterton’s Fence is just a guideline. You can weigh the risks against the benefits in each case. It’s just a reminder that there may well be very good reasons why some logic is in place. If it is at all possible to find out those reasons, then that would generally be preferable, in order to make an informed decision. [0] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
    - hbrn 4y ago
      > that is dangerous, because you’re likely to overlook some edge case or some unconsidered use case that may come back to bite you later. I know, and that's exactly why I don't like it. In my experience, lack of understanding bites you way harder than lack of a single fence. I once worked at a company that had a very complicated patented (!) algorithm to calculate a certain value. Not a single person in the company knew why it was so complicated, and nobody ever questioned it. We would constantly struggle to introduce new rules to it, because they would conflict with the old rules, and it wasn't clear how to resolve those conflicts. Since we didn't understand what value those magical rules provided, there was absolutely no way we could resolve conflicts in a way that retains the original value (if there was any). Eventually I was able to convince everyone and just removed all the rules we didn't understand. Everyone sighed with a relief. In hindsight, I believe the sole reason algorithm was so complicated was that having a patented algorithm would sound more sexy to investors, and you can't patent something stupidly simple.
ac50hz 4y ago
+10 Throwaway commenting often makes people feel as if they’re adding value, whilst fulfilling their obligations. Of course such comments have no value and worse, can distract from what ought to be commented. Perhaps ChatGPT has found a use, if it is asked to add comments to code, although I somehow doubt it…

weatherlight 4y ago

thats a legit case of, "its impossible to gleam that fact from the code and the code alone." (although I would have left that as a comment for the reviewer in the PR) so if theres a conversation around that decision, it would have been captured there.)

still_grokking 4y ago
The discussion in the PR does not help the next guy… All why answers belong into the code, as comments.

layer8 4y ago

> I just figured it was some dumb thing left in for debugging and deleted it, because there's no good reason to do that. Look up Chesterton’s Fence. :) (I made similar errors more than once.)

hbrn 4y ago
You should be very careful applying Chesterton’s Fence to software engineering. Oftentimes the knowledge why fence exists is more valuable than the fence itself. And the best way to (re-)obtain this knowledge is to remove the fence and see what breaks. I've seen people get stuck for months being afraid to change a complex piece of code because nobody understands how it works anymore. The best course of action was to admit that knowledge is lost forever and the fastest way to gain it again is to repeat past mistakes. Of course, don't do this if your software is responsible for landing airplanes. But most of us are not landing airplanes here.
- layer8 4y ago
  When you look at the original quote [0], it doesn’t necessarily disagree. You’re free to test what happens when removing the code, and when it then breaks you’ll know why the code was there, and can then decide what to do. However, when everything still seems to work after removing it, that is dangerous, because you’re likely to overlook some edge case or some unconsidered use case that may come back to bite you later. Of course, Chesterton’s Fence is just a guideline. You can weigh the risks against the benefits in each case. It’s just a reminder that there may well be very good reasons why some logic is in place. If it is at all possible to find out those reasons, then that would generally be preferable, in order to make an informed decision. [0] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
  - hbrn 4y ago
    > that is dangerous, because you’re likely to overlook some edge case or some unconsidered use case that may come back to bite you later. I know, and that's exactly why I don't like it. In my experience, lack of understanding bites you way harder than lack of a single fence. I once worked at a company that had a very complicated patented (!) algorithm to calculate a certain value. Not a single person in the company knew why it was so complicated, and nobody ever questioned it. We would constantly struggle to introduce new rules to it, because they would conflict with the old rules, and it wasn't clear how to resolve those conflicts. Since we didn't understand what value those magical rules provided, there was absolutely no way we could resolve conflicts in a way that retains the original value (if there was any). Eventually I was able to convince everyone and just removed all the rules we didn't understand. Everyone sighed with a relief. In hindsight, I believe the sole reason algorithm was so complicated was that having a patented algorithm would sound more sexy to investors, and you can't patent something stupidly simple.

ac50hz 4y ago

+10 Throwaway commenting often makes people feel as if they’re adding value, whilst fulfilling their obligations. Of course such comments have no value and worse, can distract from what ought to be commented. Perhaps ChatGPT has found a use, if it is asked to add comments to code, although I somehow doubt it…