4 ms·

The entire human race is a cognitive bias, you can't have christians and muslims be right at the same time. One population of religious people must be wrong and

The entire human race is a cognitive bias, you can't have christians and muslims be right at the same time. One population of religious people must be wrong and therefore a huge portion of the population must be cognitively biased to an extreme degree of believing in something completely wrong. It is part of human nature to be hugely biased to a completely absurd degree and software engineers and scientists are not immune to this effect. The worst that I've seen this in (to the best of my ability, as I'm cognitively biased too) is in design patterns. Typical scenario: Object instantiation requires 50 parameters to be fully realized. Some coworker suggested that we instantiate an object with empty members and create 50 methods on an object that each take one parameter to load the object. Apparently having a function that takes 50 parameters create the object was a code smell because it didn't have a fancy name. That fancy name was "builder pattern." If you can't see how utterly stupid builder pattern is for this case... well... cognitive bias.

titzer 7y ago
> If you can't see how utterly stupid builder pattern is for this case... well... cognitive bias. You cannot win against the prevailing wisdom. Try having a public mutable field on a class, and watch people lose their ever-loving minds. But why do we have more than half of the classes' exposed with getters and setters? Mmmmfh. I think the problem is that it is really hard to reason about software in the large. So we reason about software in smaller and smaller granularity, e.g. classes. And then we want to load down every single class with armor as if it needs to be protected against the wild hordes of unwashed masses who will rampantly mutate it. But most classes naturally fit into a larger unit, a cohort of classes, and they are coupled with each other, and they mutually share state. You can't understand the whole thing by staring at a single class, anyway. But it feels like we are doing the right thing because we are told every class needs armor. Nevermind that now every class is 3x bigger, and so the whole thing is 3x bigger, which makes it 9x harder to fit in your head! Uggh!
- Nevermark 7y ago
  Well, obviously the simple solution is not to use getter/setter methods but simply overload the implicit get and set operators of the field when you do need to track or react to field value accesses and changes. Not a language option? ... Oh, so simple ... and yet, so far away.
  - crimsonalucard 7y ago
    No dude. The solution is not to use the builder pattern period. Just have a function/constructor with 50 parameters. Why? Because the instantiated object requires all 50 parameters to be fully realized. Having to call 50 separate setters means you can create an "invalid" object where only 23 setters are called. Why allow this to happen at all? It's like a null value, why allow that value to exist on a type? If you need all 50 parameters to be fully realized, then the logical thing to do is to only allow the object to exist with all 50 parameters in place. A constructor with 50 parameters insures that this fact is reality. It's that simple. Yet even you, with the answer right in front of your nose staring you in the face still thought that you 50 setters is okay with syntactical sugar! That's how powerful cognitive bias is with design patters. "Builder pattern" is a word that lends a sort of artificial aura into what is essentially stupidly dividing up a constructor into 50 setters for no good reason.

titzer 7y ago

> If you can't see how utterly stupid builder pattern is for this case... well... cognitive bias. You cannot win against the prevailing wisdom. Try having a public mutable field on a class, and watch people lose their ever-loving minds. But why do we have more than half of the classes' exposed with getters and setters? Mmmmfh. I think the problem is that it is really hard to reason about software in the large. So we reason about software in smaller and smaller granularity, e.g. classes. And then we want to load down every single class with armor as if it needs to be protected against the wild hordes of unwashed masses who will rampantly mutate it. But most classes naturally fit into a larger unit, a cohort of classes, and they are coupled with each other, and they mutually share state. You can't understand the whole thing by staring at a single class, anyway. But it feels like we are doing the right thing because we are told every class needs armor. Nevermind that now every class is 3x bigger, and so the whole thing is 3x bigger, which makes it 9x harder to fit in your head! Uggh!

Nevermark 7y ago
Well, obviously the simple solution is not to use getter/setter methods but simply overload the implicit get and set operators of the field when you do need to track or react to field value accesses and changes. Not a language option? ... Oh, so simple ... and yet, so far away.
- crimsonalucard 7y ago
  No dude. The solution is not to use the builder pattern period. Just have a function/constructor with 50 parameters. Why? Because the instantiated object requires all 50 parameters to be fully realized. Having to call 50 separate setters means you can create an "invalid" object where only 23 setters are called. Why allow this to happen at all? It's like a null value, why allow that value to exist on a type? If you need all 50 parameters to be fully realized, then the logical thing to do is to only allow the object to exist with all 50 parameters in place. A constructor with 50 parameters insures that this fact is reality. It's that simple. Yet even you, with the answer right in front of your nose staring you in the face still thought that you 50 setters is okay with syntactical sugar! That's how powerful cognitive bias is with design patters. "Builder pattern" is a word that lends a sort of artificial aura into what is essentially stupidly dividing up a constructor into 50 setters for no good reason.