We were in a similar situation some years ago: We got a piece of legacy software that generated revenue, had incredibly poor code quality (On Error Resume Next littered all over the codebase), and none of the original developers were available for questions.
There's some sentiment among team members that our team is doomed in a hopeless scenario. We hardly have the expertise that when we take over on call, whoever's on shift feels comfortable handling whatever could happen.
The good news: It's not hopeless. The bad news: It will take a lot of time before you "feel comfortable" handling support requests for it.
Some of the lessons we learned:
- The short-term revenue created by software is mostly independent of the quality of the software. Spaghetti code solving your customers' problems will generate revenue, beautifully-written code that doesn't, won't.
- Obviously, bad code quality makes maintenance a nightmare. It decreases software developer satisfaction, and every small thing (support cases, feature changes, etc.) takes much, much longer than expected. This will get better over time, as you get more familiar with the product. If possible, try to keep fluctuation in your team to a minimum, so that the painfully aquired know-how isn't lost.
- Do not---I repeat: DO NOT---make the mistake of trying to rewrite everything from scratch.
Whole books have been written on how to deal with legacy code: Isolate components, write unit tests, etc. I won't repeat that here.
- What can I do in the immediate future (as an individual contributor) to benefit myself and the team?
Adjust your expectations.
- Answering a short, simple support question might require a few hours of digging into the code and doing tests. That's OK, and the time is not wasted, because now you are more familiar with the code than before.
- Changes to the code (bugfixes, new features) will take a lot more time than you would expect. In particular, the time it takes will be more unpredictable: A small change might take 5 minutes or 5 days, and you won't be able to tell in advance which one it will be. Make sure the higher-ups understand that.
- Make sure that the office climate is good. Support each other. Working with legacy code is often not fun, so make sure that there are lots of other opportunities for your colleagues to enjoy work. For example, set time aside to rewrite some small(!), particular annoying part of the old application.
- How can I best frame this work experience? We can barely comprehend the product, algorithms and design choices, etc. and I worry this will hurt my career, being unable to speak deeply on these topics and my work experience besides putting out metaphorical fires and archaelogical work.
Everyone enjoys writing new software from scratch using the newest gadgets and tools. However, what companies often really need are people able to maintain that decades-old legacy application that brings in all the revenue. So knowing how to "put out metaphorical fires and do archaeological work" (and being willing to do that!) are actually skills many companies are looking for.