• Short article\post authors on Professional Development topics as they relate to the SQL Server Professional
• SQL Bloggers who would like their existing professional development content syndicated to the PD feed like general topic on SQLServerpedia.
• Volunteers for monthly live meetings
• Help us spread the word through your networks and blogs
• Your ideas on how the Professional Dev PASS virtual chapter can serve the community.

This chapter can only be as good as its members and by helping the chapter grow, you are really helping yourself grow.

So what do I think consists of professional development? Well, you could start of with this tag but that might give you the wrong impression. Let’s see what the Internet says:

From Wikipedia:

Professional development refers to skills and knowledge attained for both personal development and career advancement. Professional development encompasses all types of facilitated learning opportunities, ranging from college degrees to formal coursework, conferences and informal learning opportunities situated in practice. It has been described as intensive and collaborative, ideally incorporating an evaluative stage ^[1] There are a variety of approaches to professional development, including consultation, coaching, communities of practice, lesson study, mentoring, reflective supervision and technical assistance.^[2]

http://en.wikipedia.org/wiki/Professional_development

That is pretty close to what I was thinking especially skills\knowledge obtained for personal development and career advancement. Here are some PD topics IMO:

• Social networking\Blogging
• Handing tough situations\office politics\obnoxious coworkers in the work place
• Negotiating offers and raises
• Career path decision trees
• Job seeking skills
• Presentation delivery techniques
• Management(Time, People, Project etc.)
• Development of organizational skills
• Volunteering in the SQL Server community

And the list could go on for a long time. Hit Arnie, Mark or myself up if this is something you would like to help out with.

What do you think should be covered in a Professional Development virtual chapter?

Relevance, please?

So, you ask, what does all that have to do with Professional Development? I just advertised some things about the kind of person I am. It is now part of my Internet Image. That first paragraph is like a tattoo. It will never go away. This is what some say should be avoided when speaking of internet image in the SQL Server(and beyond) community. They say maintain the most upmost professionalism at all times. That is one strategy and I agree it is hard to get into trouble being conservative. However, you can also be yourself if assume the following:

• (Today’s + affirmation) By acting myself, I can interact with people with the same interests as me, I am likable for who I am, and I want to associate with people like me even in a professional environment.
• I would prefer to work in an environment where I fit the general culture.
• By fitting in with the culture, I am a foot a head of an equal job candidate for same position that does not fit in the with culture.

Talking about myself again!

To use me as an example, I display my xbox gamer tag proudly on this site. I would not want to work for a company where most of the people do not own Xboxes. At the same time, I would love to work at a company where there are games in the break room.

Of course, you can cross the line and use poop or toilet analogies. At the same time, wouldn’t you prefer to work for a boss who appreciated crude internets geek humor if that is what you are into? Same goes for bowling, knitting, d&d, and wiccan magic. He77, if it was not for HR, my first question to potential job candidates would be “What is Goatse?”. I kid but as a hiring manager, I do look for technical ability first but cultural fit is a not too far behind. Look at it like this. I do not care if I walk by and one of my DBAs is reading the Onion because I know when a server explodes and the ʪĦÍŦ hits the fan, they will be there be it for three hours or thirty; what ever it takes to recover, boot, or function. That intangible quality is a job skill!

Where is the line?

I suggest that anytime you ever post anything online, you follow this decision tree.

• Picture your dream job that you want to be in DBA century(10 human years)  from now.
• Ask yourself if this will help or hurt your chances for that job?
• If the answer is yes, then ask yourself if you would be happy working for such a company\manager?
• If both answers are yes, then do not post!
• If either are no, post away.
• If drinking tasty cold alcoholic beverages, immediately post something “insightful” on your boss’s boss’s facebook wall.

So can this backfire?

There are also other circumstances that I should warn you against being yourself like if you are the only one who laughs at your jokes or is boring, obnoxious, always right, a trekkie, or a LOTR fanatic(7 hours of walking! Even the trees!).  These mostly hold true for the unforeseeable future too so if you are not confident in your future, you may want to exercise caution as well and remember that life happens. Here are some things that would make me be more conservative.

• Your job market is small. Examples include a small town or a very small niche specialty like a Sybase to SQL Server conversion specialist in Bee-eF-eeVille, Texas.
• Your experience lends to junior level jobs for now. We all started off some where. Until your technical experience outpaces any possible negative perceptions, then a conservative route made be prudent. As I said earlier, it is hard to get in trouble being conservative so when in doubt, lean tight right like a southern Baptist GOP senator in the closet.
• Religion and politics(previous bullet aside) – This is more of my personal preference because a valid argument could be made for putting this out there. I, on the other hand, think that my dream job could be working for someone that I don’t agree with on Religion\Politics and I think the hiring manager may choose an equal but “image conservative” candidate over me because of it. However, if this is your cup of tea, +10 street cred homeboy!
• You are conservative by nature. I am only making a case for being who you are. Do not portray anything you are not.
• You think you may change careers over the next 10 years. Again, life happens. Lean conservatively unless you are confident in your future.

What am I trying to say...

I have not spoken much about the benefits of this openness on “The CPU” as my wife calls it. Let me wrap this up with that. Basically, it is more fun and more natural to be ourselves. I believe you are more interesting. Why hold back personality for dry dull dialog? That said, being anything but being the utmost professional on the internet should be done after careful thought so don’t log into alt.binaries.erotica.asian.furry.midgets.multimedia with your real name! Besides, I have worked for the same company for the last 10 years and I do not think I will be looking over the next 5-10+ years so take this with a grain of salt. Lastly, the golden rule is don’t do anything you would not be proud to show yo mamma.

Speaking of…. Yo mamma so nasty we tried to flush her dirty pages with DBCC DROPCLEANBUFFERS  but it kept failing because of the stench from that puss bubble excreting from her VLF. BOOM.

Let’s look at an extreme example of cycling the errorlog nightly. This could be as simple as setting the retention policy to greater than the default of 6 and configuring a job to run sp_cycle_errorlog. However, let’s get thorough.

1. Lets write our own proc to  do this. It calls sp_cycle_errorlog but we want to add our own logic.
2. Lets start off by writing to the windows application log: “Beginning Errorlog Cycling Process.”
3. Lets dump the errorlog to a table in msdb in case we ever want to query it.
   1. Dump xp_read_errorlog to #table and do a binary_checksum() with the new rows in the errorlog table so we are sure that SQL Server inserted them correctly.
   2. Errorlog table cleanup process
   3. SSIS package to push errorlog entries of the past 24 hours to a centralized enterprise-wide errorlog repository.
      1. Checksum across linked server
      2. Extract to text file increase we ever want to view it like a real errorlog file.
         1. Create a file name creation function that created a “unique” name and a table that maps the “unique” name with something that a human can understand.
4. Prechecks for sp_cycle_errorlog
   • Check disk space
   • Run checkdisk
   • Verify the previously cycled errorlog has a date of getdate()-1
     • If the previous errorlog is less than 24 hours old, check to see how long SQL has been up.
     • If the previous errorlog is older than 24 hours, halt processing. Page the DBA team with a critical alert because this should never happen EXCEPT once a year during the time change.
   • Run a custom process that steps through the previous steps to verify the completed successful.
1. Run sp_cycle_errorlog
   • Set the step to retry 10 times.
   • Log the Output to a text file.
   • Write a custom windows email service to send the results of the job step to the DBA team encrypted with PGP.
2. Post sp_cycle_errorlog steps
   • Zip errorlog
   • verify the archive with the compression software
   • Run a CRC on the zipped file
   • Copy the archive to the file server along with a text file containing the CRC.
     • Run a CRC on the file server and compare with CRC in the text file
3. Write “Cycle Errorlog Process Complete” to the windows application log.
4. Email the entire DBA that this process was successful.
5. Move copies to the cloud at Amazon’s S3, Windows Live Drive, Drop.io.
6. Pass the entire content of the errorlog to twitter CHAR(140) as a time for the internet can crowdsource your errors.

Again, extreme example but that is being overly thorough to put it mildly. Where is the balance? I think I have come to realize that a trait of a great DBA is balancing thoroughness with discretion. Some tasks\process\queries need the utmost level of thoroughness yet some just need to work. Sometimes, you have something that needs to be thorough but it is more important for the query\task\process to be in place yesterday. In that case, you have to sacrifice thoroughness for speed.

I am glad I was able to step back and learn from the real world example that got me thinking about this.

What personality traits do you think tend to be common among the top 10% DBAs or geeks in general?

This principle is just as important when troubleshooting problems in the database world. Fixing the wrong problem can also cause the funk to explode.  You may think that getting the problem statement is an obvious and trivial task. Sometimes it is staring you in the face. Sometimes, it is harder. Here are some scenarios that make it difficult.

Troubleshooting Derailment Factors

Being told what the problem is – Imagine a dev or business analyst telling you there is a data problem. They say there are duplicates rows. However, it is really their query. Business rules allows for dups. If you don’t identify the query as the problem, you could burn time or worse, “clean up” the dups.

Identifying a symptom as the problem – Let’s say that your cluster keeps failing over periodically. You do some troubleshooting and find out it is because of SQL agent. You think it an easy fix and you set it to not affect the group. However, now the agent fails and stays down all night. The business critical ETL did not run. Come to find out that the real problem was a flapping disk that the agent log file was on.

Being under the gun – When the database is down, sometimes it can be hard to step back and identify the problem when all you are focused on is getting it up. This can be dangerous. What if you have database come up suspect? While hastily trying “things” to get the server up, you try to detach\attach it. Now what?

The Power of the Problem Statement
By identifying the right problem, you can focus in on the possible solutions and use your knowledge and resources to pick and implement the best solution as fast as possible. This can save us from go down tangents, fixing stuff that does not need to be fixed or making a bad situation worse.

“You know, Bob, I cannot remember the last time SQL was down. You sure are doing a good  job.”

“Gee, is the log always that big or are you happy to see me?”

Ha, every production DBA knows those compliments NEVER happen. We have a thankless job. No one ever notices until the database is down. Think I am kidding? When was the last time you told your Exchange buddy how solid the mail server has been?

Well, I am talking about a different compliment. Actually, Colin Stasiuk (Twitter) is talking. Complimenting skills is of which he speaks. I just thought this topic deserved more than a comment.

Colin writes:

I’ve always ranked myself from a discipline point of view as:

1. Database Administration
2. Database Development
3. Business Intelligence

Now I’m trying to decide if I should “bone up” on the business intelligence side of SQL Server to try and get that around where my database development skills are at or whether I should branch off and do something different altogether.

The short answer is YES and it is not meant to answer Colin. I just think this is a great topic. It really doesn’t matter how you grow as a professional(and person in general IMO) as long as you grow. Aww, *hugs4all luvu2* It would be helpful if you choose something that adds to your professional capital but, hey, taking up Feng shui may provide the stress relief that you need to take it to the next level.

Staying on topic marginally, we will focus on the most relevant side technologies to a DBA and related database professionals.

Colin mentions the three pillars of a database professional:

First, I would like to applaud PASS for taking a huge step forward in two areas. First is marketing. They have grow the submissions,  sessions and attendees at an exponential pace. I guess they will beat TECHED this year. They also introduced a social element to the process. Once you submitted an abstract, it was open to others to view. This creates a crowdsourcing element. It makes the community to step it up a notch. The result is a better conference for the participants due to competition.

Here are a few tips from my experience on both sides of the isle.

• Get a proof reader. Word can spell check but it does not pick up on everything especially punctuation and grammar errors. I suck at this too. If you read a blog post from me with no grammar errors, it probably means the wife proofed it. I saw this a lot with foreign submissions. Some of these sessions, I am sure the speaker would do a good job but I have to take points because of this.
• Use vivid action verbs. Do not use have, be , was, were etc. However, go beyond action verbs like “learn” and tell us what attendees will “consume”, "be inundated with”, “be bombarded  with” etc.
• Use as many characters as possible. There were a few short abstracts that I found short but good. However, at first glance, I was hesitant until I realized the abstract was very, very concise. In general, it is better to use more words than necessary than too few. If you have the gift of conciseness, good for you. Otherwise, use words!
• Submit as many abstracts as possible. This should be a “duh” bullet but I see MVP’s and authors submitting a single abstract on topics with lots of competitions like virtualization, SAN, and performance. Max out your submissions. Some conferences will not select you unless you are selected for at least 3 sessions.
• Start out and end with a BANG! This includes the session title, the first sentence and the last sentence. If your abstract is two sentences, keep working.
• Especially if you are new, look for topics that are not covered every conference several times like performance, consolidation, SANs etc. However…
• Do not submit niche topics. A heath care or financial industry related topic might be compelling but spin it as a compliance topic that could be applied to a lot of industries.

Anyway, I would be happy to review your abstract in the future and provide constructive criticism. Feel free to drop me a note.

Here is the the basis of the meme to quote Mike.

When I wrote about empirical evidence and learning through trying (instead of asking only), I got thinking about things I wish I knew when I was a Junior DBA that I know now.

So here is what I know now that I wish I knew then(and usually learned the hard way).

Microsoft Project is your friend.

I have written about this before but it is worth it to revisit. I started out making big production changes to mission critical systems with nothing but a task list in my head. I evolved to notepad and then excel. My success % improved with each jump. Now, I can floor my boss and customers with downtime estimates accurate the minute. On top of that, I can establish doable timelines and get more resources if my time line does meet expectations.

You can be your worst enemy.

Ego can make a brilliant employee a liability. It manifests is several ways( at least for me).

• Jump on the new groups sporting all your brand new certs in your sig trying to “help”. However based on attitude, it is clear you are there for the wrong reasons usually attention.
• Bogarting knowledge. So you know something someone else does not, teach them instead of holding it over them. Help out he jr guy. He may be your boss someday.
• Ego can keep you from asking for help when you are clearly in over your head. I still struggle with this one.

Life is so much better when you are modest rather than smug.

If the hole is round, a square peg may not be the best fit.

I have officially become platform agnostic. SQL Server will always be my first love and what I am best at but there are other products out there. Not that I know everything there is about SQL but I don’t learn 10 new things about it everyday like I used to. As a n00b, I learn 30 new things a day about MySQLOracle. There are valid reasons to go MySQL or Oracle over SQL Server. That is just the way it is. Imagine rewriting the DAL layer for Wiki or Wordpress just because you had to run it on SQL Server. If you drink that much koolaid, more power to you. I think knowing the features and limitations of other platforms helps me as a SQL Server DBA as well.

The GUI is not your friend.

I used to be an enterprise manager DBA. When I learned how to admin from TSQL, that is were the Senior DBA level skills came in. I still use the GUI if it a click or two vs. several lines of code but I know how to write it and, if need be, automate it. If you can’t, learn.

Know X as good or better than the subject matter experts

Where X is technology that interacts with the database: The OS, hardware, SAN, network, and application code. Of course, this is not always feasible. I have never jumped on a switch to prove it is not a SQL Server problem but I have gotten pretty close. Once when all fingers pointed at SQL Server, I had them check the switch for errors and sure enough the firewall was set 100/half duplex. If nothing else, learn the hardware and OS inside and out.

Next Victims

Jonathan Kehayias(RSS, Twitter)

Jason Strate(RSS, Twitter)

Rob Boek(RSS, Twitter)