How to leverage and frame software developer work experience in taking over a challenging startup acquisition?

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.

1. 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.

2. 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.

The workplace problem

The management already made their decision. Which leaves you with a simple choice: take it or leave it.

The technical problem

You have to maintain or rewrite a software that you do not understand. You already study the code and it is hopeless.

Then change the approach: find (i.e., create) the requirements of the software. Or better requirements. Start with the main stakeholders for you: the management. What do they actually want? The exact same behavior? Or just a similar enough behavior? What improvements do they expect compared to what is already implemented?

Once you do that, you might find out that you can completely rewrite the software, and even make it better.

You can also infer requirements through usage and testing. "If I do this, I get that". Write that down, they will be very useful in the future.

Regarding the code, change it step by step. Start with what you understand, and gradually move towards the things that you do not understand so well. You might be able to find tools to reverse engineer the software for you, and present you with valuable information: classes, methods, data structures, call graphs, caller graphs...

Static analysis tools might come in handy to spot bugs or code structures that can be beautified and simplified.

But the most important, start with the requirements.