The other answers seem to be taking the view point that a "deeply specific, undocumented framework" is 1) problematic, 2) needs to be changed and 3) you should do something about. I would suggest first identifying whether there is a problem at all, and if so what this problem is.

> They have written their own specific framework with custom types, structures and models. 

This could be because this framework permits the developers in the company to implement the company's products/solutions effectively and efficiently. Or it could be a case of [NIH](https://en.wikipedia.org/wiki/Not_invented_here).

You haven't provided any information to tell which of these is the reality.

>  There is little to no documentation for it.

I expect that most software that is not used by other developers, including  the vast majority of corporate software, does not have documentation. So, alone this is not surprising at all.

> The software team is basically 3 developers that have been here for 10+ years who know the framework mostly by heart.

Are they producing software and solutions that work? Are they doing so efficiently?

> I'm a junior employee with 1-3 years of experience. I am supposed to be getting up to speed with this framework.

I agree that this can be challenging.

>  The framework is huge and so far it has been almost impossible to develop anything independently aside from minor things.

"Huge" and "not independently" don't necessarily go together. A framework that has many *interdependencies* is often difficult to develop in for a newcomer, because you have to understand the whole thing to not break something. A project that is well-organized with fundamental CS principles like single responsibility, encapsulation, defined interface boundaries can totally be worked on relatively "independently", you'll just be operating in one particular subsystem.

> I have been meeting with one of the developers to try and learn from them, but it's not going nearly as fast as I think it should.

You may need to adjust your expectations. In large systems it takes *months or years* to onboard completely. If you are used to small projects or start-up companies it is a very different experience to have worked for a big company for, say, 6 months and still feel like you don't know that much. *This* is normal in large companies.

So, instead of going by your idea of how fast you should be ramping up, **ask your boss** (or even one of the other developers that you are most friendly with, how well they think you are picking up the system).

Remember: by your own admission, they took 10 years to get to their present state.

> I have brought up the documentation issue with the manager, and although he agrees, the 3 people that could document the framework are always busy with projects that bring in money.

This is also normal. You are unlikely to succeed in getting the system documented. You *can* succeed in learning it, or you may find that your brain doesn't work in that particular language/architecture/coding style. I, for example, generally do not enjoy looking at Java code even if the library/program in question is smaller than a large Ruby framework I have no problem with.

>  What can I do about it?

First, and most important:

**Talk to your boss about what is expected of you and whether you are meeting the expectations.** If your boss is perceptive they may figure out that you need some words of encouragement and provide those, assuming you are in fact meeting expectations.

Then, formulate the problem. Are you unhappy with your onboarding **speed**? Do you not like the **architecture** of the system? Do you feel you are not receiving enough **support**?

Depending on what you perceive the problem to be, the course of action will vary.