Plugin causing duplicate entries in the document context menu

Friedrich W. H. Kossebau kossebau at kde.org
Thu Nov 15 01:30:10 GMT 2018


Am Dienstag, 13. November 2018, 10:18:27 CET schrieb René J.V. Bertin:
> There we go again...
> 
> First of, thanks for calling my professional background an anecdote. Really
> subtle, remind me to return the favour some day.

It's indeed less an anecdote, but might be the explanation why there is so 
often disharmony here.

A former butcher working in a hospital operating room will be looked strange 
at if they reason their modus operandi with their butcher experience. And vice 
versa a former surgeon working in a butcher shop.
You could be the world's leading heart surgeon. Or the best fugu cook ever. 
Does not matter if you simply try to apply best practices used to in the old 
domain in the new domain. Usually they are no longer "best", but instead at 
least irritating to the other professionals in the new domain, if not annoying 
due to being less productive or shifting responsibilities/duties to others.

Software development means working on usually highly deterministic systems, 
way less complex especially in dynamics than real world stuff. No need to do 
big number statistics to get an idea about some behaviour, you can go directly 
to the equivalents of e.g. DNA strings and watch and twist the DNA strings for 
protein generation (or whatever there is). No complicated tools and resource-
intensive operations involved, all basic software development work with basic 
developer tools.  Better even, you can if single thread do control the time 
during protein generation and press the pause button on the world, also inject 
sideeffects useful to create an image of the dynamics (like fprint debugging).
No time is spent on experimenting with environment conditions like temperature  
or add-ons and discussing about what might have best promise with your 
colleagues. You as developer first go directly to the protein generating DNA 
snippet and from there start to isolate the actual input or code which 
triggers the phenomenon. (ignore my metapher kitchen dna "knowledge" :) )

Software means doing systems that can be reasoned about and ideally locally 
are completely understood. And actually this "anecdote" also gives me an idea 
why I see so many things in patches discussed which I consider fixing 
symptoms, not root causes. This might be practice in other domains. It is 
ideally not in software development, one usually has especially with 
OpenSource software access to the root cause and can fix it there (and for 
everyone). Heck, the perfect software can be even formally verified.

This is why high-level languages have been designed/created instead of having 
us writing machine statements. So developers have expressions they as humans 
can interpret and execute in the brain to a good degree, all on their own 
without needing handholding (while still praying to the gods of compilers and 
chips that there are no reality distortions when it comes to the machine then 
doing the counterpart :)
Of course that also needs people writing understandable APIs and actual logic, 
but Qt/KF/KTextEditor/KDevPlatform here provides that IMHO in general.

> Collaborative means you can reach out to colleagues and ask if they have
> experience with something you're planning to do or are stuck with, which is
> all I intended with this post and that seemed perfectly normal here
> (dynamic menu items showing up multiple times is something that almost has
> to have occurred in the past).

Your first email was fine, could have been me writing that one, it was asking 
if the observed phenomenon triggered some bells with people, who could then 
give hints where the problem could be rooted.
The second email was the one which reflected the questionable working mode, 
just see all the "guess" and other conjunctives there, incl. thinking about 
solutions when the problem had not yet been understood.

Like Kevin said, in software development, asking your fellow developers to 
help in understanding the real reason for a certain observed phenomenon means, 
they in the end have to look at the very protein^Wmenu generating code as well 
to see what the real reason is in code. Nobody has all the existing lines in 
mind and can tell without looking at and reading the actual sources where 
exactly a possible wrong nucleotide^Wcode expression triggers the unwanted 
phenomenon.

As software developer you usually start to talk to your fellows only once you 
reached some code which you do not understand, despite having spent some 
reasonable time on it. With reasonable time > 3 minutes. And then you give 
your code-level parameters you observed. Not just describe the observed 
phenomenon in the UI. Instead providing the details of the problem to what you 
managed to reduce it on the code-level, so people do not have to repeat that 
exploration.

> You don't want others to ask you to do their work for them, but please don't
> expect them to spend whatever time it takes to pursue things that might be
> known to be impossible or unfeasible.

See, your initial question had triggeed me to look at the issue initially. It 
had took me a few minutes (thanks to KDevelop grep) to locate the code where 
the menu is generated and to get an idea how to log what and thus isolate any 
potential source of the duplicated entries. And you surely were able to do it 
in a similar time. Though I then would have had to do the actual work to 
further isolate the root cause. Thus I first stayed silent, as this all could/
would have been/actually now is done by you. Only your second email got me to 
say "dude!" 

As said above, "whatever time" should be way more than perceived 3 minutes. 

This is basic development work. I doubt you are not able to do it if you want 
to be a developer at same eye level (and by offering patches for review I 
assume you do). It's the first thing to do if no-one has an instant idea or 
pointer to what could be the actual reason. It's what you learn as one of the 
first things when learning programming.
Not doing it when no-one can explain the issue instantly effectively asks 
fellow developers to do this basic job for one. This is not collaboration, 
this is utilization. This is asking your fellow to stop scratching their own 
itch, but take their resources and scratch yours from the start.
Only a subset of people likes to be utilized, and they have special forums for 
that, this is not one ;)


tl;dr  It's fine to ask for pointers where to dig oneself or if digging is 
needed. But starting a discussion about the provided pointers and whether they 
could be right or wrong perhaps, is not, as it asks the pointing person to 
first go themselves to where they pointed to and dig and check for you if 
there will be something found by digging, When it is you who wants to get what 
is buried. And discussing about what to do with the content potentially found 
before it is dug up is also wasting resources, which we are short of.

Cheers
Friedrich




More information about the KDevelop-devel mailing list