Learn to refactor code well

Refactoring old code should be standard practice in an organization. Although it may take some time away from current projects, it's not something that should be skipped over. Code that was written years ago should be audited and refactored every now and then. If it's code that is frequently used, I personally like to look at it quarterly. Not every code audit will result in refactoring.

Ideally, when you write code you should think about the future of that code. High code reusability and avoiding temporary band-aid solutions should come to mind. In reality, there are many different engineers in different levels that operate in any given team on an organization. These engineers come and go and the method they may use to structure their code can be outdated over-time or wasn't written in the best manner. Your code should be easy to maintain, straightforward, and clean. When working in a codebase, think about who else will need to make sense of it when you're gone.

Another important element of refactoring is considering when to move tech stacks. It's not always easier to refactor from an old language (like COBOL), into something new. Sometimes, it's not even ideal considering your architecture, dev availability for the switch, maintenance required, how many devs in your org know the new stack well enough, and especially perceived down time.
If you're considering a move to a new language, start smaller and do adequate benchmark testing.

Recently I thought about refactoring parts of our codebase from Python to Golang to circumvent the time wasted running certain api functions through Python. Since python is an interpreted language, it moves through elements very slowly. It can take hours to archive data if you have to cell by cell in a database or grid style data entry. Since Golang is compiled, it is typically much faster than Python.

It's still on the table for me to do benchmarking of some services we provide to judge the comparisons, but a large factor that would hold me back from making a large refactoring initiative is the lack of experience other devs on the team have with Golang. Ideally, we should be able to pick up new languages fairly easy. Especially going from back-end to back-end. However, people are busy! We don't really have the time to do that on the job unless there is a serious need for it.

Usually this imbalance of time allotted to up-skill and refactor is what leads to tech debt.