Nice article, but man.. I don't carry all my arguments with me all the time for every decision that I make, you know :) Not to mention that if you asked me on the spot, I'd have 10 other things that I'd be thinking about right there and then. Plus, when I'm working, I'm not consciously trying to recite every argument for every decision that I make. I "just know". It's intuitively based on hundreds of previous decisions that I've made. Think about that :)
This misses the whole point. Anyone who's been doing this for long enough has a stockpile of "rules of thumb" they use to make snap coding decisions. And they rarely sit there and "recite every argument for every decision" they make. I get that. No one disputes that.
But that was never the point of this article. The real question is: "When someone else is coding something in a way that you don't personally like, what reason do you give to explain why you don't like it, and why they should possibly feel compelled to change it?"
Do you just throw up some baseless bromide like, "Well, umm... it's, uhhh... It's an antipattern!" And then just cross your arms and smile, content in the idea that you've somehow quantified your objection? Or do you try to give the person tangible, empirical, logical reasons for why their approach might not be ideal??
If you think that someone else's coding is indeed an antipattern, that's fine. But if your sole explanation of the "problem" is to tell them that it's an antipattern, then, well... that's kinda messed up.
The specific practice I outlined in this article is a great example of this. Even with all of the great comments left on the article, I've yet to have anyone give me any tangible reason why this approach may be an "antipattern".
To be clear, some people have pointed out some downsides to this approach. But that doesn't make it an antipattern.
Too often in our career field, one dev tries to shout down another by hollering that something is a "code smell" or an "antipattern" - when they can't give you any specific reasons why the approach is supposedly suboptimal.
I don't necessarily disagree, it really depends who is asking the question and who is answering. I definitely respect your passion for the craft, though. You obviously have the need to understand well what you do.
And about the other comments, for me, they are more than enough to call it an anti-pattern and leave it at that. But again it depends who that is coming from.
I've got colleagues whom I'd definitely challenge when they say something is an anti-pattern. I also know people who if asked the same question and say it's an anti-pattern, I'd stop there and start questioning myself instead of expecting them to answer to me.
So it's very contextual I'd say at the very least.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice article, but man.. I don't carry all my arguments with me all the time for every decision that I make, you know :) Not to mention that if you asked me on the spot, I'd have 10 other things that I'd be thinking about right there and then. Plus, when I'm working, I'm not consciously trying to recite every argument for every decision that I make. I "just know". It's intuitively based on hundreds of previous decisions that I've made. Think about that :)
This misses the whole point. Anyone who's been doing this for long enough has a stockpile of "rules of thumb" they use to make snap coding decisions. And they rarely sit there and "recite every argument for every decision" they make. I get that. No one disputes that.
But that was never the point of this article. The real question is: "When someone else is coding something in a way that you don't personally like, what reason do you give to explain why you don't like it, and why they should possibly feel compelled to change it?"
Do you just throw up some baseless bromide like, "Well, umm... it's, uhhh... It's an antipattern!" And then just cross your arms and smile, content in the idea that you've somehow quantified your objection? Or do you try to give the person tangible, empirical, logical reasons for why their approach might not be ideal??
If you think that someone else's coding is indeed an antipattern, that's fine. But if your sole explanation of the "problem" is to tell them that it's an antipattern, then, well... that's kinda messed up.
The specific practice I outlined in this article is a great example of this. Even with all of the great comments left on the article, I've yet to have anyone give me any tangible reason why this approach may be an "antipattern".
To be clear, some people have pointed out some downsides to this approach. But that doesn't make it an antipattern.
Too often in our career field, one dev tries to shout down another by hollering that something is a "code smell" or an "antipattern" - when they can't give you any specific reasons why the approach is supposedly suboptimal.
I don't necessarily disagree, it really depends who is asking the question and who is answering. I definitely respect your passion for the craft, though. You obviously have the need to understand well what you do.
And about the other comments, for me, they are more than enough to call it an anti-pattern and leave it at that. But again it depends who that is coming from.
I've got colleagues whom I'd definitely challenge when they say something is an anti-pattern. I also know people who if asked the same question and say it's an anti-pattern, I'd stop there and start questioning myself instead of expecting them to answer to me.
So it's very contextual I'd say at the very least.