John seems to have a very similar personality to myself, based on what you describe here; I could very easily see myself doing these same sorts of things. As such, allow me to explain to you what I think John means and how you should respond to me, if I was John and I was saying these things to you:
he said the way I approached a ticket "was dumb."
Saying your approach was dumb does not mean you are dumb. It does mean you're inexperienced, though, and that's ok. You should ask John for how he would have done it, and make an effort to learn from him, as he is the most senior developer on your team and you're the most junior (and it seems based on the tone of your question that you're a junior developer in general and not just junior to this company). If it was me, I would have followed up this statement with a description of exactly what "was dumb" about the way you did it, and how to do it better, and I would expect John did this and that is being "conveniently omitted" from the question. It's ok to have "dumb" solutions or approaches, as long as you learn from them and don't do sloppy work that someone else (likely John himself) will have to clean up after later.
I asked him for help with Git once and said that I had followed the instructions exactly (which I had) and he immediately answered "No you did something wrong."
He said this, because, if you followed the instructions exactly, then he expects that it should have worked. Therefore, in his mind, you probably did something wrong, because the instructions are perfect (even if they're not, they are in his mind). So you should take John over to your computer and show him what you did precisely and why it didn't work. That said, Git is a beast of an application and one wrong move could blow up your whole local repo. It does that sometimes. Don't be afraid of Git; when in doubt, copy your changes to another folder (desktop works best for me) and simply delete and recreate the local repo from scratch, then copy back your changes. Once you've done that, then you can show John what you did and show him why it doesn't work. In which case it will work perfectly, because broken software always works properly when somebody else is watching ;-)
He explains things incredibly quickly and constantly says things like "it's super easy", "that's all there is to it", and "should be just an hour or two." When I say that I did not understand him, he is shocked and says "What!? What do you mean you didn't understand me?"
John sounds like a very experienced Senior Developer, and even though he's only been at this company for 2.5 years I'd guess his resume goes back 10 or more. Anyone who is extremely experienced at something often has trouble understanding that everyone, including themselves, were at one point novices, and they have a hard time appreciating that and "ELI5"-ing their explanations. If John is explaining things too fast, ask him to slow down. If he's explaining too much, take notes (and ask him to slow down so you can take notes). If he's at too high a level, ask him to drill down a bit ("How would you do that, exactly?"). If you need a reference, ask him to provide a good reference that he would recommend ("If I have additional questions after, can you send me a good resource to look at?"), and so on. John will appreciate that you're taking initiative and actively listening, instead of letting everything go over your head for an hour and then asking him to repeat from scratch; that sort of behaviour is colossally annoying and is likely to get you to fail your probation.
I told him that some code crashed when I ran it, and he said, "What!? What do you mean it crashed?" He just didn't believe me.
It's less that he didn't believe you and more that he wanted more information. "When I ran this code, it crashed" is not particularly helpful. Yes, you have a problem. But I've run the code a million times and never had a problem; now you run it and you have a problem. So I can't fix this problem because I'm not experiencing it. You need to tell me more about the problem in order for me to help you figure out what's wrong. Rather than "when I ran this code, it crashed", it would be more helpful, next time this happens, to say "when I ran this code, I got an error message that said XXX, do you know what that error means?". That's something John can actually help you with. John is probably very busy; he doesn't have time to go back and forth, so saying "the code crashed" and him having to ask "was there an error message?" is something that's time-consuming and annoying for him. Instead, skip that exchange and go straight to "what's the error and how do I fix it?". John will see the former as a waste of his time; he'll see the latter as an actual problem that requires his attention.
He is usually the only one that talks to the customer and decides how long the tickets will take and who will do them. The few times that I have talked to the customer, he did not seem happy about it. There is no policy against it. I think he just likes to be in control.
This is because there is usually a chain of command, and that chain of command could have a number of reasons for it, depending on the relationship and situation. Here are a couple examples of why this might be the case:
If the client only has one point of contact, but your team has 5 developers, then the client has 5 times as many requests if your entire team was sending that one guy requests. If there's only 1 point of contact, then the requests can be bundled and handled all at one time, instead of willy-nilly. This wastes less of the client's time and is more professional from your company's side.
John might know the answer. If John is taking the role of project manager as well as senior developer (this is a thing that sometimes happens), John might know things that you don't think he knows if you think he's only the senior developer. You should tap John for as many of your questions as you can, because he probably has most of the answers, and then the customer doesn't need to be bothered. The less the customer is bothered, the more professional they think your company is and the more money your company will make.
Now, the bottom line is, right now, John's comments don't indicate that you're failing your probation period, especially if you were hired as a junior developer (if you were hired as an intermediate then I might be a bit worried, and as a senior then I'd be VERY worried). They indicate that John thinks you're green, which is fine if you're junior.
However, they indicate that John is becoming a bit annoyed with you, and you need to show John that you can perform in a more professional way. This doesn't mean you have to suddenly learn everything about everything; it's not about technical knowledge, and studying more is not going to solve the problem. It's about knowing how to tackle situations where you have problems that you don't know how to solve and you need to ask for assistance. This is a people problem, not a technical problem. It seems to me like John doesn't think you are able to participate properly in the assistance-feedback loop: You ask for help, you get assistance, you ask clarifying questions, you are given more assistance, you implement that assistance. It seems to me that you are failing in the first part ("when I ran the code, it crashed"), and the third ("John explains things incredibly quickly [and rather than ask him to slow down, I come to an online forum and complain about him to randoms on the internet]"), which necessarily means you are also failing in the final part.
Work on that. John will respect you more and give you a better review for your probation. Good luck!
