Maybe 3, then I switched gears and started investing in fire prevention strategies (hell, fire detection & prevention systems were my first real job).
Cleaner code, proper testing, reproducible and reliable build processes, actually studying and applying CS concepts [0]. I've since come to the conclusion that any place suffering from repeated "fires" is a place that ought to burn down. It's a sign of misprioritization and it will either lead to the early deaths of their employees from the extreme stress or the early death of the company/org from incompetence. Hopefully the latter more than the former.
[0] Concurrency issues. How many places have a policy of just "clear the queue, the data will be resubmitted if it's needed" when the real problem is that they have more data to be processed than systems to process it. Wait, that's not actually the real problem, it's a poorly designed system that's barely taking advantage of the available hardware. I had a system I (thankfully escaped) was partially responsible for that involved millions of dollars in hardware for...200 concurrent users. It couldn't go past that. They'd created so many bottlenecks in their design and dedicated hardware entirely to certain tasks (that used maybe 1% of the hardware's capability) that scaling beyond that was literally impossible. The hardware was more than capable of handling more users (I'd seen less hardware handle more users for more complex tasks in the past), but a lack of comprehension in the design of the system led to this incredible failure. More money was being thrown at it year after year to try and scale it but they were still hitting these fundamental walls created by the design which they wouldn't address or even entertain addressing.