Keep Criticism Narrow

Criticism should be kept as narrow as possible. Point out the problems and only the problems. Don't expand them into personal insults or wide judgments.

Example 1:

Wrong: "You are a big jerk!"
Right: "I disagree with your opinion about foo-oriented programming."

Example 2:

Wrong: "You don't seem to understand any of this."
Right: "I suggest we review your responses to items C, J, and K. Your answers puzzle me. I don't know where you got the impression that green squares go into yellow boxes."

Example 3:

Wrong: "You are lying. Dr. Glop never said that."
Right: "Your quote appears to be incorrect. Here's the correct passage according to page 123 of ..."

If the person wants your opinion about their general understanding or general competence, let them ask first. Otherwise, don't volunteer it.

If a person is frustrating you for whatever reason, leave the discussion (assuming the context of a wiki) before you are tempted to express wider opinions about given person. When in doubt, say nothing.

Our primal cave-men urges to lash out in frustration or chest thumping is harmful to civilized discussion. Yes, it's hard to resist the urge, but something we must do if harmony is a goal. Lashing out will likely not change the other party to fit your desires anyhow. Harsh or blunt criticism rarely solves anything. The other party probably has some harsh opinions of you also that they are holding back. Unleashing yours will either alienate the other party, or result in them releasing counter criticism.

While the above offers some good advice, I feel it should be noted that the "as narrow as possible" depends upon the claims being made. If the argument is organized such that one can clearly identify "items C, J, and K", then those can be targeted. If not, "You don't understand any of this" may indeed be "as narrow as possible".

But one should clarify where the alleged problem is first. It may just be a communication breakdown.
If the problem is somehow 'localized', then perhps 'where' can be clarified. Fallacy and some problems, however, are rarely localized.
Example?
One was provided.

And, to the contrary of the claim above, generalizing a person's (lack of) understanding can indeed solve problems. It can help a third-party audience - one not well enough experienced to be properly crtical of claims - know where to review evidence with caution. It is perfectly fair to note that a person has regularly used fallacy in his or her arguments, especially if it is easily proven. This might even help the other person IF that person is not a HostileStudent and is capable of critically reviewing his or her own claims. But you can't ask for everything.

But its such an overused accusation on the web that it is more likely to generate heat than light. Everyone thinks their opponent "doesn't get it". It reminds me of that survey where something like 80% of randomly surveyed people think they are better-than-average drivers. There's a topic on that somewhere on this wiki. (It may be that they use criteria that favors themselves, not that they are outright self-deceiving.)
An accusation is only "overused" if it's wrong. Claims of fallacy, I think, are underused.
It no longer carries any "punch" because it is overused. Readers ignore it as an authoritarian claim because it is over-used. For example, if a 5-year-old says their teacher is "stupid", they are probably ignored, *even* if they were right, because most 5 year olds probably hold that opinion at least once. The villagers hear "wolf" so often, from different people, that they ignore the next one like they did the last one......even if there really is wolf this time.
"Punch" isn't the issue if you're seeking "light". Truth is.
Truth not heard is still not heard. You need to take movies or photos or something if you want villagers to pay attention to your wolf call over the hundreds of bogus calls. Is your goal to be right or to be heard? If only the first, then you may end up being right in isolation. It may not even be your fault that others have abused CriticizeBluntly so much that your good criticism is dismisses and put in the same category as that of the empty shouters. But the environment is what it is. Don't complain about the rain, work around it.
Truth not heard is still truth. And there is often evidence (photos, movies, etc.) proving the truth before persons claim it. The issue of "not being heard" has nothing to do with lack of evidence; it has to do with willful ignorance. People who pander to the ignorant (be it willful or otherwise) by telling them lies and misrepresenting truths in ways they're willing to hear are called 'Charlatans' and 'Sophists' and are morally corrupt bastards that don't deserve respect or to be heard in ANY intellectual community.
[I don't see any evidence that Top is intentionally corrupt or wilfully misleading. I'm sure his intentions are good and he means well, but for whatever social, psychological, educational or genetic reasons, he does not possess the same appreciation for scientific or logical rigour that you do and he never will. His priorities are different to yours, but that doesn't make his priorities wrong. I imagine he's the sort who frequently spouts homey aphorisms around the office like "Keep it Simple, Stupid!" or "I don't care how you do it, as long as it works!" The VB coders in the room probably smile and agree; after work they buy him beers and say, "You da Man, Top!" The Haskell and LISP programmers swear under their breath. Top's managers keep paying him. If I were hiring, I'd hire one of him and one of you -- for different but equally-important purposes -- but I'd put your offices at opposite ends of the building. Y'all might want to consider doing the virtual equivalent here, because you're never going to agree on anything. Ever.]
There is no rigor in software engineering beyond machine performance. I'm just the messenger. It's all turned into a game between everybody to shape the "best practices" in their own image by overmagnifying their pet factors using over-simplistic, convoluted, or circular reasoning. If you can objectively prove X is better in all meaningful factors, be my guest. Until then, stop peddling fake rigor and claiming/painting everyone who disagrees with you as drooling VB hugger.--top
If you're just a messenger, then I suggest you find a source for these claims of yours that isn't so persistently wrong. First, as you've been informed many times, software engineering DOES NOT concern itself with demonstrating 'X is better in all meaningful factors' any more than architectural engineering concerns itself with whether bolts or screws are better in all cases. Only particular cases are of any concern, and risk, cost, and consequence must all be considered. E.g. whether gotos are bad in all cases is irrelevant... are they bad when you're doing a simple while loop? yes, because they offer no benefit relative to a language loop construct but introduce greater risk of error and make more difficult the optimizations. Second, there is a great deal more that is rigorous than machine performance: there is also AlgorithmicPerformance (independent of machine), correctness (for sorts, searches, databases, dispatch, optimizations, calculations, communications, etc.), safety (both type-safety and the sort of consideration for control-safety commonly seen in robotics, pacemakers, and city traffic-lights controllers), security (PKI and SecurityModels?, preventing buffer overflows, etc.), modularity, and more. I'm assuming you're just willfully ignorant on that second matter, as you've heard it all before but it never seems to stick for long in that opinionated and ridiculously 'custom business app'-focused brain of yours. In any case, even if you believe you're right, is your goal to be right or to be heard? - because, as a messenger, thus far you fail. Any truth you might be presenting seems quite heavily buried in that pile of what your proposed audience considers obvious untruths then is buried even further when you attempt to defend fallacy and error with yet more of the same. If you want to be a good messenger, improve that signal-to-noise ratio of yours.
That advice applies to everybody in the field. Our field has DisciplineEnvy because we haven't figured out how to apply rigor to software design outside of overly-narrow metrics. Some want to over-magnify these narrow metrics to promote their pet tool/technique. --top

(Moved Goto-related material to ObjectiveEvidenceAgainstGotosDiscussion. The split may not be perfect because there is a bit of interweaving of sub-topics.)

In some ways this reflects the on-going issue of OO design patterns: shouldn't they be built into the language if they are known patterns? It's also an argument against try/catch language idioms: something which can be handled with conditionals and other techniques. Some argue that languages are getting carried away in the way of LanguageIdiomClutter to keep up with the brochure-checkbox Joneses. Design-by-contract and AspectOrientedProgramming are other contenders for creeping featuritise idiom clutter. Generally we want our OWN favorite idioms in the language but not other's that we don't use much. I personally like blocks over gotos in most cases, but it has not been demonstrated that blocks are objectively better using sufficient and thorough rigor.

I see from your last statement that you're once again stubbornly beating the dead horse about 'objectively better' without dealing with a proper 'better for what' angle. When you get tired of doing so, maybe we'll have a reasonable conversation on that matter. When it comes to blocks vs. gotos, I don't believe there's even much overlap in their functionality. Might as well compare, with 'sufficient and thorough rigor', which of gotos vs. car wax is better.

Please clarify the non-overlap statement.
What is difficult to understand about 'non-overlap in functionality'? Hammers and Nails have different functions, and so arguing which is better is somewhat silly (better for what? pounding objects into walls?). I feel the same about your 'gotos and blocks' comments. Perhaps you should clarify what you mean by 'blocks' since, while there are about four variations of which I'm aware for meaning of 'block' relevant to software, none of them seem to be comparable to gotos.
I mean flow control structures such as IF, While, Case, etc.
I'm left baffled as to how you meant these and said 'blocks', but I do see how these items can be compared.
You are baffled by almost everything I do. I believe you to be bleeped in the head and vise versa. No need to repeat such.
Actually, most of what you do I can comprehend. It just disgusts me.
You disgust me too. The feeling is mutual.

I'm convinced that DesignPatternsAreMissingLanguageFeatures, or at least are indicative of missing language features. If you can't encapsulate and refactor a commonly used pattern into a library, something is broken with the language: either the language needs the pattern built into it OR the language needs a higher-level feature that would allow one to encapsulate that pattern into a library. The latter is a better choice, and is where the whole idea of subroutines and objects started. RealMacros, if combined with a symbol generator, would be a usable combination for encapsulating most patterns. I would note that DesignByContract and AspectOrientedProgramming are features you can't capture even with RealMacros or functions or procedures - arguing that they're LanguageIdiomClutter seems to me like another statement of gross ignorance on your part. In addition, I'd note that your statements above are an argument for try/catch language idioms, not against them - i.e. using try/catch obviates need for common patterns that programmers usually get wrong anyway... which is why they built the pattern into the language.

Note: replace my statements above about "machine-performance" with "performance-related issues". "Machine" is misleading. --top

NovemberZeroSeven and again JulyZeroEight

CategoryCommunication