One of the main reasons I keep side projects going is that they give me a safe place to experiment.

When you're working on something business-critical, the primary objective isn't learning. The objective is delivering value for the business and helping the organization succeed at its shared mission. Of course you will learn while doing that work, but learning in that context should mostly be a side effect of delivering, not the main goal. If the team's success depends on the system working reliably, introducing unfamiliar tools or techniques purely for the sake of exploration can create unnecessary risk.

Side projects create a space where that exploration can happen safely. They are a place to try new frameworks, testing approaches, deployment strategies, workflows, or architectural ideas without the pressure of production systems or adverse business impact. If something works well, it becomes a technique you understand deeply and can confidently apply later. If it doesn't work, you still learned something valuable, but the only thing at risk was your own time.

This isn't to say you shouldn't try new things in professional projects. Innovation is important and teams need to evolve. But it helps to be deliberate about how that experimentation happens. Ideally it is done in ways that keep the blast radius small by introducing changes incrementally, scoping them carefully, and making sure they can be rolled back easily if they don't work out. That way you can still move forward and explore better approaches without putting the organization's mission at risk.

Over time I have found that experimenting freely in personal projects and then bringing the proven ideas into professional environments is one of the most effective ways to reduce risk while still continuing to grow as an engineer.