A database specialist and blogger I follow came across this post:
http://stackoverflow.com/questions/888224/what-is-your-longest-held-programming-assumption-that-turned-out-to-be-incorrect
which got me wondering, what assumptions have I made that turned out to be incorrect? The one that came to mind for me was the idea that going to the database is slower than pulling in all the data you need at once and querying the stored data when necessary. It really depends on your situation. When you don't have to deal with remoting or firewalls, it is very often faster to query the database than to use a stored list.
More importantly, though, this question should make everyone ask themselves: what assumptions do I make today that are based on incomplete, out-dated, or inaccurate information? A post like this one is good in that it helps everyone to see what assumptions had been proved false and allows all the posters and readers to learn from others' mistakes. However, the goal should be to question our current assumptions, not just take pride in previous lessons learned. Looking back is certainly a valuable exercise, but looking for new lessons to be learned is more important.
Sunday, July 25, 2010
Sunday, July 11, 2010
What band instrument repair taught me about I.T.
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".
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".
Subscribe to:
Posts (Atom)