Ryan Carmelo Briones

mostly harmless

Musicians and Programmers December 07, 2010

A few weeks ago I wrote a blog article called “Practicing for Life” where I talked about some of the things I learned in George Leonard’s “Mastery: The Keys to Success and Long-Term Fulfillment” including some insights on parallels between practicing software development and practice a musical instrument.

In the end, I challenged readers to channel their musician experience and talk about what practices specifically we could use as metaphors for practicing in software development. In return I offered 4 copies of “Mastery” to the best answers. I got a few answers, not as many as I hoped, but some good ones at that, including a very thoughtful blog post by a new Obtivian Dan Melnick.

“As piano student, practiced sight-reading (perform w/ new music). Solve unfamiliar SW problems quickly, cleverly, creatively.” – @Geniasaurus [original tweet]

“I frequently refer to programming fundamentals as the “scales and arpeggios” of software development. I think you’re right on… Algos, data structures, looping constructs, the stuff you should be able to write without thinking.” – @polgfred [original tweet 1 original tweet 2]

“Music and Software Development http://bit.ly/cV3L77 is my reply to @ryanbriones blog post Practicing for Life http://bit.ly/aqhlVH” – @dan_melnick [original tweet]

Fellow Obtivian Fred Polgardy echos my comments about scales and adds a little specificity for the practicing software developer. I’ve actually been spending a little time in this area myself reading “Mastering Algorithms with C” to buff up my computer science fundamentals.

Eugenia brings up sight-reading as a way to expand the mind of the software practitioner. While not direct parallels, I think there’s a few ways to accomplish this. First, program in a “foreign” language. Try to code up something in a language you’ve never coded in before, particularly one that forces you to think in a different way. Some good ones include Haskell, Io and Erlang. If you’re doing Java, C# doesn’t really count. In combination with a new language, try solving some of the problems in Project Euler. There are some good ones there that bend your mind just enough when trying out a new language yet still have practical, provable answers to check yourself against.

Last Dan brings up a few really good points. First “Listening” or developing an ear for software development by pair programming and reading other’s source code. After a similar suggestion by Ethan Gunderson, I started to do this by finding and following developers (particularly ones who’s code I appreciate) on github, and then made github.com my homepage. That way, when my browser starts up, I get up to the minute info on the open source code my peers have been working on and have the ability to dig deeper right away. Again, in “Structure and Improvisation”, Dan echos the need to learn the fundamentals but takes it further and discusses how the “structure” leads to the ability to improvise. Real world software development happens at the crossroads of structure and improvisation. Finally he brings up the importance of identifying “Patterns” and test-driven development to aid in the process of composition.

Overall, some really great stuff to incorporate into your practice of software development. As promised, I will be offering all 3 of these a copy of George Leonard’s “Mastery”. They definitely deserve it.

Be sure to check back in the future. Right now I’m reading Josh Waitzkin’s “The Art of Learning”, a complement to “Mastery” suggested by Kevin Taylor. There will definitely be further posts in the future on the subject of practicing, learning and teaching as a result of this reading.

Cheers!