SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 

Tinker as You Learn

In recent weeks I’ve seen my brother from another mother, Andy Leonard (twitter | blog), write or post about his learning activities. In one case he remarked that he liked it when he went to complete a learning lab exercise and it didn’t work as expected the first time around. When the lab doesn’t work, you have an opportunity to troubleshoot why. You learn more than if you just are able to follow the steps perfectly. Basically, what you’re doing is tinkering. And you gain more knowledge as a result.

In a second case he was asked by a friend if he could write a quick SSIS package. Andy did. But he also spent time figuring out different ways he could do the same task using BIML. More tinkering. More learning. He had the time. He invested it.

If you think about it, this is often how children learn. They don’t start following a series of steps: 1, 2, and 3. They pull things apart. They try things you aren’t supposed to try. Sometimes it works. Sometimes it fails spectacularly. And sometimes something new is the result. For instance, I wonder how the first kid got the idea to secure a baseball card in the spokes of his or her bicycle to make that clicking sound as the wheel turned. It doesn’t matter how the kid came up with it I suppose, but it was definitely a popular thing to do. Nowadays we have little pieces of plastic that do the same thing. But the first occurrence was found by tinkering.

I know that I enjoy tinkering, even if it is with something I supposedly know well. That’s how I was able to get so deep into SQL Server security. It’s also how I learned how to read network traces to understand how DNS, Active Directory, SQL Server, web servers, and other applications communicate at the network layer. That’s how I learned to spot and understand when something isn’t right in those communications.

Don’t just be content with the checklist or 1,2,3 types of learning. Play. Tinker. Try new things. If you’re using VMs, understand how you can roll back to a snapshot and how you can apply/commit changes forward. If you know these things, you can always get back to where you were if you do have that spectacular failure. And you can also set your new starting point if you figure out something interesting or effective. But most of us, don’t be afraid to tinker.

Databases – Infrastructure – Security

Brian Kelley is an author, columnist, and Microsoft SQL Server MVP focusing primarily on SQL Server security. He is a contributing author for How to Cheat at Securing SQL Server 2005 (Syngress), Professional SQL Server 2008 Administration (Wrox), and Introduction to SQL Server (Texas Publishing). Brian currently serves as an infrastructure and security architect. He has also served as a senior Microsoft SQL Server DBA, database architect, developer, and incident response team lead.

Comments

Leave a comment on the original post [truthsolutions.wordpress.com, opens in a new window]

Loading comments...