Julian Haeger

Play is accepted as having an important role in the development of problem-solving skills and resilience in children.

Play provides children with opportunities to explore simplified, low-stakes versions of real-world situations, helping them build skills that transfer to more complex and consequential challenges later in life. As a report into the importance of play by Dr. David Whitebread at the University of Cambridge summarises a work by Anthony Pellegrini:

in animals and humans, play (as opposed to ‘work’) contexts free individuals to focus on ‘means’ rather than ‘ends’. Unfettered from the instrumental constraints of the work context, where you have to get something done, in play the individual can try out new behaviours, exaggerate, modify, abbreviate or change the sequence of behaviours, endlessly repeat slight variations of behaviours, and so on. It is this characteristic of play, it is argued, that gives it a vital role in the development of problem-solving skills in primates, and the whole gamut of higher-order cognitive and social-emotional skills developed by humans

We tend to associate play with children, but as we know, there isn't some hard cut-off when the brain can no longer learn. The opportunities afforded by low-stakes experimentation, "unfettered from the instrumental constraints of work" remain open to us as adults.

As a developer, I've benefitted immeasurably from working on projects with a concrete goal and user(s) in mind, myself or others. I'd encourage anyone to pursue such projects when trying to learn a new technology. But I'd also advocate for the opposite: experimentation for its own sake, where the focus is the "means, rather than the ends". For building toys which nobody should use in production. For coding sandcastles washed away by the next tide.

When a usable system isn't the goal there's less pressure to "finish". If learning is the goal then you don't need to "finish" to achieve it, it's lying about in little nuggets at every decision.

If you can appease the compiler with a small change you don't fully understand - there's your next goal: understand that.

If there are multiple ways to solve a problem and you can't decide which way to go, try several ways, maybe all the ways you can think of. This is especially useful when one approach is widely acknowledged as the "wrong" way to do it. Try to provoke the shortcomings which others have warned about. You may discover you never really understood them, or there's more nuance than reported.

If you often rely on some category of library, service, or tool to provide a foundation for your production projects - build a toy one. It's very unlikely to be as good as the database, web framework, or source control that you use when results matter, but you'll understand those so much better having built your own out of coding cardboard.

Of course, one of the defining features of play, is that it's fun! Fun is fulfilling in itself, but it's also something that draws you in, and keeps you playing; keeps you learning. Personally, I find myself alternating during my pre-work personal development time. Sometimes I'm motivated to build something with a goal in mind. I'm enthused by the scope of project, by the anticipation of the working system. Other times I find myself flagging, less motivated to set the alarm early and spend more time at the keyboard. When this starts to happen, I find it's time to break out the toys. To put the project on a back burner and jump in the sand.