Dont Assume Stupidity

Maybe you should read AssumeStupidityNotMalice first.

I don't believe that Wiki, its community or the kind of topics discussed here attract anyone genuinely stupid (nor malicious). So, if something you read sounds stupid, please think again. IMHO, it's much more likely that...

There is some kind of misunderstanding involved.
The other party comes from a different cultural background (Unix/Windows, different company culture, different kind of apps, different languages, different education, ...)
There is some kind of misunderstanding involved.
The other party experienced successes with tools and approaches that failed for you, and the other way round.
If you don't understand their answer ("42"), maybe it's you don't understand the (implied) question.
They have different values, goals and priorities than you.
There is some kind of misunderstanding involved.
... ?
Profit !

-- FalkBruegmann

I've added a few important ones to the list above, based on my experience -- AndrewMcGuinness

Not only that, but stupidity is relative.

''Stop talking about your relatives that way... mine too... ;-) -KirkBailey)

It is especially important to apply this principle to reading other people's code. Even if you see that the CodeSmells oh so badly and you could have written it so much better, it will do you no good if you will start throwing stuff out or changing it just because it looks wrong. However stupid the person who originally wrote the code was, probably he/she had some reasons for writing the code the way it is. (Of course, you will not be able to break too much if you have UnitTests to prove you wrong...)

Maybe this may sound trivial, but I have too often found that I don't follow this rule and then break some stuff or offend people by telling them their code is stupid when it actually isn't. --DmitryJemerov

I've met many of them. "Stupid" isn't the right word, but the willingness and ability to write good code is a rare talent. -- jtg

I find myself recommending this more and more in inter-departmental political situations as well (e.g. different parts of IT shops, across IT and business boundaries, etc). As a consultant, I often get to see both sides of a dispute (i.e. both groups see me as on their side) and I am constantly struck by how reasoned and logical both sides of the argument will be and how each side will say the other is being stupid, naive, lazy, malicious, etc. when really they are each defending a different position. Since I am not taking sides, but looking to resolve the dispute, I find that trying to get people to understand the fear of the other (defence of position is always based on fear) that is at the heart of the person's resistence (doing this from both sides at once can be especially effective). This works best by finding a person's courage, and working with it like a small flame to make it grow. Courage leads to Understanding, Understanding leads to Trust, Trust leads to Collaboration (they are no longer opponents, but on the same side now), Collaboration leads to problem resolution. Thus, nudging people to see their own courage, and the other's fear can lead to understanding. To do this, I had to first understand my own fears, and stop seeing the client as stupid, and start looking for their fears. -- BillCaputo

A positive way to state this principle would be to AssumeCompetence?. That, along with AssumeGoodFaith, avoids the apparent contradiction between AssumeStupidityNotMalice and DontAssumeStupidity. Besides, calling people "stupid" is not smart.

Yeah, okay. However, I have encountered people on this Wiki who eternally argue viewpoints that are just pure kaka. I have had to call them on it on rare occasions. An example would be the never-ending, useless drivel on ItDepends and ItDoesntDepend. What a total waste of time, and constant distractions from the same kind of people who talk just to hear the sound of their own voice. I do not assume stupidity. I assume BS.

Be careful about making a conclusion that other peoples contributions are without value. The communications added is meant for a wide audience, some less advanced in certain topics, others may be more receptive to a long winded discussions. It is often better to leave things alone first. Though you may wish to refactor a page next time you chance upon it again. See LetHotPagesCool.

There's a difference between assuming the coder is stupid and assuming the code is stupid. While I agree that the best practice is to assume there's a valid reason for stupid-looking code, the next step is to assume the code is stupid--and check with the original coder, if possible. I can't begin the count the times when I've asked a very competent coder why something strange works the way it does, only to get a reaction of, "Wow... I wrote that? That's stupid."

Everyone has momentary lapses of reason when programming--even if you find stupidity, don't flip the BozoBit on the programmer.

I reckon we are all a bit stupid thinking we know much.

See: ComplexBullCrapOrValidIdea, MostPeopleAreFlamingIdiots, TheTwoPrinciplesOfHumor

CategoryWikiMaintenance