I would say 'code ownership' would be a perk. If you give them something (even small) and make them the go-to person for that corner of your codebase it will give them confidence and help them feel like they are a part of it.

I often hop into existing codebases, and sometimes I'm the only active dev on my part of the project, but many times I don't feel free to make changes, like I don't 'own' it.

That would be something really easy you could do that might help them feel important and needed, and it's pretty cheap (if they make a mistake it takes a bit of dev time to clean up, otherwise it's free).

An old employer of mine had two lesser-known perks that had surprisingly positive results:

• Meetup sponsoring - If any employee wanted to host a meetup on a topic and use the office space for it, they were allowed to do so as long as they asked for permission + gave prior notice. The company would then sponsor equipment for presentation as well as snacks and seating arrangements for the guests. The ethos here is that learning is done best while teaching, so they would encourage junior devs to take on a mentorship role.
• Conference attendance - To promote technology enthusiasm and learning, if 5 or more employees submitted a request for tickets to a tech conference, the request would be approved, then travel & ticket (but not accommodation) expenses would be covered by the company provided that there were no looming deadlines around the time of the conference for any projects those developers were assigned to.

My previous employer Carrot Creative also has some interesting perks you can look at - one of which is a "Carrotversary" - the yearly anniversary of an employee's first day - celebrated in the office much like a birthday.

Hmmm well what are the perks of the youth ?

Blank sleight

The developer probably did not work in to many other companies so his mind is still open about a lot of things.

Spirit

If he/she is young, she's probably very motivated to get things done and you can use that energy to change and introduce new things or question old thing.

Reflection

Since she/he could be spirited and have no clue he/she probably will ask a lot of questions. The guys who hired my girlfriend as junior, hated and loved her for that. She asked them everything about their code while pair programming .... everything Gg.

Productions slows down a little, but the integrity and the knowledge increases. The trick is to keep the balance. For example you should iterate every two day or such. Since it's about learning from the whole team.

Maybe you could even Mob-Program if you like :)

New Knowlege

there is this "famous" quote:

if you aren’t a liberal when you’re young, you have no heart, but if you aren’t a middle-aged conservative, you have no head.

Which applies to our job as well as a young dev we don't mind breaking changes "we have to rebuild" -> @sandeep did post a lovely article about the balance of engineers which represents the different views. younger ones have less mistakes in their history so the tend to be less scared of change / failure which often starts with the words "you just have to..." a quote which send a shiver down a lot of seniors spines. We know that the devil is in the detail.

Still it helps us to reassess old decisions and maybe break our old habits. I tend to let them fix "mistakes"/"broken windows" so they can improve things without breaking major parts of the application.

And don't forget we did not learn all the things they did, I learned C in highschool now they learn java. Such things tend to bring some new perspectives.

These are the first things that came to mind. I hope you can take away something useful from it.

Edit: ;D i misread i was going for "of" not "for" .... anyhow ... i will leave the comment out of historical reasons ..... :)