What band instrument repair taught me about software development

Most people are understandably surprised when they learn that my first job out of college was repairing band instruments (flutes, clarinets, etc.) On the surface, there aren't a lot of similarities between the two careers. However, I'm a better technologist because I learned how to repair flutes. Here are some things that I learned repairing instruments that are directly applicable to software development.

Many different approaches can accomplish a task

In order to seat a pad in a woodwind instrument, one can take many different approaches. You could "float" a pad in place with hot glue or liquid shellac, glue the pad in place and clamp the pad down so it will take the necessary shape (called impressions), use cork pads and sand the cork to the necessary shape, etc. Each method has its strengths and weaknesses. For example, padding with no impressions results in a longer-lasting repair, but takes longer to prepare the instrument beforehand. The same concept holds true in programming. No single programming language/operating system/software package can do everything you need every time perfectly. For example, Content Management System (CMS) packages are great for starting general websites, but you're usually limited by your functionality and have a higher training curve vs. custom-built sites.

To a hammer, everything looks like a nail

Similar to the previous thought, one shouldn't stick to the tools we know just because they're the ones we know. When I was still repairing full-time, I owned around a dozen different types of hammers. A dozen! And not only did I use them all, but I also needed two more to work on tubas. Too often in technology we choose our toolset based on familiarity rather than its fitness for a particular problem. When repairing a musical instrument, such an approach could do damage to the instrument. In software, this can lead to a buggy system that is hard to use and maintain. 

Perfection is impossible

If I were to try to get a flute to respond as quickly as possible, I would make the pads and tone holes as flat as possible (usually within .0005 inches), use the thinnest possible padding between metal contact points, remove all the play in all of the mechanisms, and so on. However, doing so results in a flute whose mechanisms are noisy and more susceptible to adjustment problems. Finding the right balance between durability, quietness, and response is difficult and should depend on the individual needs of the customer. The same holds true in software development. An application built for performance is often harder to change, an application that is built for security is hard to use, where an application built for ease-of-use might take longer to load, and so on. People in technology should be more honest with ourselves and our customers about what the trade-offs are so we are making the right decisions for the project.

Talent is less important than most people think

I've seen many times that success comes to people who work hard, always strive to do better, and to recognize potential areas for improvement even in projects that seem like a complete success. The people who continually improve almost always succeed, regardless of innate skill.