Growing up I loved to solve puzzles. Not just formal puzzles but anything that required figuring out how to make parts work together to solve a problem. The childhood puzzles are mostly gone now having been replaced by puzzles of greatly increased complexity. As an adult these puzzles might include optimizing a SQL query, properly normalizing a schema, streamlining a data process, or troubleshooting an ill performing server. But the puzzle could just as easily be some larger, grander business need requiring the incorporation of these smaller puzzles as mere pieces of the solution. Being a good solution provider means understanding the pieces and how they can work in concert to solve small and large business needs.

I started learning about these pieces early in my career as a desktop technician, roaming the halls of a large corporate campus, troubleshooting hardware problems. It wasn’t until later that I understood the good fortune to be in a position which focused on hardware. Knowing the hallmarks and sometimes subtle symptoms of a hardware problem has been an important piece of many puzzles that I have worked to solve.

My career with SQL Server began in 1998 when I was hired as a consultant to build client/server applications in a rudimentary fourth generation development environment. This environment abstracted much of the schema and code creation that typically requires hand-coding. An area that wasn’t abstracted though was schema design. While the environment could generate the code to create the schema it couldn’t make the necessary decisions about the design. It was here I learned the criticality of a well-designed schema for maintaining data purity. I also discovered I had a knack for normalization.

After the dot com bust I landed in IT as a system administrator where I spent several years in a role that combined Windows domain administration, network administration, and desktop support. SQL Server databases don’t exist in a vacuum. The knowledge I gained in this role helped me to better understand how to use SQL Server as a part of an enterprise solution.

In 2006 I began to re-establish myself in the SQL Server arena when I was tasked to develop a sales and listing application for an established real estate agent. This solution is still in use. In 2008 was able to focus my career with SQL Server as the primary component. In the years since I have worked on SQL Server 2000, 2005, 2008, 2008R2 and 2012 developing real solutions for real business needs.

I thoroughly enjoy, when faced with an authentic business need, creating a solution that balances the various but inevitable constraints that always exist. Sometimes this solution uses pieces from the grab-bag of knowledge gained over the span of a career. Sometimes it is necessary to acquire new knowledge. Regardless of which pieces are used to solve the puzzle it is incredibly satisfying to watch the solution come to form. It’s nice that as a grown up I still get to solve puzzles.