I'm on a team that owns most of the core libraries for one of my company's platforms
This sounds like "our team getting things right is really important."
These things could be caught in code reviews, but our team isn't big enough to keep up with all the changes, and there is a time difference between some of the teams that makes that problematic anyway
Ah, the problem isn't so much you don't know a really great solution but do not have time for it.
Code reviews have as their entire purpose to address issues like this. Good code reviews with a team willing to learn results in higher quality code over the long term as well as better education.
Depending on your role and team, I would consider adopting some sort of unofficial policy regarding code reviews:
- Every piece of code requires a senior +1 before being merged
- All pieces of code require +1 from two team members
- No one can check code in without having it looked over by another person
The reality is you ARE going to deal with problems that get merged. The question is whether you will deal with them prior to being merged (through a review) or after they are merged and become technical debt.
Another way to address this is to have a better transition process. You made it sound like a new hire goes through several months of heavy pair programming/review and then is set free to do things themselves. A few things here which will help:
- Make 100% sure the new people are the ones typing the code. They should have their IDE up, they should be typing, and the senior should be guiding them -- not a situation where the junior just watches the senior type
- This is going to feel miserably slow for anyone who is used to the senior typing and junior watching
- The junior watching the senior type is pretty useless from a teaching perspective, because they aren't doing. Most people learn from doing, not watching
- Have a gradual transition plan away from the heavy mentoring. Don't just let them go 100% loose until you have confidence they can achieve.
If resources are the problem, talk with your manager. Explain it just as you have said it here. Saying that your team does not have the resources it needs to effectively guarantee quality code is written. Explain what the outcome of this would be in your situation. Ask what your team can do to get more resources. Your manager should care about this situation at least somewhat.
And last, consider making part of your interview process include asking about functional programming. It's better to hire 1 person who can work efficiently and independently than several you have to babysit.