You can come on top in this situation but it's primary up to you.
Take advantage of your situation
There are three developers and you have the privilege to read their code. Most of the time when people start to learn on their own they sink themselves in guides and tutorials, most of which are written by people who do not necessarily have the correct background to be writing about the phenomena. You can do a small research about the developers' experience and if they fall under the criteria of being senior developers then you can try to get your head around how they write their code.
Every time a developer in your company is solving a problem in code you should question the code, How could this be written in a better way? If you can think of a solution that would probably be better then you should write emails to the specific developers, asking them questions like
Why did you use method X instead of method Y to solve this problem Z?
It's likely that you'll begin to see how you may have been looking at problems from a wrong angle or you might even find ya self in a situation where the developer could have done something differently. Sometimes you'll get replies like "Maybe it could have been done like that", in many cases it'll mean that you were right but they're too proud to admit it, you'll have to read between the lines.
The developers are busy, but using email or some kind of a messenger (some companies use Lync is probably the most efficient way to get answers from the developers without disturbing them. If the developers can't even bother to reply to your emails then you can at least do a research on the internet to find in which cases method X or method Y makes more sense to be used.
Give it some time
Five weeks it not a long time at all, most new developers require a year to become semi-comfortable around a system they didn't write. The company probably wants you to become comfortable with the structure of the system before you start implementing something that could be too big for you. If you show decent understanding on the structure of the system then you might get a chance to do some coding.
If nothing changes soon, and you'll be feeling like you have enough knowledge of how the system works, then you should schedule a meeting with your boss (he can probably schedule a week or two ahead) and discuss the matter with him, ask him for a small project or a sub-project so you can prove what you can do.
Write unit tests
One of the best ways to understand how a system works is to test all the public classes and functions available in the system, that way you get a perfect overview of what the system is suppose to do and you'll even have some code to show to your boss and the developers, you'll bring something useful to them as well.
Don't count on the workplace entirely for experience
Being new in IT is rough, getting into software-development with no experience is very rough. Many people (including me) develop small projects at home to gain experience and understanding of how to create full working systems that you can even show and discuss in interviews, even during the time they're still learning CS. You should do this, develop some projects at home, ideally for the web (they are easier to show-off and easier to share) but not necessarily. You'll run into furious errors and problems that you'll be glad to run into at home, instead of at your future workplace, and you'll be able to use that experience as an advantage in your interviews.
Capture your current environment and learn what's right and what's wrong
Having experience of good workplaces and bad workplaces is good, it's important to bring it up in interviews and compare that to the working-environment that you're applying for. If you can say something like
I didn't like working at company A because ...
then the interviewers will see that you have an idea of what you want and you're less likely to be leaving the company. Just make sure to be not too harsh about your old company.