Doug Lane

SQL Server Entertainer

10 Essential Skills for SQL Server Beginners

by

Jesse Seymour recently asked this question on Twitter:

This is a GREAT question because many people starting a path in business intelligence, SQL Server, or other technical fields often struggle to figure out what skills are important. Early in my career, I struggled with this too because I simply wasn’t thinking about professional development. I was focused on putting one foot in front of the other, only solving the immediate problems. If I were to begin my career again, here are ten skills I’d start building as soon as possible:

1. Listening for and understanding the desired outcome

The ability to listen is critical.

I repeat: The ability to listen is critical.

Every project, every assignment, every task has a desired outcome. As technology enthusiasts, it’s easy to start mentally sketching blueprints as soon as we hear someone say, “We need a data warehouse in the cloud.” The funny thing is, sometimes that’s not at all what they need — it’s what they imagine they need. What really matters are the requirements and the desired outcome. Maybe what they really want is a lot of historical data with 24/7 uptime, and “the cloud” just sounds like the best approach.

Here’s the catch: right now it’s up to the people above you (senior developers, architects, or managers) to figure out how to pull it off. They understand the technology, the inner workings of your company, the political landscape, etc., much better than you do. Ask what they heard and how they’re translating requirements into a solution. You’ll get valuable insight into the business, established relationships, and why proposed solutions are likely (or unlikely) to work.

Eventually you’ll be asked to do the translating, so start learning how to do that now.

2. Listening for and understanding concerns

In addition to understanding what people want to happen, you must understand what about this outcome worries them. There may be negative consequences associated with this solution, even if it’s successful. For example, implementing a new data warehouse adds new overnight processes, making it more likely a DBA will have to fix it in the middle of the night. Or perhaps launching a new web portal means more openings in the corporate firewall and increased risk of breach. Whatever solution you end up building needs to account for these concerns. Whether they’re legitimate concerns or not, they are real to whoever is expressing them.

3. Understanding how any previous attempts/initiatives failed

The concerns about your solution may be rooted in history. If you’re in an entry-level or junior position, odds are you haven’t been with the company since its inception. Before you arrived, there were other projects — some successful, some not. If the desired outcome has been attempted before, you want to understand why it fell short. By paying attention to what has/hasn’t worked in the past, you’ll learn to match the right solutions to the right problems. Also, if something was such a spectacular disaster that it got people fired…yeah, you want to avoid repeating that mistake.

4. Technical curiosity

There’s a common refrain among the people who rise to the top of their technical field. When they observe a behavior, for example a function returning unexpected results or a report rendering strangely, they wonder why that is. Then they dig in to find out why. They have a scientific curiosity for technology. When Kendra Little introduces herself at a presentation, she often mentions she’s a Microsoft Certified Master, which means she broke SQL Server a lot.

Without technical curiosity, you won’t feel the urge to explore and understand. You won’t spend your spare time reading blogs, building a virtual lab at home, or coming up with your own open-source script to share with the world. Your career ceiling will be lower.

Senior developers and DBAs become senior because they care about why things work. How far you go depends on how much you care.

5. Learning to research efficiently

This is a vital skill, so much so that it’s the basis of the best compliment I ever received in my career. The era of finding what answers you could by scanning a cabinet full of 800-page books is over. (Hey, at least now they’re sold in searchable, portable e-book form.) There’s now an abundance of helpful people on the internet who want to share what they learned in solving a specific problem. By leaning on their experiences, you can reduce a frustrating, days-long quest to fix an error down to a hiccup easily solved before the ten o’clock status meeting.

If you know where and how to look, that is.

The more research you do, the more you learn about which sites and blogs will help you the most and which ones to avoid. You learn what phrasing and keywords get you to the answers you’re most likely seeking. Over time, you learn who is giving you the answers that work. You learn how and where to ask questions that get responses quickly.

An added bonus is that your colleagues will start coming to you for answers, knowing that even if you don’t have the answer, you’ll be the fastest at getting it for them.

6. Self-control to stick to the problem

It’s called “scope creep”. In the consulting world, it’s a reason to say no to adding a feature. In the junior developer world, it’s a reason to say yes. It’s tempting, as you learn new technological tricks, to try integrating them into the project. After all, why not put that new-found knowledge to good use? What you just learned is a shiny object, a squirrel darting in your peripheral vision. You can recommend this new technique or feature be added to the project, but be ready to a) defend it as completely relevant and important and b) have it shot down immediately.

Don’t get discouraged though. It may be the right technology for the wrong project. File it away as something to remember for future projects.

Also, make sure you get approval to explore a new method or feature before diving in. I’ve had a simple chunk of code eat up two weeks of my time just trying to prove it can run before I ever mentioned it to my boss. When I did finally tell him, it was not a fun conversation.

7. Communicating progress clearly

Estimating time is really difficult. One of the most awful questions you can get is, “How many hours do you think it’ll take to complete?”

I hate that question with the fire of a thousand suns.

(I’m not alone in that sentiment.)

It seems especially unfair if you are junior-level because you’ve probably never done this particular thing before. How the hell are you supposed to know how long it’s going to take? Frequently, the last 20% of the work takes 80% of the total time. It’s the nature of software development. You don’t have much control over that.

What you do have control over is communicating your progress. Consistently and clearly state what you’ve done, what has yet to be done, and any anticipated challenges. This demonstrates your willingness to be transparent and held accountable. It also means your boss will be able to better recognize when it’s time to have someone else help you along.

8. Willingness to ask for help

Tenacity and grit are wonderful things. So wonderful that you can grit yourself into being three weeks behind because you just know you’re going to get this feature to work. Be real with yourself. You’re a junior developer or DBA. You’re not going to have all the answers, and you’re not always going to have enough time to find them on your own, either. This is where you can lean on your more experienced colleagues to pull you up. You may be surprised how eager they are to help by explaining a difficult concept, sharing a useful piece of code they keep handy, or offering to help debug your code.

You may not know how to return the favor, but here’s one subtle yet powerful way: let that person’s boss know they helped you. Bosses love when senior staff are willing to teach and mentor others.

9. Willingness to yield for the project’s greater good

You might have to face the fact that the feature or code you’re working on isn’t going to make the cut. Or worse, they want what you’re working on — they just want someone else working on it. If your tasks get cut or reassigned, be a good sport about it. You’re a newbie at this and it’s not about you, it’s about the project’s success. (If this is a continual pattern, however, it’s probably a bad sign that you aren’t trusted to get things done.) Don’t sulk or mentally check out. Instead, gracefully take a back seat, watch and learn, and keep contributing however else you can.

Take heart that this happens to people many years ahead of you, too — senior-level people, even. Rather than delay a project until in-house staff can learn a skill, consultants who already have that skill often swoop in and cover that gap so the project can stay on track. Remember, it’s all about the outcome, and better to be a bit player for a successful project than be the star of a failed one.

10. Entry-level technical skills

The previous nine skills make you good at your job, and able to pivot from one technology to another. This skill set makes you good at doing the work itself.

The proof is out there

Begin investing in these skills now, and like a savings account, the interest will compound. Over the years, you will stand out more from those who chose not to invest. Don’t just take my word for it. The skills listed here will look familiar if you search for SQL Server jobs with the word “senior” in the title. Your skills will match the responsibilities employers are asking for right now. Seriously, these are plucked right out of current job listings for “Senior SQL Server [Something]”:

  • “Work with business users, management, and executives to analyze, define, and document business requirements for the company’s data needs.”
  • “Initiate discussions and advocate for a common approach to data management and data definitions for multiple business areas.”
  • “Coordinate implementations while maintaining a high level of accountability and transparency in order to safeguard the platform and customers.”
  • “Keeps abreast of evolving Database technologies and best practices and recommend improvements as appropriate.”
  • “Ability to manage development resources, assigning and reviewing tasks and providing timely status to management”
  • “Someone who enjoys trying new technologies and techniques, and has experience with high availability and disaster recovery techniques as well.”
  • “Stay current with Microsoft SQL Server tools and technologies.”
  • “Excellent written and verbal communication skills are required as well.”

Note that none of these requirements say anything about a particular version or feature of software. These are the requirements you’ll still see ten years from now. They are evergreen, and always in demand.

Aren’t tech skills important? Yes. Job listings have plenty of technical requirements, too. You want the tech skills to deliver great solutions. But technologies change. People change. You will likely pivot from one technology or product to another at some point in your career. You may get promoted to management and not be a hands-on DBA or developer anymore. These less-technical skills will serve you wherever you go. Your career is an interest-bearing account and the best time to start investing is now.

The Group In Which We Are The Norm

by

Early this year, I stumbled on to a blog post by author and speaker Simon Sinek. In his post entitled “Fitting In“, he writes about his experience at Comic Con — how it made him realize the lengths to which we’ll go to fit in, and why trying hard to fit in isn’t a good strategy. I read the post and right away began to think of how this relates to the SQL Server community.

The 2012 PASS Summit begins next week and if you’re a first-time attendee, it’ll probably be your first immersion into the SQL Community. You may find yourself trying to look or act a certain way to try to fit in. Don’t. Resist the urge, the fear that tells you you have to conform. Sinek says rather than working to fit into some group, work to find the group in which you already fit. Many people — myself included — have found that the SQL Server community is a group in which we already fit. We all love working with SQL Server and we love data. If we didn’t, we wouldn’t commit to 3-5 days of intense learning about it. We can reason therefore, the people you’ll meet next week are as serious and dedicated to their work as you are.

Of course, we have different interests outside of SQL Server, but when you find someone who shares one of those interests, it makes your common bond that much stronger. For example, I’m a fan of film scores and composers like Jerry Goldsmith, James Horner, and Michael Giacchino. It happens that Mike Fal (b | t) is also a fan of that same subject. Discussing film scores is how Mike and I became friends. Allen White (b | t) and I talk about show tunes, Jes Borland (b | t) and I talk about running, and Steve Jones (b | t) and I play baseball together. None of that would have happened if I didn’t put myself out there and share my outside interests with others.

(Also, there are a lot of people who like Star Trek.)

(You’ll see.)

I let some of my personality show at the Summit last year but still held back for fear of rejection or not fitting in. This year, I’m going to fearlessly be me and it’s going to be wonderful. I suggest you do the same. Be yourself. Be comfortable. This is, as Sinek says, the group in which you are the norm.

A Word About SQL Karaoke

From what I’ve seen, karaoke at the PASS Summit has blown up to a much bigger deal this year. If you’re a first-timer, you may wonder if the singing is competitive or only for the talented. It’s not. It’s just really fun and really popular. If you can’t carry a tune very well, don’t worry. Neither can I. Just enjoy yourself whether you decide to sing or not. That’s the whole point anyway.

See you in Seattle, my friends.

 

SQL Saturday #169 – What to do when it’s just you

by

Are you the only one doing what you do where you work? When people have technical questions — particularly about data — do they come to you and only you? When you’re stuck on a code or architecture issue, is it solely up to you to figure it out? If so, keep reading.

(If not, why not just keep reading anyway?)

It just feels that way sometimes.

I’ll be presenting at this weekend’s SQL Saturday here in Denver and in a refreshing break from the norm, I won’t be talking about Reporting Services. Instead, I’ll be leading a professional development panel discussion on surviving and thriving as the only technical resource at your company. I call it, “What To Do When It’s Just You.” I’ve spent the last eleven years as the only developer doing what I do. Along the way, I’ve learned better ways of managing time and expectations, solving problems, and recognizing when you’re going to burn out.

However, it won’t be just me giving my own advice on these topics. Also sharing their insight will be Carlos Bossy (t | b), independent BI consultant; Mike Fal (t | b), DBA and blogger; and Glenn Berry (t | b), SQL Server MVP and Principal Consultant at SQL Skills.

Carlos, Mike, Glenn, and I delivered this same session at the Denver SQL User Group meeting back in May.  Here are a few comments we got on our event forms:

“I almost feel like those guys could talk for the entire meeting and it would still be valuable.”

“Good insight into solo gigs. Great tips!”

“[This] presentation was one of the best the [Denver User] group has done.”

“Loved the discussion panel!”

If you haven’t signed up to attend SQL Saturday, there’s still time! If you’re already signed up, I hope to see you at our session.

Meme Monday: Working with Deadlines

by

In response to Tom LaRock’s Meme Monday, I’m writing about working with deadlines. I’m going to take the developer approach and talk in terms of new project deadlines.

My favorite approach to working with deadlines is to take control of the time. Deadlines are much like a line on a graph where time (the x-axis) and scope (the y-axis) intersect. Time and scope have a direct relationship — as scope increases, so does the time necessary to complete the items in the scope. Usually only one of the axes is negotiable. I’ve found the most common scenario to be, “We need a solution that can do this, this, and this. How long will that take?” Rarely have I heard the opposite, “We have this much time. What can we build in that window?” It’s up to me to answer how long the given feature set will take to build and deploy. In other words, I have control over time, not scope.

Before I go on, I must confess that even after years of software development, I am a dreadful estimator of project time. I often fail to consider adequately the interruptions and other projects that will forestall what I’m working on. It’s like the difference between the first time I played golf and the second: noticeable improvement but still horrendous.

My time estimates were totally unreliable until I picked up a book by Steve McConnell called Rapid Development: Taming Wild Software Schedules. In it, I found a truly golden section on time estimation that includes the following passage:

At the time when developers are typically asked to provide a rough estimate, there can be a factor-of-16 difference between high and low effort estimates. Even after requirements have been completed, you can only know the amount of effort needed to within about 50 percent, and by that time most organizations want their estimates to the dollar.

In other words, take your best guess of time, make 25% of that number your best-case scenario and make 400% your worst-case scenario. As you get further along in the project, you can refine your estimates down because there are fewer unknowns that can be introduced. Also, your estimates become more reliable as the project nears completion because people are reluctant to add/change features that will affect the deadline. If features are introduced later on, you can try to reject them citing the effect it would have on time. More likely, you’ll have to renegotiate the timeline (which I’ve found to be easier and more agreeable anyway). Another point mentioned in the passage above is that organizations typically expect far more precision that you are in a position to deliver at that time. If you relent and give a date certain when you yourself are not certain, you’re gambling you can come out on the low side of the estimate funnel, which if you subscribe to this process, gives you only a 50-50 chance of success.

Scotty in Star Trek IV: The Voyage Home (startrek.com)
"A deadline? How quaint."

If compelled to give a date certain, do yourself the favor of selecting the worst-case scenario at that time. In Star Trek III, Scotty confessed he did exactly that (multiplied his repair estimates by a factor of four) to keep up his reputation as a miracle worker.

The range estimate method has worked wonders for me. People understand there is uncertainty in the development process and actually appreciate that I don’t throw out a specific date haphazardly. Being honest about the variability of time required also frees me from the looming specter of a date I was never sold on in the first place. As the project progresses, I give updates with narrowing ranges, until the very end, when I can say we’re ready to go live with the project next Tuesday.

I highly recommend you give this method a try when time is negotiable. I’ve found it results in more realistic expectations and deadlines. By taking control of project time, you make uncertainty a natural and acceptable part of the process, rather than struggling futilely to eliminate it.

PASS Summit 2011 Recap: Super-sized!

by

Set the Wayback Machine

It was a year ago, October 2010, when I first decided I wanted to go to the PASS Summit. I asked for my company to cover the costs, and I was denied. I could hardly blame them – requesting $3000 on four weeks’ notice was asking a lot. Plus, I was hitting a rough patch with my job and not doing my best. So, from my desk at work, I watched the stream as Tina Turner kicked off day one of the Summit. I was bummed out.

But I was also motivated.

I made definite plans to alter the course of my career. I decided to take my career seriously by:

  1. Becoming a better student of SQL Server by learning more and getting certified.
  2. Getting into blogging and presenting.
  3. Going to PASS Summit 2011, with or without company support.

Over the next year, I made significant progress with the first two goals – I earned one MCTS and narrowly missed a second, blogged a little, and delivered five presentations.

When the call for speakers opened up for the 2011 Summit, a lot of prominent figures in the SQL community were encouraging people who had never submitted before to do so. I submitted four regular session abstracts for the Summit.

All four were rejected.

I took it the rejection hard because I didn’t get any reason aside from there were already enough Reporting Services sessions chosen. I got over it by the time another call for speakers came, this time for lightning talks (five-minute sessions). I submitted two abstracts. One was accepted (“The Two Most Powerful Properties for Dashboards”), and I was elated. I was going from a SQL nobody to a PASS Summit speaker in just one year.

SQL Saturday and the Portland 10k

Friday, October 7

I opted for the bonus size Summit experience this year: SQL Saturday in Portland, a 10k race, two pre-conferences, and the three-day conference.

At the Portland SQL Saturday speaker dinner, I was reunited with old friends Bill Fellows (t), Jes Borland (t), Buck Woody (t), Allen White (t), Tim Ford (t), Dev Nambi (t), Yanni (t) and John Robel, and Erin Stellato (t), among others. I got to meet Arnie Rowland (t) (great guy) for the first time and received a thoughtful speaker’s gift — a Logitech presentation remote.

I slept terribly that night.

Saturday, October 8

SQL Saturday. My session, “Developers are from Mars, Report Servers are from Venus” was scheduled in the best time slot: 10:15-11:30 (late enough that more people have trickled in, early enough that brains aren’t full yet and the audience can still focus). I had the pleasure of not only presenting to a mostly full room, but also having several SQL buddies in the audience. Kendra Little (t), Bill, Allen, and Jes got to see me present for the first time. The session went very well, although Bill had to prompt me kindly (and with the subtlety of a derailing train) to give away swag.

As the day went on, it became apparent that the air conditioning in the building was programmed to not run on the weekend. However, by the time I sat in on Jes’ Reporting Services session, the auditorium had become a sauna. In the last time slot of the day, I think I saw one attendee at Bill’s session finally ignite. Another may or may not have melted into the floor. I don’t really remember; it was so hot I may have hallucinated. (Note: Bill knows his stuff when it comes to SSIS. Some of what he presented, I heard repeated in other sessions at the Summit.)

After a brief stay at the after-party, I headed back to the hotel to get a good night’s sleep for the big day ahead. I didn’t sleep well.

Sunday, October 9

On a cold, slightly drizzly morning, I jogged over to catch the charter bus to the 10k start. Our registration e-mail said there’d be a bag pickup. At the starting line, we were told there was not a bag pickup. Enough icy stares from the athletes prompted the race director to hastily create a bag pickup.

For this race, I had trained consistently, at altitude, for about eight weeks. I trained at a 7:00/mile pace but considered that to be wishful thinking. A 7:30/mile pace seemed more realistic.

I focused on staying close to a guy who resembled a hardcore Kenyan speedster. After the first 300 meters, I passed him and never saw him again (so much for appearances). I ran the first mile in 7:00. Fast, I thought, but I knew it was probably adrenaline-fueled and I should expect to slow down. The second mile was mostly downhill and when Runmeter told me I’d done it in 6:27, I was not really surprised. By the end of five miles, I was feeling the hurt. It helped that the final 1.2 miles tracked past a cheering crowd. I kicked with about 200 meters to go and finished in 43:34, a 7:02 split.

I ran and skied cross-country in high school. I used an old trick from my racing days to my advantage on Sunday: tangents. By anticipating curves in the course and running the tangent lines, you can shave off waste distance from the course. Based on Runmeter’s stats, I sliced sixty meters off the course by running in long, straight lines. I don’t care if I’m not young anymore as long as I’m still crafty.

With a handful of other SQL runners, I took the Amtrak line to Seattle (I highly recommend it — way less fuss and more comfort than air travel. Bottles over 3.5 ounces are not hunted like fugitives by TSA agents and legroom is not measured for reasonableness using pygmies as a standard)

Bill and I checked into the Sheraton, and promptly went to bed.

(Went to sleep in our respective beds, that is.)

Probably due to excitement about the week ahead, I slept badly.

PASS Summit Pre-Conferences

Monday, October 10

Upon waking, my first thought Monday morning was, “Holy S#!t, I’m actually at the Summit!”

I went to the pre-con, “A Day of SSIS in the Enterprise” presented by Andy Leonard (t), Matt Masson (t), and Tim Mitchell (t). Of all the presentations I have seen in the last year, this was the gold medalist for both execution and content. I got more ready-to-implement ideas and advice from this session than from all the others I attended at the summit combined. It was that good. (Once more for the Program Committee: it was that good.)

I was especially impressed by how the three presenters handled questions. One would give an answer, then another would add a thought to it, then the third presenter would wrap up the answer with their own insight. When they disagreed with each other on a design choice (e.g, file system vs. SQL Server storage for packages) they stated their respective cases. As a result, the audience was treated to multiple points of view on many issues that SSIS developers confront.

I wouldn’t ordinarily comment on lunch — conference food is remarkably unremarkable — except that lunch on this day was incomplete. Somehow, the caterer for Monday’s lunch ran out of chicken. That’s not a big deal, unless there’s no other meat alternative, which there was not. Curry tofu (think stale marshmallows hit with pepper spray from across the room) was the only other meat-like item. Lesson for the day: don’t wait until the fifty-fifth minute of a sixty-minute lunch to go get food, or just eat out.

In the evening, I went to the party at Lowell’s hosted by Steve Jones (t) and Andy Warren (t). I met a lot of new faces there and caught up with more acquaintances, including several SQL Cruisers. I got there early enough that I scored a free dinner, which was positively delicious. Later, it was off to Bush Garden for karaoke night. I sang “One Week” by Barenaked Ladies — my anchor song — and “Only the Good Die Young”, which was awful. On the way back downtown, Jason Strate (t) walked through a foot-deep fountain, to no one’s surprise.

I got back to the hotel around 2:30 a.m. and attempted to sleep. Generally speaking, I failed.

Tuesday, October 11

It started to catch up with me that I hadn’t slept a lot the last few days. It didn’t help that I was signed up for a second pre-con, Stacia Misner’s (t) session “MDX, DAX, and DMX: An Introduction to the Languages of BI.” I didn’t get as much value out of this session for a few reasons:

  1. Exhaustion was beginning to take a toll on me.
  2. The session was heavily weighted toward MDX (about six and a half hour’s time) and I was more interested in DAX (one hour’s time).
  3. I just don’t learn as well if I’m looking at code in SSMS. I do better with demos or slides.

Just the same, I’m eager to see another of Stacia’s sessions. This one ended up being a little light on DAX and MDX, that’s all.

Welcome Reception

I’ve heard PASS is trying to make the first-timer’s experience a more inclusive and more appreciated one. One thing they did was pretty special in that regard.
Although I didn’t participate in the networking or big brother/sister events for first-timers, I went to the conference center for the welcome reception. While standing outside the ballroom chatting with friends, I ended up getting herded into a large conference room adjacent to the ballroom. We all stood around, lined up in front of a doorway, awaiting instructions and knowing something was up. The screen at the front of our room lit up with the image of Rushabh Mehta (t) on stage. He welcomed the crowd, then spoke about how exciting it was to have so many first-timers in attendance this year. With that, doors opened in front of us and we entered the ballroom to a Super Bowl-like introduction: stage lights, fog machines, and a crowd lined up along the red carpet. I loved the entrance and the feeling of being a superstar, if only for about eight or nine seconds. Well done, PASS.

The rest of the night in short:

  • Red Gate/SQL Server Central casino and award party for Jeff Moden, Exceptional DBA for 2011.
  • More karaoke at Bush Garden – lots of locals in the bar so a lot more songs in the queue. I murdered ELO’s “Mr. Blue Sky”. Mark Vaillancourt (t) learned the hard way to never sing “White Christmas” – it repeats. And repeats. And repeats.

I finally got a passable night of sleep.

Wednesday, October 12

Finally, my first SQL Run. Bill and I got down there just as the crowd was leaving. I was pleasantly surprised at the size of the group — close to forty runners. I hope this tradition keeps up, and I hope I’m not so sacked next time around.

I was fortunate to be given a spot at the blogger’s table for Friday, and an invite to sit in the reserved section directly in front of them on Wednesday and Thursday. The Wednesday keynote was going along well enough until…Contoso Frozen Yogurt.

The Blogger's Table at the 2011 PASS Summit
Yogurt jokes at the ready.

I had held back mocking any of the BI enhancements until they stated that according to their data, “Kids love frozen yogurt.” I won’t repeat the tweets here, but the blogger section had a lot to add with tweets about Dateline’s “To Catch a Predator” and “FREE YOGURT” spray-painted on the side of a van. Lesson for Microsoft: run your demos by someone who can tell you if they’re ripe for mockery.

After the keynote, I couldn’t fight it any longer — I went back to the hotel and took a nap. If the lesson isn’t obvious by now, I’ll state it: pace yourself at the Summit.

Jessica Moss’s (t) HIPAA session was great, except when my phone rang out loud. (If you own an iPhone 3G or 3GS, the ringer toggle sticks out far enough that a shift in your pocket can switch it back on, which is how I got burned.) It wrapped up in just under an hour, so I headed over to catch the end of Jes Borland’s talk. Based on what little I saw of that session, she handled her first PASS Summit presentation with ease. Keep your eye on Jes, people. She’s a SQL superstar in the making.

The remainder of the day:

  • Bradley Ball’s (t) excellent lightning talk incorporating the show “24”
  • SQL Cruise meetup & thank yous to sponsors
  • Speaker appreciation party
  • Bush Garden – “One Week”, “Amish Paradise”

Thursday, October 13

A better opening presentation this time, followed by an outstanding Matt Masson session on what’s new for SSIS in SQL Server 2012. Before Monday, I hadn’t heard Matt Masson present. In fact, I hadn’t heard of Matt Masson at all. Matt is now on my list of must-see speakers. An illustration why: when I walked into the room, he was killing time before the session demonstrating how he could use SSIS to separate his Facebook friends from his frenemies, who were — as he put it — all plotting against him. He’s very funny and very sharp.

Later, during this session, a most incredible opportunity presented itself to me.

I was watching Twitter and posting useful tidbits from the session when, around 11:00, I saw Allen Kinsel (t) trying to fill in a last-minute cancellation for 1:30. I’ll let my Tweetdeck stream tell the rest of the story (note: tweets show MST, so subtract one hour for Seattle time).

That’s right, I jumped in and gave a regular session with less than two hours to prepare it.

In fairness, I should mention a few facts:

  • The session I gave was one I’d given five times before, including SQL Saturday just five days earlier. I had already put about seventy hours of development and rehearsal time into it.
  • Like less experienced musicians performing an adagio piece, I rushed.
  • I got a mere one or two questions during the session, so I finished in only forty minutes. I was slotted for seventy-five minutes. I ended up answering questions for another fifteen minutes afterward.

I spent the two hours’ prep time re-styling the deck — all eighty-eight slides — to the PASS Summit template, changing white text to black, and adding zoomed-in screen shots to account for the depth of the room. I also spent that two hours trying to prevent my heart from launching out of my chest cavity.

It was a thrilling, terrifying, and euphoric experience being up on that stage. I had wanted achingly for months to give a full session at the Summit and because I recognized I was at the intersection of opportunity, preparation, and damned good luck, I did it.

My view from on stage
Terror at 36,000 x 10^-4 Feet!

That night, my body began to revolt against its perpetual tiredness. I had dinner at Elliott’s with the Denver SQL User Group. I was happy to see we had over thirty people turn out — a healthy gain over last year’s ten or so, from what I heard. I stopped by my hotel lobby and had a long and thoroughly enjoyable chat about politics with Mike Walsh (t), who was very civil and open-minded.

As I went to bed, I reflected not only on the speaking experience, but also on how supportive my SQL Server colleagues — my friends, really — were in helping me get that session not only noticed and accepted, but also filled with attendees. Take another look at the Twitter stream above. The longest I have known anyone in that stream is eight months, and yet they all were publicly pulling for me to succeed.

Truly, this is community.

Friday, October 14

Honestly, the rest of my 2011 PASS Summit was a blur. Dr. Dewitt’s keynote on the worlds of structured and unstructured data helped me, and I suspect a lot of others, understand what’s going on on the other side of the data fence, and how we shouldn’t ignore the importance and interconnectedness of our collective backyards.

The lightning talk went well, though again, I rushed. I talked about how framing matters with dashboards, using signed photos of donkeys as examples. (The photos were not signed by the donkeys themselves — that’s ridiculous.) Once my lightning talk session was over, I said my goodbyes, rolled my suitcase onto the light rail, and flew back to Denver completely wiped out.

What I Learned

For my presentations, I have a lot of useful feedback to learn from. I intend to put it to good use and improve on my performance as a speaker. I have feedback to share with you as well: some suggestions for the Summit that I learned from this year’s event.

Do:

  • Pace yourself. Get enough sleep early in the week so you aren’t dragging come Friday.
  • Bring business cards with your Twitter handle on them. If you don’t have a Twitter account, get one and get active with the SQL community.
  • Use a real portrait photo of you as your Twitter avatar. You’ll be more memorable to others.
  • Go out for lunch somewhere unique to the host city. Let’s be honest, convention food has a low ceiling for taste. In Seattle, there’s fresh seafood all around and it’s gooooood. Go get some.
  • Attend as many off-hours activities as you can handle. This is where friendships are forged. Whether it’s a morning jog, morning prayer, or (technically speaking) morning karaoke, people want to connect with you through these activities.
  • Stay in a hotel a reasonable walk from the convention center. Being able to get back to your room quickly and ditch your swag/change clothes/take a nap frees up more time for the fun stuff. Plus, a lot of people hang out in the lobby or the bar. You want that to be your lobby, your bar.
  • Bring a power strip with a long cord. Six feet is okay, twelve feet is fabulous. Outlets can be a long way from where you end up sitting. One of the recommendations for next year is to have power strips for pre-con attendees. That’s great, but how will you stay juiced during the actual conference? You’ll need a power strip with a long reach, so come prepared.
  • If you want to present a regular session but aren’t an official alternate, be an unofficial alternate. I was amazed to hear how quickly PASS burned through their alternates. As a lightning talk speaker, I had access to the PowerPoint template. I could have styled my presentation ahead of time and used the prep time that day to rehearse. Next year, if I’m a speaker I’ll have a second deck ready and styled. You should too. Even without the official template, you can still make sure your deck and demos are ready for a large room and audience with ZoomIt or zoomed-in screenshots.
  • Buy the DVDs. You can’t be everywhere and see every session. Or can you? You can, and for the bargain price of $125 + shipping and handling. ORDER NOW! (Update: the $125 price was valid until the end of the Summit. The current price for attendees is $195 — a great deal just the same.)

Don’t:

  • Bring dress clothes, unless you have a specific reason. I wasted baggage mass on a nice shirt, pants, and dress shoes. You’ll be on your feet so much, you’ll want good walking or running shoes to keep your feet happy. Also, the Summit is CBC on the dress compass: casual-business-casual, close to due casual.
  • Spend any time in your hotel room unless it’s transition time or you need a nap/shower. Unless there’s a networking event going on in your room, all the action is going on somewhere else. Use your hotel room for sleep and refreshing.
  • Forget to turn your phone off before a session begins. Don’t rely on a mute switch — turn the ringer volume down to zero instead. That way if the switch flips accidentally, the ring still won’t be audible. If you leave your phone on, or worse yet — answer it, the audience will judge you. Oh, how they will judge you.
  • Feel like you have to attend a session in every time slot. Your brain will start overflowing mid-day Thursday if you’ve been pouring session after session into it. Skip one slot here or there and go talk with other people, see the vendor exhibits, or reflect on what you’ve learned so far. Buy the DVD’s if you’re afraid of missing out on something. (Remember, I told you to ORDER NOW!)

In closing, I’m grateful, truly grateful for the adventure I had at this year’s PASS Summit and to the people who helped it unfold as it did. I got to reconnect with old friends, make a lot of new ones, and scratch the year-long itch to be at the world’s largest and greatest SQL Server conference. I got the opportunity to present twice (which I have to believe is an extremely unusual occurrence for a first-timer), and enjoyed every second of it. I can’t wait for the next adventure to begin.