Thank you. I have to admit, that it's again hard for me to pinpoint what exactly you're answering to and what's your argument. Either because I'm not that smart, I'm unwilling to accept some of what you say (for whatever psychological reason/bias), it is somewhat obscure, or all together. So, please forgive me, if I fail.

First of all, I'm not sure this is exactly an XY problem, because I started the discussion describing what exactly I was doing, what difficulties I faced, and how documentation can help solve them, in my opinion (yes, opinion). So there was no confusion what I want to actually achieve. I.e. faster and easier understanding of the code, which is the primary function of documentation. I.e. you read documentation, instead of reading code (sometimes many functions deep), thus saving time and effort. At least with sufficiently good documentation.

A counter argument was that documentation is not necessary, and the code alone is enough. Another was that tests are better than documentation, because they're verified to be correct. One person replied that when they started, they also tried to write documentation, but were discouraged by the project leader, and now they also support that approach. All of that is beside the point of the discussion, although provides context.

Yes, there is no evidence supporting the particular argument I was using. I was attempting to use logic and induction to change other people's opinion, so that they don't see documentation as a thing that "doesn't matter very much". It is hard to evaluate the effect of documentation and provide evidence without extensive data and research, similarly to how it is hard to evaluate why exactly the developer time was spent. I would be glad to see evidence, though.

OK, now I'll try to calm down a little, lower my defenses, and dig at the root of the problem.

The code is a mess, there is a metric shitload of it, and it is hard to understand. I wanted no more of that pain, and I wanted to have that fixed. I.e. to have the code easier to understand, no matter how. Perhaps this is exactly what I should have written. Instead I simply wrote that the code was complex (which is true enough) to try not to trigger other people's defenses, thinking that perhaps arguing for the documentation would be easier. I know that documentation helps, in many ways, but it would be just one way of fixing it. That way was also against the popular opinion, as it turned out. I may have also had a bias against people doing "the wrong thing" (TM), since I always document my own code.

So, perhaps, this situation and my approach is what you mean by the XY problem. I don't think that my proposed means are completely at odds with the ends, but I agree that they're unnecessarily limiting, rigid. I think that I would have been better off simply raising the issue itself and asking for solutions. Especially, since that particular piece of code is already considered problematic by many. Perhaps that's what I'll do.

I had issues with some people from that community before, and I do have my own communication difficulties, which makes it more complicated, and perhaps contributed to my choice of approach. Perhaps I'm a considerable part of that particular community problems too.

Please excuse me, if the above attempt at self-reflection is too personal for a stranger's HN comment. Thank you.