When people find out that I was a band instrument repair person and became a computer programmer, most people seem surprised. They don't see a connection between the two. However, I've found that there are a lot of similarities in the mind-set that makes a successful programmer vs. one that makes a successful band instrument repair person. Here are some things that I learned repairing instruments that are directly applicable to I.T.
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, use flexible pads and manually shape the pads to the tone hole, and so forth. Each method has its strengths and weaknesses. Many players (especially saxophonists) prefer the feel of pads glued in with shellac, but it gets brittle in cold weather. Padding with no impressions results in a longer-lasting repair, but takes longer to prepare the instrument beforehand. The same concept holds true in I.T. No single programming language/operating system/software package can do everything you need every time perfectly. PHP might be good for getting a web site up quickly, but Java or .NET might be more appropriate for a large-scale web site. It is important to know and explore the alternatives to come up with the best solution.
To a hammer, everything looks like a nail
Continuing the previous thought, some people will stick to a particular methodology because it is the "best" for whatever reason. Just like some repair professionals will claim that stick shellac is a superior choice of glue over other hot melt glues, some I.T. professionals will stick by a database, operating system, programming language, etc., for similar reasons. While choosing a methodology for its convenience can usually get the job done, the best products I've seen are the result of knowing the alternatives and choosing the best methodology based on its merits, not based on convenience. The idea that one becomes an "expert" in one area by refusing to learn other areas usually leads to more limitations than expertise.
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, where an application built for ease-of-use might take longer to load. Sure, there are cases when changing some code can result in an application that's easier to maintain and faster to load, but at some point your goals in writing software become conflicting.
Talent is less important than most people think
Finally, I've met countless people in the music industry who became good at what they do not through talent, but through hard work. Success comes to people who work hard, always strive to do better, and to recognize potential areas for improvement in what otherwise seems like a success. People who do those things almost always succeed in the end, no matter how they might define "success".
No comments:
Post a Comment