6 ms·

It's unclear to me what the author is criticizing. If the argument is that putting form over function is bad, where form is more important than the thing actual

by leokun 13y ago

It's unclear to me what the author is criticizing. If the argument is that putting form over function is bad, where form is more important than the thing actually working, then I agree with the post. And that's what happened in the example, the rewrites all turned out not to work. Replacing working code with broken code is never good. If the argument that form is irrelevant as long as everything works, well then I disagree entirely. Just working doesn't mean it's good enough, and really the big reveal in the post is completely beside the point because all those rewrites did not work but that's not what the author is criticizing. Code has to be maintainable, it needs to be readable, and that matters. Also it's pretty much cliché at this point to trot out the straw-man turns everything into a verbose classes programmer. I've never seen anyone turn a simple one line function into 3 files of classes with tons of unnecessary methods ever in my career. In Java you do create classes for a single function sometimes, but that's because you have to.

cLeEOGPw 13y ago
> It's unclear to me what the author is criticizing. I think he is criticizing the desire of people to force their ways of programming on others.
- leokun 13y ago
  When people are forcing their ways of programming on others becomes a problem it's because of a lack of clear guidelines for the project. Code shouldn't be littered with half a dozen ways to do the same thing. It reduces maintainability and readability. Use a consensus or a person in charge to pick a way to do something that can be done many ways, and then always do it that way, and yes force people to program that way for the sake of the project. Some people, sometimes very skilled and extremely intelligent people, are just entirely process adverse, seeing it as needless as long as everything works. Yes working code is important, but being part of a team, and working with the team is pretty important. Maybe you don't need the process, maybe you can read code like Mozart writes music but others can't. But maybe think of your team sometimes who have to follow in your footsteps.
williamcotton 13y ago
When programmers are working together, like most things in life, it isn't really about the finer details, it is about people trusting each other. There are layers of trust. At a fundamental level I trust that my compiler works. I trust that the the standard library is going to work as expected. At a higher level, up in userland, I trust that libraries or modules that are used in a lot of places or that were written by respected members of the community. If I don't know them I can look at other things, like tests, demos, and documentation. Only when there is no other information, when you don't know of the person or their work, when you see no tests and no documentation, will you need to actually go in and look at the code. I take two things away from this. One is that in organizations where this is happening there are fundamental problems with co-developer trust. The other is that monolithic code bases where an organization owns the code rather than individual authors owning the code can lead to an atmosphere where no one and everyone feel that they have the say over specific implementation details. We can design systems and workflows that can implement and support developers trusting one another. If a team is building a system, components could be authored and published under individual author ownership, and then stitched together by the team to build a product. Of course this is fundamentally a transcendent problem. The issues aren't with the details of the system, the issues are outside of the system and with how the PEOPLE relate to one another.
- dingle_thunk 13y ago
  This is very true. I think it's also probably true that it gets harder to trust code as you get closer to the coalface, much the same way as when collaboratively working on a document, one may become frustrated by another person's grammar or style - yet a third party reading the document would not be able to tell the difference. This I suspect also applies to chefs, plumbers, architects, and many other professions.
raganwald 13y ago
> 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.
mcgwiz 13y ago
The author is not criticizing or championing anything. He's just being descriptive. He attaches to his description a reference to the psychological theory that similar people have an innate need to preserve a degree of individuality. This applies to tribes, romantic partners, and software development teams. While one may or may not agree with Freud, the article is at least food for thought. Presenting software conflicts in this way asks us to acknowledge our instinctual psychological motives and question our claims of objectivity, technical soundness and pure logic. This kind of in-fighting serves only the individual and not the team. Personally, I think there is great value in having a plurality of ideas and voices, but in a commercial setting, they must ultimately serve the team. This creates tension because individuals must be able to restrain their impulses.

by leokun 13y ago

cLeEOGPw 13y ago

> It's unclear to me what the author is criticizing. I think he is criticizing the desire of people to force their ways of programming on others.

leokun 13y ago
When people are forcing their ways of programming on others becomes a problem it's because of a lack of clear guidelines for the project. Code shouldn't be littered with half a dozen ways to do the same thing. It reduces maintainability and readability. Use a consensus or a person in charge to pick a way to do something that can be done many ways, and then always do it that way, and yes force people to program that way for the sake of the project. Some people, sometimes very skilled and extremely intelligent people, are just entirely process adverse, seeing it as needless as long as everything works. Yes working code is important, but being part of a team, and working with the team is pretty important. Maybe you don't need the process, maybe you can read code like Mozart writes music but others can't. But maybe think of your team sometimes who have to follow in your footsteps.

williamcotton 13y ago

When programmers are working together, like most things in life, it isn't really about the finer details, it is about people trusting each other. There are layers of trust. At a fundamental level I trust that my compiler works. I trust that the the standard library is going to work as expected. At a higher level, up in userland, I trust that libraries or modules that are used in a lot of places or that were written by respected members of the community. If I don't know them I can look at other things, like tests, demos, and documentation. Only when there is no other information, when you don't know of the person or their work, when you see no tests and no documentation, will you need to actually go in and look at the code. I take two things away from this. One is that in organizations where this is happening there are fundamental problems with co-developer trust. The other is that monolithic code bases where an organization owns the code rather than individual authors owning the code can lead to an atmosphere where no one and everyone feel that they have the say over specific implementation details. We can design systems and workflows that can implement and support developers trusting one another. If a team is building a system, components could be authored and published under individual author ownership, and then stitched together by the team to build a product. Of course this is fundamentally a transcendent problem. The issues aren't with the details of the system, the issues are outside of the system and with how the PEOPLE relate to one another.

dingle_thunk 13y ago
This is very true. I think it's also probably true that it gets harder to trust code as you get closer to the coalface, much the same way as when collaboratively working on a document, one may become frustrated by another person's grammar or style - yet a third party reading the document would not be able to tell the difference. This I suspect also applies to chefs, plumbers, architects, and many other professions.

raganwald 13y ago

> 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.

mcgwiz 13y ago

The author is not criticizing or championing anything. He's just being descriptive. He attaches to his description a reference to the psychological theory that similar people have an innate need to preserve a degree of individuality. This applies to tribes, romantic partners, and software development teams. While one may or may not agree with Freud, the article is at least food for thought. Presenting software conflicts in this way asks us to acknowledge our instinctual psychological motives and question our claims of objectivity, technical soundness and pure logic. This kind of in-fighting serves only the individual and not the team. Personally, I think there is great value in having a plurality of ideas and voices, but in a commercial setting, they must ultimately serve the team. This creates tension because individuals must be able to restrain their impulses.