Hi!
This morning I was reading through this post:
and I got curious about other people’s experience and challenges with monster-sized Ruby code bases… (as I myself don’t have such experience)
Share any pains/gains/insights, tools you discovered that made your task more pleasant, or anything you feel worth sharing! 
I haven’t worked on “monster-sized” ruby code bases but from my experience on some mid-size large projects, I tend to agree that standardization and great tooling can make a great difference.
The project seems similar to Standard Ruby, would be interesting to learn if there was a good reason to implement from scratch or it’s a “Not Invented Here” project.
Consistency is probably the engineering value our team points to the most often. When the code is consistent across a codebase, it makes it much easier for someone to jump in anywhere and help out. We use lots of linters, including a growing number that we have written ourselves. When it comes to introducing a new architectural pattern, we emphasize having a plan for propagating it across the codebase, rather than just changing patterns going forward.
Testing is also critical. 100% coverage minimum, both branch and line, and lots of end-to-end tests as well. It’s a long haul getting there, but very worth it. Test flake, though, can tank engineering productivity and motivation, so we also address flake very proactively.
I second the above. It’s always a cultural, not technical, problem.
This means Code Quality must be top notch and fully automated. This includes near 100% code coverage as well.
I also take a very pro-active approach to everything by constantly staying on top of dependency updates and tackling them as fast as possible in order to reduce potential tech debt. If you let this slip, it’ll come back to bite you in a very costly way where it’s not days but weeks or months. Having worked on large teams, and consulted as well, this is always the main culprit for retaining or hiring talent.