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