Christopher Phiri’s presentation makes a distinction that’s easy to lose: recreational programming isn’t a side hustle, interview preparation, or another obligation to improve yourself. It’s programming because the activity itself is interesting. Learning and useful tools can follow, but neither has to justify the time.
The practical advice is to give experiments different rules from production work:
- Keep a low-friction playground, without mandatory CI/CD or elaborate setup.
- Build toy versions of systems you want to understand, or solve a tiny personal annoyance.
- Try the same idea in different languages to explore how they shape your thinking.
- Treat abandoned repositories as exploration, not a backlog of broken promises.
- If you share the work, explain decisions and dead ends rather than just presenting a finished artifact.
The strongest line is “Boredom is data, not defeat.” In a recreational project, losing interest can be a reason to change direction rather than a discipline problem to fix.
That permission belongs to the playground, not to systems other people depend on. The useful boundary is keeping some programming free of shipping pressure—not pretending reliability and maintenance don’t matter at work.