3 ms·

> It's unclear to me what the author is criticizing. The author isn't criticizing so much as observing. From TFA: The post is not about the Agnostic or his co

> It's unclear to me what the author is criticizing. The author isn't criticizing so much as observing. From TFA: The post is not about the Agnostic or his code, it’s about the dynamic of programmers eager to rewrite code in their own image, and the hypothesis that our (I am equally guilty of this behaviour) motivation for doing so is to emphasize the small differences between ourselves and others.

slewis 13y ago
Aren't you the author? I love how people missing the point actually reinforces the point. Well done.
- raganwald 13y ago
  I was the author. Now I'm a guy who wonders if those are my memories, or Tyrell's niece's memories ;-)
  - singlow 13y ago
    ...a mournful discovery. Those who agree with you are insane. Those who do not are in power.
  - RyJones 13y ago
    I've had the experience of violently agreeing with a comment I found on the web, only to find I wrote it years ago and had forgotten about it. Strange days.
    - rthomas6 13y ago
      I've had the experience of disagreeing with a comment I found on the web, only to realize that I wrote it years ago and had forgotten about it. I'm not sure if that's better or worse.
tieTYT 13y ago
1. I think you complicated your point by having the Agnostic write some code without any context as to why it exists and confusing 3 other developers. 2. I think you complicated your point by having the other programmers rewrite it incorrectly.
- raganwald 13y ago
  The more complicated I/we make/made this discussion, the more obvious it seems to me that having programmers who talk to each other is simpler than trying to make up and/or enforce rules to obviate the need for talking to one another.
  - nimblegorilla 13y ago
    It almost sounds like you are advocating a style of code ownership where programmers shouldn't make changes to other's code without talking to them. I realize the context of your article requires a coding example that is somewhat trivial to understand and pick apart by developers who have a "better way", but I also think it's a copout to claim that the programmers in your example are just refactoring code for the fun of it. A lot of people are rightly fixating on the formatting "feature" of not padding 2-digit zip codes. If I was on that project I could easily see myself wanting to reuse the zip-code formatter and running into an issue where my use case requires the 2-digit zip codes to get padded. On most projects a zip-code formatter shouldn't be such a big deal that it requires a meeting between programmers. If the original zip-code formatter had bizarro requirements then they should be made more explicit. For some reason the article avoids the biggest mistake in the whole process. Why did the other programmers make changes without ensuring the test cases passed?
    - raganwald 13y ago
      > It almost sounds like you are advocating a style of code ownership where programmers shouldn't make changes to other's code without talking to them. Sure, we could say there should be more tests, or people should run them. We can say there should be issues filed before you refactor things. We can try to introduce all sorts of processes for avoiding mistakes. And we'd be right. But it's also nice to talk to a human, even if just casually. I don't want to say "shouldn't X without Y" because then "shouldn't make changes to other's code without talking to them" is much the same thing as "shouldn't make changes without running existing tests" and "shouldn't check changes in without submitting tests that the code fixes." Shoulds and shouldn'ts should always be secondary to talking.

slewis 13y ago

Aren't you the author? I love how people missing the point actually reinforces the point. Well done.

raganwald 13y ago
I was the author. Now I'm a guy who wonders if those are my memories, or Tyrell's niece's memories ;-)
- singlow 13y ago
  ...a mournful discovery. Those who agree with you are insane. Those who do not are in power.
- RyJones 13y ago
  I've had the experience of violently agreeing with a comment I found on the web, only to find I wrote it years ago and had forgotten about it. Strange days.
  - rthomas6 13y ago
    I've had the experience of disagreeing with a comment I found on the web, only to realize that I wrote it years ago and had forgotten about it. I'm not sure if that's better or worse.

tieTYT 13y ago

1. I think you complicated your point by having the Agnostic write some code without any context as to why it exists and confusing 3 other developers. 2. I think you complicated your point by having the other programmers rewrite it incorrectly.

raganwald 13y ago
The more complicated I/we make/made this discussion, the more obvious it seems to me that having programmers who talk to each other is simpler than trying to make up and/or enforce rules to obviate the need for talking to one another.
- nimblegorilla 13y ago
  It almost sounds like you are advocating a style of code ownership where programmers shouldn't make changes to other's code without talking to them. I realize the context of your article requires a coding example that is somewhat trivial to understand and pick apart by developers who have a "better way", but I also think it's a copout to claim that the programmers in your example are just refactoring code for the fun of it. A lot of people are rightly fixating on the formatting "feature" of not padding 2-digit zip codes. If I was on that project I could easily see myself wanting to reuse the zip-code formatter and running into an issue where my use case requires the 2-digit zip codes to get padded. On most projects a zip-code formatter shouldn't be such a big deal that it requires a meeting between programmers. If the original zip-code formatter had bizarro requirements then they should be made more explicit. For some reason the article avoids the biggest mistake in the whole process. Why did the other programmers make changes without ensuring the test cases passed?
  - raganwald 13y ago
    > It almost sounds like you are advocating a style of code ownership where programmers shouldn't make changes to other's code without talking to them. Sure, we could say there should be more tests, or people should run them. We can say there should be issues filed before you refactor things. We can try to introduce all sorts of processes for avoiding mistakes. And we'd be right. But it's also nice to talk to a human, even if just casually. I don't want to say "shouldn't X without Y" because then "shouldn't make changes to other's code without talking to them" is much the same thing as "shouldn't make changes without running existing tests" and "shouldn't check changes in without submitting tests that the code fixes." Shoulds and shouldn'ts should always be secondary to talking.