when I initially asked, I got push back of, "why do you need this stuff"? Then the non-technical stakeholders realized when my colleague and I were behind on our work, thats when they started, "what do you, what do you need?"
Sounds like you didn't give a particularly good answer to their question as to why you needed it. Explaining in non-technical terms why you need a particular resource is a tricky skill to master but it's one that's every bit as important to a developer as the ability to write code. You need to be able to translate these technical requests into either business benefits of having them and/or business risks of not having them.
Has this ever happened to anyone? This is not a startup, this is a huge financial institution and they did not have me setup with any kind of Github or Bitbucket account, gave me a laptop with no ability to download anything I need to do my job.
It's not especially unusual for companies who are setting up their first "real" in house development team not to have this sort of infrastructure in place beforehand.
The department I work for is not the first development department, there is an offshore team that are developers and they have everything they need.
Actually it sounds as though you really are the first development department - offshore teams may technically be part of the same organisation but the way they operate tends to be much more black-box, as far as the non-technical stakeholders are concerned money goes in, code comes out.
In the latest development, my colleague and I requested our own staging server. Get this, they provisioned a staging server for us that we, as of this writing, still cannot access, yet their other development team that is offshore, does have access to it.
Sounds like the already established team has already established lines and procedures in place to accommodate them. In other news, night: dark, snow: cold. It might be worth communicating with the offshore team yourself to find out what channels they use/used in the business to establish this sort of thing. If they've already done the legwork in establishing means to get what they need from the business why not piggy-back on that instead of re-inventing the wheel?
I find myself being put in the position of a Tech Lead, teaching my colleague how to work with git and ensuring he pushes his code on time, that he has the git workflow down because the people we work for have no idea what that is or why it is important.
I'm afraid I don't understand why this is a surprise to you - it sounds like they don't have anyone in a tech-lead type role and of course non-technical stakeholders aren't going to know, or frankly care what the git workflow is. If the tech lead duties weren't something you accounted for when the role was initiated (and they conceivably may have had no notion that they needed such a thing) then you need to talk to your manager about the fact that this aspect is going to take up some non-zero portion of your work time. If the offshore team has their own tech lead then point that example out e.g. "Offshore Team has Joe already doing these responsibilities for them"
Whenever we have questions about the specs, mockups or assets, no one seems to absolutely know, and we are consistently referred to the other development team that is offshore, whose main modus operandi is to ensure their work is getting done. Sure they have access to all the developer tools they need, whereas my colleague and I had to justify for over a month why we needed those same tools.
Again I'm somewhat bemused at your surprise - of course they are going to refer you to their only existing technical resource. If the off-shore team isn't providing you with the responses that you need (when it sounds as though it's something your bosses want them to do) then escalate that failure to your manager, because then they aren't "getting their work done".
I mean, am I going nuts here? You hired me as a developer, yes I need the same tools, resources and permissions that your other developers have.
You're not going nuts exactly, but you do appear to be demonstrating some considerable naivety in expecting people from a completely different area of expertise to automatically know what you do. They're on a learning curve here and it sounds as though you aren't making any allowance for that. Is it frustrating to have to explain/justify requests from nearly first principles? Heck yeah. Especially when you are used to taking these things for granted.
But here's the thing - whining about reality not being the way you want it to be isn't going to change anything, so if you intend to stay where you are you need to dust off that "business skills" hat and put it on for a bit. When you identify a gap in the infrastructure go beyond the immediate effect on your workflow and consider the implications on that for the business because it's those implication that are going be your most powerful arguments for getting what you need.
If you need to practice this, try explaining the need to someone outside of work that's similarly non-technical, partner, family member etc. If you can put it in terms they can understand then you know you're headed in the right direction.
Finally, it has to be acknowledged that establishing and building an in-house development team (or any other new business function) is definitely a chunk of work, and often a thankless one but you need to be aware that it isn't going to "just happen" so if you aren't up for taking that challenge on then there's nothing wrong with that, but you might have to start looking for a more established environment where you can just hit the ground running. I've done it before myself more than once - not going to lie it was a slog at times, and I'm not sure I'd be particularly enthused about doing it again any time soon. So don't be afraid to ask yourself if this is truly the job you want at this stage of your career/life.
