This appears to be very much an interpersonal problem, and not necessarily initiated from the OP's side. I disagree with most of the other answers, since they try to ignore the "why" of the problem. They want to say "fix the process" or "do this/that for better communication" without understanding the reason for the coworker's behavior.
There's several possibilities that could be going on, but there's only 2 likely ones that I'll touch on.
- The coworker is trying to sabotage the project or the OP deliberately. This breaks down into 2 subcategories: failing the project because they don't like it; and failing the OP because they don't like them or because the OP has better (real or perceived) coding skills.
Trying to kill a project has some nuances to it. They could be morally opposed to it; they hate the language it's written in; they are bored with it; there's so much wrong with it they want to rewrite it instead of continuously fixing it; they dislike the customer it's written for; and so many more reasons than I can list. I'm sure we've all had those projects we "just hate". There's even some (slightly) legitimate reasons to want to kill a project, such as trying to kill off a Frankenstein of a 20+-year-old program that's had 80% complete projects scabbed on and translated between +4 languages that just needs to be completely rewritten from the ground up. Or letting hardware fail due to heat issues because the hardware was cheap junk to begin with.
If this is the case, it's best to have it be an open secret. Otherwise it's making other's lives a living hell. When people aren't part of that scheme, they have to take up the "slack" of fixing things and the people in on it grow to hate the people doing the "good faith" fixes.
When someone is trying to deliberately kill a project, doesn't tell anyone, and is not doing it for the benefit of anyone other than themselves, there's no training or communication that'll make them quit. There's no process change they'll adhere to and change their ways. They simply need to be removed from the project. This is a win for the company, since the person is no longer doing active harm to them, and if the person wanted to be taken off the project, it's a win for them as well.
- The coworker dislikes the OP because of some slight, real or imagined. It could be that the OP accidentally to purposefully stepped on the coworkers toes some time in the past and they haven't forgiven them for it. Maybe the OP has shown that they are a better programmer than the coworker, either deliberately or incidentally. Possibly the coworker is insecure and just believes something happened, could happen in the future, or just doesn't like them for no real reason.
Sometimes grudges last for a long time, even when the original "sin" was years past and the reasoning no longer matters. It's hard to get past that and sometimes it never happens. Mental maturity has a lot to do with this. It doesn't matter what the physical age of the coworker is, if they still act like a 10 year old, they don't have the maturity to handle some things, including someone being better than them at some things.
If they are insecure, they need positive reinforcement of the things they do well and encouragement to learn and practice the things they don't do well. The only time negative reinforcement should be used is when there is a clear "something" that shouldn't be continued and is paired with a replacement "something" to do instead. "Don't use your sleeve to wipe your mouth" is an example of negative reinforcement. Doing this alone is generally bad. Including direction to "use your napkin instead" pairs it with positive reinforcement of a replacement action and is considered a learning opportunity. Tone of voice and use of expletives can greatly change how this is perceived, though. A neutral or cheerful tone can make the experience stick more positively in a persons mind, while swearing or using a forceful or derogatory tone will make it a negative experience, likely making them more insecure.
Having the correct responses in situations will make people more confident. If they are constantly being derided for something like SQL injection and told to "RTFM" or "figure it out", they probably won't figure it out. I've heard this as "rock management". It's described as a "rock collector" here:
This manager is an enigma to the entire team. Everyone is eager to please her, bringing rocks of all varieties for her inspection and approval, but few ever pass muster. The rock collector keeps everyone guessing about what she really wants and causes frustration because she is never completely satisfied. This undermines the team's confidence.
If we know the expectations of people around us and we know the correct responses to give them, we can avoid dealing with all the negativity that goes along with answering incorrectly. Also, if we have confidence we have the real answer to a problem and know the people we're talking to want to hear the wrong answer, we can effectively argue that our answer is correct and not back down due to their ignorance.
It can take a lot of time and effort to help someone who is insecure, but take it from me as someone who became confident, it can happen. It takes years of learning, being coached, getting the correct feedback, and more to get there, but someone who was insecure can eventually become confident. Whether the OP and their company has that kind of time is a different issue.
If the coworker just doesn't like the OP for no reason, there's not likely anything to fix that. Sometimes communication can fix it and sometimes it'll make it worse. There's not a whole lot to do about this, although there's probably a bunch of books out there that try to solve it.
If the OP's coworker refuses to learn, refuses to change their behavior, refuses just about anything and everything to get them to be a team player, then it's time for other changes. Maybe the process and system really are broken. Do they have good reasons to not follow them? If they do, things do need to change. If they don't, then it's time to separate ways. Other's have spent time explaining how to change the process and "the system", so I won't go into that. This Answer is pretty long anyway.
Hopefully I've shed some more light on why knowing the reason behind the behavior is the key to solving he process, and why ignoring that "why" will likely never solve the problem.