Ask HN: New to a system with maintenance in mind and no sparse docs

[perlpimp]

I have been hired a year ago to work for a company to maintain and update system that we do not have very good documentation for nor do I have insightful knowledge of the tools that are used to maintain and so on.

Wonder if there is a good rule of thumb to keep working on the system if there is a lot of time between support requests. Like writing additional tests, interference testing to find patterns of failure and so on to move to deeper understand it.

[NAHWheatCracker]

I find that the best way for me to learn a system is to just clean it up. Making non-functional changes like formatting the code and adding documentation. Maybe refactoring if I see something that could obviously be cleaned up like duplicate code.

Testing is also good, if it's testable. Based on your description, I'm guessing it isn't very testable. Testing and refactoring together is a good cycle.

Setting up a repeatable environment is huge help. Build/test should run on every commit in CI. Dockerize it if it isn't already. Have as many official environments as you see fit. At least a dev that is kept up-to-date and production, of course.