Whenever I have to ask about how certain code of someone else works, I feel bad. I feel like I should be able to figure it out on my own.
On the other hand, if people ask me to implement something within their code, that I am not familiar with, I kinda expect more info? Like if you don't have any tutorials or documentation on your tool, be prepared to answer some stupid questions about how to set it up and whatnot. How else am I gonna know how to start with? Having to read the entire source code is a massive waste of time, no?

tl;dr: if you don't provide documentation or tutorials, be ready to answer stupid questions.

That's why I make readmes and howtos so that even years afterwards, people won't need to ask questions that I probably couldn't even answer from the top of my head anymore.

This is a tough nut.

If you ask me what eg

GibbleGobbbleGabbel(n)
<All kind of shenanigans, suddenly return>

does... ok. Completely understandable.

Send an email with a suggestions when to meet, prepare your questions, let's chat and try to understand it.
---

When you send a chat message with "help", followed by a wall of text and then a question tag afterwards... Nope. not gonna answer that.

But If you're lucky and the serotonin is high enough or my coffee pot is full I might be nice and say you should make an appointment...
Otherwise expect radio silence or a "get your shit together".

The last sentence will be my answer if I did look at the problem and realize it's not a complex problem, or If I have the feeling that you're a lazy bum trying to shift your work on my desk.... And I might become very abrasive if you pull this stunt on a daily basis ;)

Document what needs to be documented. If you need the full tour aka introduction, ok - make an appointment, we'll figure it out. All I need to know is that you tried to figure it out by yourself and can give clear questions instead of "stupid code no works you help me" ;)

@IntrusionCM i try to make my questions as precise as possible and I did spend a lot of time on a previous version of this tool so I do know roughly how it works. But it has grown a lot and there are many features of which I have no idea what the hell they are supposed to do or how to even get it to run.

Also, since people want this to be used by external users at some point, documentation will be needed anyway so why not put in some effort now, and have me and others test it while we need to get familiar with it anyway? It can only make things better

@hasu I wouldn't mind adding documentation.

I'm just grumpy and old and wanted to add that the "how" you ask for help is important.

Working together, respecting each other and building together documentation is a good idea.

Don't feel bad to ask questions, only feel bad if you do it in a non respectful way - is my message I guess.

A question isn't stupid as long as it shows that you took your time and put in an effort.

@IntrusionCM thanks ^^ I'm trying to be respectful even if I get emotional sometimes. What happenes to me a lot and what makes me mad, is that I try to find a solution, get stuck, send an email about it, then find a solution... I hate this. I literally stare at the email for like an hour going through stuff in my head wondering what else I can do to fix my problem. I dont come up with anything, decide to send the mail and then boom. Solution. T_T

@hasu If I encounter reasonable questions, I routinely check whether the documentation would have answered that. If the documentation is unclear or incomplete, that's a bug which needs to be fixed even if it's just for an internal tool.

You could side up with management here for process improvement because badly documented shit is a hidden project risk where you may suddenly need more time than planned just to figure it out.

Since this will hit everyone sooner or later, that cost will be a a lot higher than for the time the actual author would need to write it down once, plus that the author knows it best and thus doesn't have to waste time with guessing.

@Fast-Nop thank you a lot for your comment. Unfortunately we are a research group so there is not much in terma of management that I can go to. So what ends up happening is that I run to all the devs, gather info on how to use and setup their stuff, then I write a tutorial on it because either I'm asked to do so or I do it for my own future self. Then they send me other students so that I can help them setup that stuff. Rinse and repeat. ^^"

This is a proper example of experience. At work I have tons of legacy systems written by the kind of developers that MAKE people hate PHP, for the record, I fucking love php, I do, I know the language well enough to do whatever the fuck I want in terms of web and have gauged it against other stacks and still prefer it....BUT I can see the hatred, understand it and feel pitty for the people that go through it in the worst case scenarios.

Last friday I fixed a critical error on an application that contains about 300 files of the worst php code that could have been written by anyone, while this was a patch more than anything it was still to everyone, from the head of my department to the VP of my institution a testament of my ability, make this the same thing for you. It comes with experience, it comes with practice, it comes with you taking the time to sit down and become better than the shitlords that wrote it originally.

Don't despair, rise to the opportunity, rise to the challenge.