Ever wonder how some people always seem to know the answer in SQL Server? Or seem to come up with it with a minimum of digging around?
Well, they’re not necessarily cleverer than you, it could just be that they’re better at playing with SQL Server than you are. Knowing how to quickly and simply build up a test scenario means whenever you want to try something out, or prove a hunch then you can be most of the way to proving something while others are still Googling and Binging away. Or if you’ve found something on the Internet, you can check it does actually do what it claims to. Because as Abraham Lincoln once said:
It’s the 2nd Tuesday of the month, so it’s another T-SQL Tuesday. This months is being hosted by Bradly Ball (blog | twitter) who’s set us the assignment topic of “Second Chances”.
Now I’m sure most SQL Server DBAs (and all other techies for that matter) have lots of stories where something went horribly wrong ,and they got another chance to get it right, either with or without their employees best wishes. But those are mostly horror stories to scare people onto the right path!!
Instead I wanted to talk about about those ‘second chances’ you get, even when the first chance went well (And was probably ignored by the PTB becase of that, c’est la vie). They go well, and we feel happy as we leave the office. But there’s alway the niggling feeling that we could have done it better somehow. Maybe it could have been faster, or we could have taken the chance to implement more features, and that’s where our second chances come.
Even if I’ve done the same task before, I want another chance to try something different when I do it again. Perhaps I’ve read something online, and it looks good on my test rig, and now I want to try it on something large but not too important. Or I’ve been to some training (or conference) and picked up some useful information from a presenter. This is a perfect opportunity to try it out, but very carefully, unless you want to end up needing one of those less pleasant second chances.
And I take it as good practice to regularly review previously written scripts or setups. 3 months after you’ve written it’s amazing what can jump out at you as a less than brilliant solution, or a bit of fresh insight offers you a better way to set things up. Another good reason for keeping notes on how things went when you do a large piece of work. For example, I have a folder full of notes I’ve built up building SQL Server clusters over the years. Because I can refer back I can make sure that I don’t repeat mistakes (and there have been some), but can also look at what can be improved (even non technical aspects, my recording spreadsheet for clusters has become a thing of great use rather than an after thought).
As SQL Server professionals we should be trying to make sure we’re always learning and refining our skills, so we need to make sure we take all the opportunities we get to improve and learn. Even if it is just doing something we’ve done before again, or we think we can shortcut things by just reusing the same scripts we’ve used before.
So grab hold of second chances when they come along as they can be a good thing.
I’m in the middle of recertifying as a SQL Server MCSE, studying for a Mathematics Degree with the Open University and trying to train for various long distance cycling events. It can feel like an uphill struggle to fit it all in and still have time for friends and family (and the cats). And that’s without the usual 9-5 we all have
So how to juggle it all?
I try to think first in long term chunks, usually 6 months and 12 months. For an OU module I have to think across a whole 12 month period as that’s the teaching period. For my MCSE I can split it into 6 month chunks (doing MCSA in the first 6 months, and then the remaining exams in another 6 month period).
Once I’ve made sure that I am not overloading myself in one period I make sure I have all the dates on the calendar.
First off I block out any immovable dates, for example our wedding anniversary, OU exam periods, important birthdays, etc. These are sacrosanct and I either can’t or won’t move them. Everything else has to fit in around these, or will have to be a once in a life time opportunity.
Next to go in are the dates I want to achieve something. This could be an MCSE examination or a particular Audax event. These could be fixed or movable. This year for example:
I have a fixed goal date of the end of July for being fit enough to ride the London Edinburgh London audax. This can’t be moved.
I have an exam date set in August for completing the MCSA phase of my MCSE qualification. This could be moved if needed.
OU assignment hand ins. These are a fixed deadline, but I can hand in earlier if needed if I need to free up time. (Next week I’ll be doing this so I’m not working through a holiday)
Now I’ve got the goals I can start working backwards to work our what needs to happen when. How I do this for each goal will be different depending on how I need to study or work towards them. For my cycling goals I know I’ll need more time and effort as the goal nears as I’ll be taking longer training rides. Studying for my courses and exams should hopefully remain constant with just a slight increase in time as I revise before exams.
Now I’ve a good idea of what I need to do and when I can start to plan my weeks to make sure I’ve got some time set aside to get everything done. So I’ll block out 3 hours on a Wednesday straight after work to go for a long training ride on the bike, with shorter 1 hour rides on a Monday and Friday. Then I might schedule 2 hours on a Thursday after dinner to work on my OU course or even 2 evening for some of the tougher modules.
By having a set routine it gets easier to remember what you’re meant to be doing when, and all the other bits and pieces fall into place. And by sharing the routine with my wife we both know when I’m going to be busy, or days when I’d rather not have something else happen.
But having done all that planning it’s important to stay flexible, stuff happens.
A tier 1 database down at work 10 minutes before clocking off time on a wednesday, you can be sure my bike ride’s gone out the window.
A friend is visiting town for the first time in years on a Thursday evening, not a problem, as I know when my free slots are so I can move my study time around to suit.
All of it’s easily coped with if you’ve left yourself some slack. And remember, it’s always good to have some downtime. A night in from of the TV isn’t wasted if you’re relaxing from hard work on the other nights, especially if you’re relaxing with loved one.
This is the story of how I cam to love presenting, how we went through a rocky patch, but patched it up in the end.
Years ago I was getting swamped by work. Everywhere I looked there seemed to be another call coming in, another request for something to be done, another bit of housekeeping that was begging to get done, all of it landing on me and swamping me. End result,an unhappy DBA who didn’t feel as though he was developing any new skills or progressing his career.
Then I realised, hang on I’m part of a team, why aren’t we sharing? So at a rare team meeting I asked around, and it turned out we all felt the same. While we all wrote our mandated documentation, no one really felt they could delve into some else’s domain. So we decided the best way was to do presentations across the team, cross training each other into our areas.
This was a revelation. Suddenly people were interested in helping out, documentation didn’t seem quite so much of a chore as there was a real point to it. Team meetings changed from a dull routine to satisfy management into something to look forward to as a chance to learn something new. Everyone in the team learnt some new skills, and we became a much more efficient and cohesive team. And because we were efficient we had more time to learn new things for ourselves, so everyone was a winner. And I discovered I loved presenting. Seeing the light break as someone grasped a new concept, having to approach things from a different angle, having to break down concepts to there simplest levels to make sure I understood them; all of this was great
But soon the shine wore off a bit. We’d passed on all the work related information, and the excitement of presenting had warn off a bit as I knew my audience to well. With every presentation I knew the level to target, and even the best way to address a topic to specific team members. So me and my presenting stumbled around in the doldrums for a bit. I’d occasionally get excited when I learnt something new to me, but the thrill just wasn’t there anymore…..
I’d been attending SQL User groups for a year or so, and loved seeing some of the top SQL Server gurus from around the world presenting to small groups and having to deal with such a wide range of audience knowledge and engagement. I mean, only a short slot to present something technical, to a group you’ve never met, when you’ve no idea if there’s going to be an expert in the crowd ready to pick you up on something, where there could be a large section who have no interest in your topic but you still need to win them over, this looked like just my sort of gig.
I’ve now presented at 2 SQL Server user groups. And each time I got that same feeling from years ago. The flame is back, and I’m constantly thinking about how to improve my presentations, or how I can build one out of things I’m currently working on. I’m also paying more attention to speakers presenting skills than I did before, trying to work out if there’s anything I could ‘borrow’ to improve my skills. And I dig deeper into topics, because I want to be able to explain each oddity, or be ready for the off kilter question from the audience.
In fact most of my training for the coming year is based around becoming a better presenter and teacher. I want to do more User group presentations, have submitted to a couple of SQL Saturday events, and want to try to do some of the larger conferences next year. I’m also working on an MCT, and am even considering taking some speaking classes
So go on, get up on the stage. Presenting, whether to colleagues or a User Group could be just what you need to perk up your career or rekindle your passion for your job.
While picking up new technical skills is the main reason for attending SQL Server events like User Groups and SQL Saturdays, there’s also another very good reason for attending. Watching some of the presenters just present is of great value.
All the speakers are obviously technically very good, but what really separates them from the other technical people present is their presentation styles. There’s a wide range on display, from the ultra focused business style talking about career enhancement to the enthusiastic geek motivator who’s all about getting you fired up about the newest tech.
But even with the difference overall feel, there’s still some common points that I aim to always incorporate into my presentations:
Be prepared. They make it look pretty effortless as they turn up and go. But that’s down to have rehearsed and practiced the material, and knowing they have a backup should anything go wrong
Engage with the audience. There isn’t a feeling of “you’ll sit there and watch and listen for the next 45 minutes”. They try to get the audience to interact with the material and think about how it would work for them
Time Management. They have the time built in to answer questions on the fly, but also know where they are in the presentation so they can politely say ‘talk later’ if they’re running behind. And from watching them do the same presentation to multiple audiences they also know how to extend it if noone’s asking questions.
Clear, easy to read materials. Slides aren’t cluttered with logos or fancy backgrounds. And occasionally handouts for frequently referenced info, this is a great idea, and makes it easy to take something away at the end.
So that’s just 4 quick and easy things to incorporate into your own presenting then! But in my opinion they all tie together, and the main thing you can do to bring them out is PRACTICE.
I’m sure my cats know more about SQL Server then any other cats on the planet, but they do insist on sitting there watching me present to no one with slides on the wall of the home office. Luckily my wife will also put up with me doing it, and in fact will often be a source of good feedback. As a non technical person, if she feels she’s sort of following the plot I’ve got the level right.
And it’s very rare that I’ll give the same presentation twice. Each time I present something I try to get feedback (and really appreciate it being given) and then use that to feed back for the next presentation.