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.

Advertisements

WIT: A Quick Thought

I recently had the opportunity to be a Dungeon Master (DM) at a gaming convention. It was my first time. I loved it. So what does that have to do with Women in Technology (WIT)?


The young lady standing up also DMed her first convention. She’s my daughter and she’s 12. When we were signing up for DM slots, I asked the organizer if he felt there was any issue with her signing up to DM just like any other DM. He didn’t. She had been DMing D&D Adventurers League locally and had done well enough that he didn’t have any issue with it. 

He evaluated her on the merits of her body of work. He could have said no because she was 12. He could have said no because she was a girl. He could have said no for a whole host of reasons that had nothing to do with her ability to unravel the story, adjudicate the rules, and provide for a pleasant and entertaining player experience. He chose to judge her on her capabilities as a DM. 

When I work with colleagues, I care about their skills: technical and soft skills. I want to work with top folks so we can deliver excellent results as quickly as possible. I’m not interested in wasting time on the job because we have a less capable person that was hired and included only because that person meets some cliquish requirements that have nothing to do with the job. See, I have a personal life that’s important to me. I have folks outside of work I want to spend time with, like my daughter pictured above. 

I also want to deliver the best results I can to be competitive in the workplace and so my organization is as competitive as possible. Wasting cycles because somebody reminds me of my high school or college friends or because that person has more in common with me for non-work related characteristics than another is just plain foolishness. To do so negatively impacts my ability to stay gainfully employed and make a way for the people who are most important to me, like my family. 
As a group, the females in IT are in every work-related way as competent as men. They don’t need a helping hand. They aren’t less capable. They don’t cause problems unless folks go looking to cause issues with them. Yes, there are individual exceptions. But the keyword is “exception,” as in outside the norm and that’s true of any group of any reasonable size. 

Women should be evaluated based on their ability to do the work. And they should be compensated properly for that ability. And they should be treated properly as valuable coworkers who help us make stuff happen. They don’t want anything more than these things. It’s not hard to do these things. We only hurt ourselves and deny ourselves opportunities when we don’t do these things.

That’s what some gamers learned after giving that young, female DM a chance. At first, these gamers were skeptical. But they had signed up for those slots and wanted to play, so they did. And they soon realized she had developed the skills to be a good DM. They had fun. Difficult players were managed. The modules were moderated to be just the right challenge level and kept at the right pace. And they left with more stories about their characters and new found friends at the gaming table. They gave her a chance to compete fairly and she won them over. That’s how it is supposed to be for women in our career field, too. 

DevOps Does Not Make Admins Obsolete

As a follow up to my tweet, I stand by my belief that DevOps does not make administrators obsolete. I include Database Administrators in my statement. The core point of embracing DevOps is to determine what is repeatable and see if you can automate it. Why?

  • You’re trying to move faster.
  • You’re trying to reduce mistakes due to human error.
  • You’re trying to free up time of knowledge workers to work on more important things.

Let’s look at the DBA. Every time a DBA has to manually run a script, what is the DBA not doing? The DBA isn’t monitoring performance. The DBA isn’t checking code to see if it can be improved. A DBA isn’t reviewing audit exceptions that have hopefully been reported by an automated check. Think about the typical tasks a DBA has to do every time a new script is ready for modifying the database:

  1. Check out the new script from source control.
  2. Back up the database (possibly).
  3. Execute the script.
  4. Verify the results of the script.
  5. Report back that the script has been run.
  6. Back up the database again (possibly).

These steps, in and of themselves, aren’t hard. We expect a DBA to bring a professional eye to minimize mistakes, but mistakes do still happen (guilty as charged). What if all of that was automated? Then the DBA wouldn’t have to spend the time running through each step. As a result, the DBA is free to do so much more. The DBA can become a key player rather than someone who just executes code. That means a DBA has more time to show his or her importance to the organization. We talk about career security. Becoming a stronger knowledge worker helps move us towards that.

Which is why I say DevOps doesn’t make admins obsolete. It makes the ones who embrace it for what it is potentially more valuable to their current and future organizations.