Generality creep

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Apr 4 17:12:50 UTC 2019


On 4/3/19 8:33 AM, Guillaume Piolat wrote:
> I don't how long you've been around, but this community seems to me as 
> indeed unreasonable and often disrespectful (I've been doing it too at 
> times).

I also think we have patterns of negativity. In the recent days I have 
received a number of private messages also mentioning that as an ongoing 
difficulty (you know who you are; thank you). I'm not very worried about 
some heat in casual discussions in the forums, though all of us could 
use more civility. I am, however, worried about negativity "in 
production", i.e. on github and in DIP-related and other consequential 
exchanges in the forums.

My current hypothesis is it has to do with people's lack of time.

Consider modeling a "specialist short on time". For a while I tried to 
model lack of time as a sort of decrease in IQ. For sure that's happened 
to me. Whenever I gave myself only a few minutes to make a decision on a 
pull request, that would definitely count as a net decrease in competence.

However, that model is not very accurate. For example, a specialist 
short on time would still be able to point out a mistake that would 
escape a non-specialist.

So a better model is, a specialist short on time in a design or code 
review has a more negative bent than one with time. This is because 
software is quintessentially constructive. In math, proving a negative 
is difficult because the burden is to prove something can't exist. In 
software, proving a positive is more difficult because it must be 
constructed. What is easy in code and design reviews is small "proofs" 
that an existing proposal has a problem. It's also time effective - a 
threading specialist may see a five-line race pattern immediately. A 
programming languages expert would see how qualifiers are bad for 
postblits in a minute.

Most of all, pointing out a negative gives the reviewer undeniable 
expertise high ground and a sense of doing the right thing. I pointed 
out a problem, the reasoning goes, thus alerting people that a mistake 
could be made. The reviewer gets a good jolt of satisfaction and moves 
on with their day.

The fallacy within is akin of the one of broken windows. The first-order 
reasoning goes, a dangerous mistake is being averted and correctness or 
at least some notion of consistency (people in software design love 
consistency) is being preserved.

The second-order effects, however, are numerous and pernicious. The main 
problem is, again, the constructive nature of software: often, a pull 
request or some other proposal embedding a mistake originates from a 
genuine need. People need to use malloc and free in pure code. They need 
reference-counted collections that are also immutable. Then, our 
archetypal specialist-short-on-time reviewer points out how that is 
problematic and considers the matter done with. "The problem is solved," 
- the subtext reads almost triumphantly - "it can't be done". To a 
non-investor specialist interested in correctness, this is a perfectly 
valid outcome. To the poor sap who wanted to get work done, that's none 
too helpful.

Contagion is another second-order effect. People in the community, 
would-be contributors and reviewers, see specialists who are mostly 
negatively biased. Clearly they know what they're talking about, so they 
are admired and set the standard everybody is aspiring to. Soon enough, 
it becomes "comme il faut" to point out weaknesses in proposed code 
instead of doing the much more difficult and time-consuming work of 
helping improving it, proposing better alternatives, and such. So all 
reviewers turn negative, whether they are specialists or not.

As soon as I'd put a pull request that had any informational entropy to 
it (i.e. not 100% obvious and boring), I might as well put the ear to 
the ground to hear the sound of shovels digging. The Vickers getting 
mounted. Barb wire getting rolled. Reviewers were getting ready for 
trench warfare. It has sapped all of my creative streak. My students, 
enthusiastic but scared soldiers, hesitate when they hear my whistle. 
"They'll kill me if I put this pull request out for review," I heard 
more than once put this way or another.

More specialists would help, but many specialists with a short time each 
would be less than helpful. We need steady energy, not just the 
occasional jolt of power. Electrical grid, not lightning. Great Work 
done by invested specialists has the true potential to turn negativity 
around.


More information about the Digitalmars-d mailing list