Thanks for the replys.
So week in and I'm going through phases of thinking I am getting it then feeling like I am back at square one.
From speaking to a few the system has grown massively over the past few years. There is no real standards no documentation and code comments are very sparse.
I do have a local dev environment and database with dummy data in so I develop safely. However there is no tests other then user testing and to be honest I think even trying to impliment tests at this stage of the code would be lots more work then it would save.
There is massive functions with if statements in which I would have broke out into separate functions but its all like that so I will just have to suck it up and get used to it.
I have done a few error fixes and small additions which has helped. I think a big part of my problem what trying to understand it all to start with rather then just easing in.
Think also as I dont really understand the business workflow its making things more dificult
The situation you're in is not unfamiliar to me. I'll skip some of the programming stuff and make a few more general job comments:
1. Asking questions makes you seem smart and eager, not an idiot. Get as much context as you possibly can for the project. Especially business logic. You don't want to second-guess how things are supposed to work from someone's idea of it (the code), you want to get it right from the people who know.
2. Don't be afraid to take the pen and paper approach. It's actually a good way of abstracting at a high level that we learn to use as children. When it helps, use it.
3. When you have a good handle on the business logic behind everything, don't be afraid to have a go at refactoring things. Sometimes it's possible to dual-track development so that as well as putting in the latest urgent fix, you're working on a better solution long-term as well.
4. Identify some sort of metrics by which you can demonstrate your progress and your value. Good version control is vital for this. Use code quality tools, line counts, number of functions with comments, whatever so that you can show improvements. Nobody will care right now, but six months down the line it will help you show the value of re-writing the codebase.
5. Double-check everything and work up a really solid testing methodology. People hate it and it takes time but trust me on this - half a year from now being able to show no bugs in your code is way more valuable than having overrun a few times or told them "no, it'll be tomorrow". You don't want to enter death-spiral where you're so busy working on the bugs or misunderstandings from your last piece of work that the new piece of work starts to suffer.
6. Ask for protected time, maybe a morning a week, set aside for re-factoring and improving the code base. Tell them it will reduce bugs, improve on-boarding of new developers and probably improve performance. Alternately, ask them for the same but so that you can build out test processes. These could be unit tests using something like Codeception, or from the sounds of the project, you might be better off with front-end testing with something like Selenium. That can demonstrate an immediate value to the stakeholders and get you a good chance of buy-in.
Just some general suggestions for when you're thrown into the deep-end on a large, unstructured project. I particularly recommend the front-end testing which can be automated. There's huge value in that if they don't already have formal testing as part of their release process.
.
