Guess I'm in the rock star league, but I don't think I have a shitty attitude. I've worked with lots of weak programmers over the years and it can be disconcerning but that doesn't mean you should be an asshole for that.
When people you work with asks "what's this strange Dictionary class you're using?" you take a deep sigh (internally, not so that they hear it) and explains that "a dictionary is a hash" and then they ask "what is a hash?" and you say "it's something that converts from one type to another, say english words to german words"
It causes conflict no matter what you do so you try to reduce the risk of it. "What is a linked list?" you answer correctly and helpfully "It's like an array it's easy to insert and remove elements from. I've some books at home explaining data structures you might want to borrow?"
It's only when people refuse to take advice that you get the right to be impatient with them. For example, you might review someones code and point out the logical errors in it and if they don't believe you, you might even make a test case which crashes their code. If they then say "well, that's unlikely to happen in production anyway" then you know you're wasting your time with them. Better just let them "sink" on their own.
Btw, have you asked your colleagues for help? Maybe they are introverted and that is why you think they have a rotten attitude? Maybe they aren't as bright as you think because I've never met a great programmer who wasn't always willing to help underachievers.
If you're learning, it's really important to have the skill of narrowing down what it is you don't know and formulating a clear question about it.
I've seen all sorts of failure modes with that:
* People asking overly broad questions, e.g. if they are having trouble using, say, a dictionary class: "How do dictionaries work?" rather than "I'm trying to do x with a dictionary and I can't figure out how to make it work - I tried the put() method but it doesn't do what I thought." This makes it very difficult to dig into what's actually being asked and provide a relevant answer.
* People not admitting what they don't know. E.g. maybe they just don't have a clue what a dictionary is, yet won't admit it.
* People making a lot of assumptions and not articulating them. This tends to manifest as a really specific question that doesn't make sense. E.g. "I tried to build a spellchecker and dictionary is not returning the right thing." Then it turns out they assumed dictionary was prepopulated with the English language. This is even worse if the person can't/won't explain their thought process when prompted.
* Not reading any of the docs. I ran programming tutorials at one point and it was remarkable how many questions would have been answered by the introductory paragraphs of the tutorial if they'd read them instead of skipping it then spending 10 minutes struggling with a problem that didn't make sense to them.
* Unwillingness to talk through things systematically, e.g. explaining code line-by-line. It's surprising how often people will ask for help, then lose patience with you once you want them to spend any amount of time explaining things. This is enormously effective - half the time they realize their mistake on their own.
When people you work with asks "what's this strange Dictionary class you're using?" you take a deep sigh (internally, not so that they hear it) and explains that "a dictionary is a hash" and then they ask "what is a hash?" and you say "it's something that converts from one type to another, say english words to german words"
It causes conflict no matter what you do so you try to reduce the risk of it. "What is a linked list?" you answer correctly and helpfully "It's like an array it's easy to insert and remove elements from. I've some books at home explaining data structures you might want to borrow?"
It's only when people refuse to take advice that you get the right to be impatient with them. For example, you might review someones code and point out the logical errors in it and if they don't believe you, you might even make a test case which crashes their code. If they then say "well, that's unlikely to happen in production anyway" then you know you're wasting your time with them. Better just let them "sink" on their own.
Btw, have you asked your colleagues for help? Maybe they are introverted and that is why you think they have a rotten attitude? Maybe they aren't as bright as you think because I've never met a great programmer who wasn't always willing to help underachievers.