Personally I think it’s irresponsible to hire new employees before having a maintainable project. It’s much easier to onboard employees and delegate to them when they have a safe dev environment and testable projects to break while they learn.
- hiring people for unmaintainable projects is literally the default for the majority of companies as everyone starts out small without directions and either fails or becomes something big. Legacy code is basically everywhere, clean code is the minority.
Gradually that test suite will accumulate enough stuff that all OP has to do is walk into work, pull the latest, and make a few easy fixes before they finish coffee. They will look like either a hero or a monster, depending on how the politics work out. It's risky, but either way something will have been stirred up.
Have you ever been in a situation where you think "Gee, this is a mess but we are swamped here! Let's hire more people to help fix this" and then the new hire(s) joins the team and proceeds to bad mouth everything instead of helping to make things better? I have and it wasn't lack of communication or openness.
It's an attitude I can't empathize with.
Considering that you will face this probably with your next employer again, deep breath and just enjoy the actual engineering work!
- just make the function / class you're working on nicer, preferably just a small function. Apply some common quality standards to it, clean code, nice docs. - repeat this for a while, and you will have a nice set of examples and guidance for the other team members by setting an example.
Personally I am a huge fan of making that one place where you found the bug nice, adding a simple test case and moving on to the next thing. It adds up over time and does not hurt in terms of time involvement/budget since you already had to invest a larger amount fo time to find the place bugging out.