I am sorry to hear that. While i also do encourage questioning, i believe asking a big amount of sporadic questions on relatively simple matters can lead to annoyance among mid/senior developers. Programming is mainly about solving problems, and the work include troubleshooting and testing things yourself. It is what your colleagues expect from a fellow developer regardless of experience. If you can tell them that you've made an effort and it still doesn't work, they would probably be more understanding.
I'd also recommend to ask for a session where you ask many questions at once if you haven't tried that.
I ask them questions because they don't have any proper documentation of their projects. Debugging code is fine but I have to go through unnecessary things just to solve one issue. That is actually time-consuming, and after that, they term me as a slow worker. I don't want to work there anymore.
This is true ... there are questions which are driven by curiosity ('how does this work') and there are questions that are more instrumental ('why doesn't this work').
Often the second sort arise because you're missing some deeper understanding of the problem, but even so - one should always try and solve problems oneself (say for 20 minutes), make a list of questions that you run into as you run into them, and then be able to ask them afterwards.
But I also have to say: pair programming is the very best way to ask transmit knowledge and understanding. Your senior pair knows you, sees how you're approaching a problem and will be much more equipped to understand your question as you're both in the same place (literally and metaphorically).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I am sorry to hear that. While i also do encourage questioning, i believe asking a big amount of sporadic questions on relatively simple matters can lead to annoyance among mid/senior developers. Programming is mainly about solving problems, and the work include troubleshooting and testing things yourself. It is what your colleagues expect from a fellow developer regardless of experience. If you can tell them that you've made an effort and it still doesn't work, they would probably be more understanding.
I'd also recommend to ask for a session where you ask many questions at once if you haven't tried that.
I ask them questions because they don't have any proper documentation of their projects. Debugging code is fine but I have to go through unnecessary things just to solve one issue. That is actually time-consuming, and after that, they term me as a slow worker. I don't want to work there anymore.
This is true ... there are questions which are driven by curiosity ('how does this work') and there are questions that are more instrumental ('why doesn't this work').
Often the second sort arise because you're missing some deeper understanding of the problem, but even so - one should always try and solve problems oneself (say for 20 minutes), make a list of questions that you run into as you run into them, and then be able to ask them afterwards.
But I also have to say: pair programming is the very best way to ask transmit knowledge and understanding. Your senior pair knows you, sees how you're approaching a problem and will be much more equipped to understand your question as you're both in the same place (literally and metaphorically).