Since leaving the classroom and returning to the world of software development, I've tried to spend at least an hour a day reading about the changes that have taken place in technology since 2010. In July I started to dedicate my in-bed-before-sleep time to this task, and it's resulted in a lot of books being read and a bunch of new skills being acquired or refined. While it's impossible for any one person to know everything about a given subject, it should not be impossible for one person to know a healthy amount about a number of different subjects. This has certainly been the case with me while I learn more about data modelling, database design, and data warehousing. In fact, looking back at the technical books I've read in the last six months, it's easy to see that the vast majority are all related to databases in one way or another, and the four I have dedicated for January, February, and March are all on SQL Server.
I think I may have a little bit of a database fetish.
Last week I finished Stacia Varga's Developing SQL Data Models exam reference and I'm currently going through Victor Isakov's Administering a SQL Database Infrastructure reference in preparation for an upcoming Microsoft certification exam. On deck is Jose Chinchilla's Implementing a SQL Data Warehouse as data warehousing is a topic that has recently piqued my interest. Randolph's SQL Server 2017 Administration Inside Out is expected to be released by the end of next month, and I'll likely set aside some additional time to ingest the wisdom contained in the book. There's just so much to learn and explore!
A few people have asked why I read so much. They want to know specifically why I read so many technical books. When I think about it, though, the answer is not so cut and dry. Sure, I'd like to learn more about these tools so that I can make better use of the technology, but this isn't the only reason. Buried deep in the curiosity is the desire to discover what I do not yet know. As Bart Simpson so eloquently said to Mrs. Lovejoy all those years ago, "what you don't know could fill a warehouse."
It's true. We generally do not know what we do not know, and it's because of this ignorance that incomplete or inefficient decisions can be made to solve problems that other, smarter people may have resolved years before. Not a day goes by where I don't learn something new about the tools I use, and I hope this does not change anytime soon.
There's a certain excitement that comes from reading about an interesting feature or function, then trying it out and thinking about how it might be used to solve a real problem elsewhere. Back in November, I said that 10C would switch from MySQL to SQL Server just because I wanted to gain some experience with the platform on Linux. The conversion was finished mid-December, and nobody has reported any issues with the service since the switch. It was, by all accounts, one of the smoothest migrations of 10C I've ever performed. Learning more about SQL Server will (hopefully) allow me to do even more with the database going forward. More than this, I'd like to better understand how complex business problems could be solved with better use of this powerful tool.
While 10C is a personal project that I take very seriously and put a lot of care into, there is simply not enough "hard" work for me to do with the database. Businesses, however, ask a lot of tough questions. Depending on the quality of those questions, businesses may ask the question again and again in the form of reports. Being able to build the SQL queries to quickly and accurately return the answers is certainly a worthy place to use the skills I'm working so hard to acquire.