SQL University – Professional Development & Knowledge Sharing

This week is SQL University’s “Professional Development” week. Andy Leonard is a pro when it comes to this topic (check out this post and the links on it to see what I mean) and I asked if I could sneak a post in along side his this week since it is a topic I tend to gravitate towards (primarily as a means of teaching myself lessons I need to learn). I was going to write about some hallmarks of a good DBA or any IT Professional (Things I’ve blogged about before like when talking about owning mistakes or a post recapping lessons I learned at the dump). A recent post by Jason Hall, however, gave me a different thought process –

Everyone Grows… Or Everyone Fails

A hyperbole? I don’t know but I think it holds true. Jason’s post talked about his experience at a conference working at a vendor booth. He had a lot of conversations with developers and many sounded the same, apparently. They wish their DBAs shared reports and info about the system with them. My first instinct was to write a comment and say “yeah.. right.. I’d like to find some developers like that!” poking fun and adding fuel to the stereotype of DBA-Developer, umm, relationships. It started my thought process, though. Do we do enough as DBAs to share? Do I? Sure, I teach some classes for performance minded development wherever I am working. Sure I’ll answer some questions but is that enough? Do you share enough? Does your company? Or do you subscribe to the notion that…

Knowledge Is A Weapon?

I’ve worked with folks who believe this. I’ve worked at organizations where that notion is deeply set. Do you know what I mean? Getting information is like pulling teeth, people keep you guessing. Perhaps they are afraid of being less important. Perhaps they are afraid of their team losing an edge. Whatever the reason the end result isn’t great for anyone involved. Share. We learned that in Kindergarten. Heck we learned it in preschool and our parents enforced that rule often, especially if we had siblings. It works today in the corporate world, it works on technology teams.

Some Ways A DBA Can Share?

There area a lot of areas we can share better but some thoughts (and before you get uncomfortable, my standard professional development disclaimer applies – I am talking to myself as much as I am to you)

• Teaching/Mentoring – I really enjoy this one. Setup some brown bag lunches and teach a topic. Take a presentation you’ve received and regurgitate it to the rest of the DBA team, to some Developers or to the system administrator team.
• Show Them The Reports! – Like Jason said in the blog post that inspired this one. What’s the harm in letting others see the state of things. Developers might see the impact (positive or negative) from a development decision. Architects can see the effects of a design decision. Your peers and management will see, gasp!, the state of the environments you manage. Sure… I know this might air some dirty laundry but are you doing the best job you can do? Are you working your tail off on proactive tasks when you aren’t interrupted by reactive ones? If you are barely keeping your head above water because of too much reactive work for one DBA perhaps a couple black marks could even work in your favor.
• Documentation – Yeah.. I don’t like doing it either but Documentation is to be embraced.  It lets you go on uninterrupted vacation, it lets other staff back you up or do rote tasks and it just makes life easier for all involved.
• Participate In Meetings – Meetings!?! I know. I hear you. You have to go to them anyway, so instead of just playing Dr. No (Actually, I sign on to corporate web meetings as “Dr. No” but that’s another story.) explain things, offer suggestions and let people know what is going on in your head (related to the topic at hand, please)
• Check Your Motives – I wish I could say that this advice could never have anything to do with me. I can say it usually doesn’t but I catch myself letting that evil pride get in the way sometimes. As I get “older”, I find it occurring less and less. In the past few years, I’ve started to embrace offers for help. It means I have one less thing to do. I’ve started to jump for joy when a colleague wants me to teach them how to do a part of the job that I used to think was “mine, all mine!” It means I can focus on something else that needs to get done. It means I might have a week that is close to 40 hours because of the help. Some Tips for checking the motives?
  • Help is Help – Remember that. Help isn’t someone showing you up. Help isn’t someone trying to steal your job or “be better” than you. In fact, what does that even mean? Why do we go to our jobs? Is it to be better than people? I go to provide for my family first and foremost (though I think I’d sadly still enjoy doing something with technology and SQL Server even if I didn’t have to… maybe not as many hours). That means I am there to do the best job I can do for my company. I am there to make sure we have a more successful day each day. That doesn’t mean I have a more successful day but that the company does. That means my team should do the best we can do. If someone wants to help me on that quest, I should jump at the chance – there are enough people to deal with that seem to not have that same goal in mind (alright, I’m half joking)
  • All Boats Rise Together – If a colleague does a better job, the team is doing a better job. Maybe the analogy sees failures in some sports, but I think a team of team oriented players looking to succeed as a group does better in the long run. If you are the A player in a subject your goal should be to bring the B/C/D players up to A level. it shouldn’t be to keep them down so you have some sort of an edge.  Like I said above, everyone grows, or everyone fails.
• Honey, Not Vinegar – Sure we will always see people who aren’t like minded. We will always deal with less than optimal (and that is being nice) code, time lines, architectures, hardware, storage subsystem, etc.  You can write off the people or teams who create these situations or you can help them out. The former will give you a chance to use some new “witty” sarcastic comment. The latter will help prevent problems in the future without alienating people. I’ll be honest here, I have found myself tempted to go with bitter approach at times. I’ve even given in and it did nothing good. Technical accomplishments were forgotten and the attitude was remembered. Projects weren’t improved and issues were resolved angrily, if at all.

No Auditing

SQL University students are tough and determined. Someday there may be a Microsoft Certified Masters student who got their start reading posts here. Real students don’t audit. So… There is a homework assignment. It’s simple though: Try it. Publish a report from a monitoring tool or the SSMS reports. Show someone how to look at one of the tools you like to use to track your environment. Approach a code review as a time to partner with development in the same goal – meeting the requirements – exceeding them, even. Be sickly positive even when faced with some pretty frustrating situations and share knowledge, work with the goal of making the environment better. I’ll be doing the homework assignment myself and I’ll report back here in a week or two with the results. I just ask you to try it for a week and let us know in the comments what you ended up sharing. Enjoy the rest of the semester at SQL University and I’ll see you in a couple weeks when I am your official instructor during the week discussing SQL Server tools (instead of lecturing during Andy Leonard‘s class 😉 )

Other Professional Development Posts

Some other topics in the “Professional Development” vein.

• Checklists, Recipes and Algorithms – DBAs can learn a lot from Pilots, Chefs and Doctors. I blog about it here.
• One Man’s Trash – While at the dump, I picked up an important lesson about attitude.
• Bill Clinton Wasn’t Impeached For… – Own your mistakes, it is often the best solution in the long run.
• Day Job Lessons From The Garden – Sometimes some manual labor will give a few good reminders.

Update

I’ve done some of my homework. I took some reports from the monitoring tool I use and published them. I have a time setup to training folks on the reports and publish the URLs out. I’ve also been working on the security policy which allows developer support teams the ability to look at server information (view server state) and query (select only) from certain log tables. Giving them the information to help me. How about you?