9 Things I learned in 2009 (Part 1)
Chris Shaw
As we start to move forward in 2010, it is easy to look at the issues that we face every day and the tasks that need to be completed. As we look into the rest of the year, it would be prudent to look back at 2009 and see if we can document some of the things that we have learned, almost consider it a 2009 post mortem. For me, the year appeared to fly by without hesitation and there were many new projects and tasks on my list, however when I review what I learned I believe I only covered about 10% of my list in this article.
Think out of the box – There are a number of times that the academic solution will not work for one reason or another for a problem that you might be facing. You are then left in a situation where you are forced to try to cobble together something for a solution. When you are faced with an issue, make sure you look at the issue from all sides, not just from the angle of what is the best way to do this or what is the best design. Sometimes a best practice just isn’t a best practice for your environment.
Example: I contracted with a small company that used a SQL Server database to keep track of their clients and what discussion they had with the client or potential clients. When they started to look into disaster recovery plans with me, we found out they did not even have a good backup. A consulting company was asking them to consider a solution that included a hot fail over to another city. The solution would work but was very expensive for a small client. The database was small enough where it could be moved over the internet easily and the data could be off line for 24 to 48 hours. With those requirements the client could get back up and running on a SQL Server at another host as long as they had the backup file. The end cost to the client? Just the amount of space they were using to store the backups of their small database.
Never Stop Learning Something New – There is always a new feature that is coming out with SQL Server. In the past few years we have seen a number of releases of SQL Server and if you are not on the edge of cutting technology you may not be using every feature in every edition. Don’t let your skills go to the way side just because you are not using a feature.
Example: This summer I spent some time interviewing for a contract position. During this process people wanted to know what features I had used and what features I had not used with SQL Server 2005. One company in particular was relying heavily on the XML features in 2005. When I interviewed with them I was honest and let them know I have not seen much use of the xQuery features. I ended up being offered the contract but for less money than I had hoped. If I could have answered the xQuery questions, I think I would have been fine.
Keep your Code – Have you worked on something that you were really proud of? You may want to consider making that code public if you can alter it to remove business specific information. If nothing else, it will help you to not re-invent the wheel next time you try to implement a solution.
Example: A friend of mine was talking about how he was working on code that did a lot of manipulation of table partitions. His code grew the partition, managed the indexes, rolled partitions in and out and managed the indexes. He had written the code for a company however, he had a discussion with the company and removed all references to the company in a copy of the code and retained it. Now if he has to go somewhere and work on table partitions, he has code that he has already worked on even if it is for example purposes only.
There is Nothing Like a Good Monitoring Tool – There are a number of monitoring tools out there for people to use. I have one that I prefer and I like it because of the functionality and the ease of use. Some tools just don’t do what I want them to do or I end up spending all my time looking to find the items that I want.
Example: I was testing a tool over the summer that claimed it was a performance monitoring tool. I spent a number of hours researching and trying to figure out how to get the tool to look at the data just the way that I wanted to see it. After a few days of working on it and speaking with the company that made the tool, I determined that if it was that hard, I did not want to use the tool. I am sure that other people are going to look at that product and it will be second nature to them.
Next week we will review the second half of my list. I would be interested to see what is on your list. If you have time, drop me an email to let me know what you think is the coolest thing that you learned in 2009. Please make sure that you rate this article and if there is a subject that you would like to see in the future, please let me know.
