Software engineers are often great people that I count as friends. They can be smart, witty, knowledgeable, and wise.
Then there's their downsides.
They engage in a variety of questionable behaviors ranging from condescension to bandwagonning.
They also believe in, repeat, and argue poorly researched or even just plain wrong myths:
Never use the table tag
React (or Vue, or Angular, or something else) is best and everything else sucks
TDD is the only way / TDD is dead
Why is that? How does a group of supposedly rational people with a science background constantly engage in so much bias?
Top comments (7)
Cognitive biases affect everyone, regardless of experience or education. Biases are particularly tricky because even if a person is aware of a bias, they typically only notice when others are guilty but not themselves.
Then again, I have been reading books like The Undoing Project, Mistakes Were Made (But Not By Me), and Misbehaving so this response may be affected by my own recency bias π
Based on my reading of Misbehaving, if Nobel Laureate economists and huge investment firms can make critical errors because of bias (especially in the latter case when there is a lot of hard cash on the line) then we should expect devs to make the same kinds of mistakes.
There is a great post about this topic, I think it resumes it pretty well:
Cognitive Bias and Software Engineering
Graham Trott γ» Oct 25 γ» 4 min read
I think a lot of that is peer pressure/social media pressure, which most people are susceptible to. They don't want to be seen to buck the trend.
Also cognitive dissonance is everywhere. You see medical doctors who also provide homeopathic remedies, despite knowing from their education that they can't work, for example.
Sometimes people don't think to question something because they were told it by an agent they perceive as an authority.
I think it just comes down to the fact that supposedly rational people are still people π€·ββοΈ
I was once like that.
Speaking from my experience, the main cause is lacking of experience and/or clinging to unrealistic dogma. We tried to set up the supreme principle, ideal methodology and perfect paradigm once and for all so we can happily live with that forever.
We thought we could generalize everything and strictly categorize them into "right" and "wrong" without anything in between. We hoped that once it is done, it would guide us through. Being dogmatic is everything, pragmatism is just for the weak who doesn't know right and wrong.
As we were creating our realm of perfection, what must be done is to judge whether what should be allowed to enter and what should be kept out. Again, there is no compromise on that. Whatever allowed in must be perfect, and what is not allowed in is evil.
Sometimes, being smart is also a curse. You know what perfection looks like, but you often don't realize we don't actually need perfection. We need to compromise, and as the people who can easily see imperfection, we do need to compromise a lot.
People get too wrapped up in things.
The best answer is the best one for your use cases and if it provides value. TDD can provide a lot of value if practiced appropriately, but I've also seen where (especially when applied to legacy code) it becomes a hassle.
The web framework debate is tiresome, and Vue and React (and in some cases Angular) can already do so many of the same things that all arguments just come down to preference and highly subjective reasoning.
I relish the opportunity to expand my knowledge and try new technologies that I'm unfamiliar with in my professional work. If they start to not fit my use cases well, there's always room for improvement or evolution.