Enthusiastic IT generalist. Spent most of my time doing everything with computers since a very young age. If it can be done with a computer, I've probably done it.
Instead of saying "It doesn't work", try "I didn't do it right."
Doesn't sound that helpful really, BOTH cases are common when you're working with code. Sometimes 3rd party code, or code written by your colleague etc. doesn't work, sometimes yours doesn't.
Playing the blame game is usually completely unproductive, it doesn't matter if it's the problem of a 3rd party library, your code, or your colleague's code, what matters is why doesn't it work and how to fix it. Similarly I see people use IDE annotation + version control "blame" features to find the person to literally blame for a problem, which is not ok. However those features can sometimes be used to find a person who could help you out, if you're actually stuck or in panic mode.
The important bit, like the post says, is that something doesn't work and you don't know why, and you need to figure it out. Learning to debug, to figure out which parts you're absolutely certain work correctly, is one of the most useful skills as a programmer.
Learning to figure out which bits to debug is probably one of the most difficult things, e.g. instead of trying to figure out if "arrays are not working right in your programming language" (hint - they're probably not), you could try to figure out what's being stored in those arrays for real.
Also finding the careful balance of trying to figure things out for yourself and when to ask for help is a difficult one - one decent guideline is that if you can't explain the problem to someone else, you probably should try for a bit longer. E.g. "it doesn't work" is not an explanation, but "user registration is failing, apparently this check is failing here, but I can't understand why" is already some sort of a starting point.
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.
Doesn't sound that helpful really, BOTH cases are common when you're working with code. Sometimes 3rd party code, or code written by your colleague etc. doesn't work, sometimes yours doesn't.
Playing the blame game is usually completely unproductive, it doesn't matter if it's the problem of a 3rd party library, your code, or your colleague's code, what matters is why doesn't it work and how to fix it. Similarly I see people use IDE annotation + version control "blame" features to find the person to literally blame for a problem, which is not ok. However those features can sometimes be used to find a person who could help you out, if you're actually stuck or in panic mode.
The important bit, like the post says, is that something doesn't work and you don't know why, and you need to figure it out. Learning to debug, to figure out which parts you're absolutely certain work correctly, is one of the most useful skills as a programmer.
Learning to figure out which bits to debug is probably one of the most difficult things, e.g. instead of trying to figure out if "arrays are not working right in your programming language" (hint - they're probably not), you could try to figure out what's being stored in those arrays for real.
Also finding the careful balance of trying to figure things out for yourself and when to ask for help is a difficult one - one decent guideline is that if you can't explain the problem to someone else, you probably should try for a bit longer. E.g. "it doesn't work" is not an explanation, but "user registration is failing, apparently this check is failing here, but I can't understand why" is already some sort of a starting point.