I was with a number of musicians this evening; they were preparing for a rehearsal by playing around on their instruments. It’s a common occurrence in creative endeavors; they weren’t practicing scales, or harmony, or even trying very hard to make a tune. They were simply doodling around, getting ready to play.
In sports, I think this would be the equivalent of “loosening up” before a game or a practice session. People are recalling the muscle memory and the mental preparation necessary for engaging in a highly-skilled activity.
This happens with computer programmers, too. Programmers, especially when they’re learning a new language, tool, or system, tend to “play around” and write code to help them figure out how it all works. It’s a form of loosening their mental muscles before diving into the task at hand. And, more specifically, it helps them to identify “best practices” for the particular situation. For example, playing around with a database can teach a developer about the best ways to model data structures in code that can handle the data efficiently. Playing around with a RESTful API can help them to better understand the different mechanisms for executing and controlling HTTP sessions.
The best and most senior developers spend quite a bit of time just playing around because they understand that this is a crucial part of the creative process. To use something, you must be able to understand it, and playing around it is the best way to do that.
Junior developers tend to want to dive straight into the code; I think they feel that it’s a sign of professionalism to be able to start and complete programming tasks in a timely manner. At least, I felt that way, too, when I was a younger programmer. However, the sheer usefulness of playing around with things almost always trumps the ability to dive in and write some code.
The fact remains that programming is a creative endeavor, and not necessarily a highly structured one. For any given problem, there are almost always multiple potential solutions, and playing around with them can teach the programmer a lot about the various pros and cons of them.
Of course, playing around can be taken to the extreme, where it actually passes the point of usefulness and turns into a pointless exercise in coding (sort of like how one link leads to another on Wikipedia, with everything ending up on “Philosophy” eventually). However, the actual constraints of the job (the necessity to deliver something by an agreed-upon date) will usually pull the developer back to reality.
As a manager, you need to direct your programmers; they should be encouraged to play around with things, but they may also need to be mentored as to how to analyze what they’re doing and thus gain useful knowledge. Senior developers and architects, especially, need to be encouraged to play around with things; this will greatly improve their knowledge of the system or technology.
And, in some cases, that “playing around” can turn into something truly wonderful.