When a new developer joins the team we always give them a quick tour of the codebase.

Here’s what’s standard Rails. Here’s what we’ve added to make a 6 year old codebase easier to manage. Here’s how you can find what you’re looking for. Here’s the code you should take as exemplary and here’s some code that you shouldn’t.

One thing I’m always on the lookout for is if that codebase tour every gets painful to give - have we made something overly complicated, or overly clever? Is finding something hard because it’s all meta-programming and so searching for keywords doesn’t work? Do we use different words in the codebase than they would see in the app for the same concepts?

Hopefully you’ve already got your codebase in a fairly welcoming state, because a lot of the same things make it easier to extend and work on for more experienced developers too. But if you’ve got some dark corners (haunted forests) you might want to put the time in to sort them out.

Similarly, a codebase is much more welcoming if making changes to it is low risk. The best way I know to feel that way is with automated testing and continuous integration - your junior developers should feel safe and secure in the knowledge that any bugs they introduce will be caught long before they reach your users.

Writing documentation can also help demystify your codebase. I like to write documentation at a high level so that it doesn’t get out of date too quickly, and then link to specific parts of the code that I think are good entry points for going deeper.