Total Recall

This is the final entry in my #SQLNewBlogger challenge. You can read the previous entries here:

Part 1: The Intersection of Art and Science
Part 2: The Art of Improvisation
Part 3: What Motivates You?

One of the biggest challenges in an actor’s life is learning lines. Only some actors are good at it (I am not one of them), thus many techniques exist to assist them to memorise words created by someone else.

In 2006, while working on a 150-day project to migrate a bank’s management reporting systems (or “Business Intelligence”, as the cool kids were calling it) from SQL Server 2000 to 2005, we had to learn a lot of new ways to do things.

Microsoft has been good to us by including a lot of features and behaviours to maintain backward compatibility, but in most cases, it is a good idea to learn the new ways. This also helps you on your career to becoming a Senior DBA. It all comes down to continually learning new stuff, to remain skilled and relevant.

During the course of that 150-day project, I arrived at work one morning, had my coffee from the company canteen with the team, and then sat at my desk to write some T-SQL. I realised I could not remember the ALTER keyword.

Not only had I forgotten the ALTER keyword, but I also could not remember how to look for it. As I recall, eventually I right-clicked on a stored procedure and chose “Modify”. It was the longest ten seconds of my life.

I have never forgotten that keyword since. And why would I? It was a curious moment in my already established career working with SQL Server.

As an actor, I’ve never been good at learning lines quickly. It is why I was replaced, in junior primary, as a lead in the school play. More recently, shooting a television commercial, we had to do sixteen takes to get my lines correct on film. Even then, the director made me do pick-ups afterwards just in case.

One particularly memorable play I was in, had a tricky script where the character’s lines would repeat. Naturally, during opening night in front of a paying audience, I got stuck in a loop and could not for the life of me remember the right exit line.

Just as I was beginning to panic, Eskom, South Africa’s now-famous-for-the-wrong-reasons electrical supplier, decided to cut power in the general vicinity of the community hall in which the play was being performed.

Unlike in 2015, where they now have backup generators and the show must go on, we refunded the tickets, asked everyone to come back for the following performance, and I was comfortably able to get through that section when we did the play again. It was the longest week of my life.

The only way for me to get my lines down is to practise them, over and over again. I recently learned a new technique, based in immersive scene study, to predict the shape or idea of the lines, and that helps.

But as with working in the SQL Server sphere, or anything else in life for that matter, if you do not practise, and don’t do the work, you will forget, no matter how good your memory is.

Just as I did with the ALTER keyword and the psychotic play, make sure you have a fallback plan. I don’t mean for you to sabotage the electrical grid or kick out the power cable from your server. I want you to keep in mind that there is something beyond Books Online or MSDN. I’m talking about Twitter, and specifically #sqlhelp.

A community of people exists to help you do better. That is why #SQLNewBlogger even exists. We are in this together. The SQL Family sticks together. Join up with Twitter if you have not already, and start interacting with the community.

Visit a user group in your area, or start one if it does not exist. Attend a SQLSaturday (they are free!). Volunteer at a SQLSaturday event. If you have the resources available, attend the annual SQL PASS Summit and network with other like-minded folks. Participate and learn. Keep your skills sharp, and share your knowledge with other community members. Every bit counts.

(In memory of Larry Toothman, a.k.a. @IowaTechBear.)

What motivates you?

In this, the third part of my series on the intersection of art and science, I hit that crossroad. I can cross over into the creative, art side, where this post has been written, or I can stay on this, the science side, where I have maintenance tasks to run.

Both have to be done. Both can be done in any order. So what motivates me to write the words that create what you, dear reader, will be reading in the future?

Over the Easter weekend, I participated in a 48-hour Movie Making challenge. The premise is simple: each team has just two days and nights to throw together a short film from between two and five minutes in length. That means everything from the pitch to editing and everything in between. I was originally invited to direct the film, but we decided that I was not experienced enough to do it.

Instead, I just acted. There was a lot of sitting around waiting for the talented crew to make us actors look amazing. We need that much help to look good.

With all that sitting around, finding your motivation is important to give you a base on which to build the actions (and more importantly, reactions) for the audience to believe you. There are multiple camera angles, and in each one you have to provide the same performance, or it screws up continuity, making the editor’s job incredibly hard.

Many actors are typecast. The Femme Fatale. The Action Hero. The Romantic Lead. The Goofy Sidekick. It becomes understandable when you realise how hard it is to find your character at the end of a very long shoot. If you get bored, you will ruin your performance.

Acting becomes very much about projecting yourself on screen. That projection of yourself becomes your “type”, and so you get typecast. I will forever be the goofy sidekick, because that’s how I play on the screen and on stage. My character’s motivation is easier to find that way.

Motivating myself to perform maintenance tasks on the other hand, is less fun. I believe we have checklists and documentation precisely for this reason: if you’re bored or lose concentration for a second, you’ll break something, or even worse, cause data loss.

I leave you for another week with the question: what motivates you?

The Art of Improvisation

This is the second post in my four part series for the #SQLNewBlogger Challenge. You can read the first part here.

On Saturday, 28 March 2015, I moved three servers and various networking equipment from an old custom server cabinet, made of wood with a steel door and plywood backing, to a brand new steel APC 42U rack with appropriate door, panels and mounting screws.

For a change, very little blood was spilled, and my right hand only cramped up afterwards.

Working with hardware like this reminds me that there is so much more to Information Technology than software. It is literally the T in IT.

This is also the part of IT that never goes according to plan. You design your infrastructure diagramme, where each device and server will go; you mount the rails, the shelves and patch panel; you get new patch leads to run to the switches; you ensure it all follows good practice.

And then as you go along, you realise that the switches do not have front-mounting brackets because the client threw them away, so your first plan goes out the window, and you improvise. Now that shelf has to move up, and the monitor and keyboard will have to make do on the half-length shelf, installed upside down to leverage the lip to keep them from falling off. The fiber cable was installed sideways into its box, so rack-mounting it is impossible. The additional power strip was using an extension lead which is a big no-no. The labelling of hardware was missing or incorrect.

Improv: not just for actors.

Physically moving equipment is a very risky proposition on a good day. Everything must be unplugged, which is fraught with issues relating to power surges: hard drives fail, switches blow up, and firewalls give up the magic smoke. None of it is good. There is also the risk of bumping or dropping several thousand dollars’ worth of server (which I have done in the past).

All this is to say that there is a lot going on and only a short amount of time in which to do it. We had a window of nine hours and we finished with fifteen minutes to spare. There was no lunch break. Things came up that were unexpected or downright broken, and we had to improvise.

I respect and admire the women and men who work behind the scenes, who build servers and configure networks and run cables and wire up data centres and make sure the infrastructure is sound. These are unsung heroes in our field and ought to be recognised. They are improvising all the time.

It takes dropping a screwdriver on to a server during a shelf installation that reminds you of what is important about this gig: all of it. Every component is equally important. Just ask the disaster recovery experts out there.

Hug your hardware technician next time you see him. Thank your network cabler next time she has to run CAT-5e so that you can run the newest software that will be obsolete next Tuesday.

If you are ever feeling cocky and need a reality check, unplug all of your equipment, untangle all the wires, and plug everything back in again.

When it does not work the first time, learn to improvise. You will be grateful you tried, because when you have to recover from a catastrophic failure, improvisation is one of your critical skills.

Stay tuned for my next piece in this series.

The Intersection of Art and Science

This is the first post in a series of four, where Ed Leighton-Dick, via Brent Ozar, is proposing that we SQL Server folks participate in the #SQLNewBlogger Challenge.

I write a fair number of words on my personal website, and tend to neglect this site. Reading Brent’s post, it occurred to me that I can draw lines of parallel between my personal life and my SQL Server life, through this short series.

Those who follow my antics on social media know that I have recently begun dabbling in the professional arts, and specifically on-camera work. In fact, I just wrapped on a short film that makes its debut on 19 April 2015.

By definition, I am an out-of-work actor who moonlights as a database consultant. It just so happens that I can make n-times more as a database consultant than a professional actor, with n trending towards infinity.

So why act? Why go through the bother of learning those skills, the hell of auditions, the challenge of learning lines and not spiking the camera, for little to no work, and no money at all?

Steve Jobs famously spoke of the intersection between technology and the humanities, or put more simply, the intersection of art and science.

Microsoft SQL Server is a great example of science. At the PASS Summit last year, I had the privilege of listening to, and even talking with, people like Dr Rimma Nehme, Conor Cunningham, Kimberly Tripp, Bob Ward, Gail Shaw, Paul Randal and other equally magnificent technologists and computer scientists from all over the world.

And yet, how do we answer questions when asked how to do something in our very scientific field?

“It depends.”

That is the very definition of art. Somehow, when faced with expensive, extremely complex technology, based on scientific and mathematic absolutes, we just shrug and say those two words.

It is then followed by an in-depth technical explanation of the pros and cons of each option, where we swing back to science again.

But even so-called simple things like index management require strategies. That implies a degree of planned uncertainty.

We get to be artists.

To answer my own question of “Why?”, I act, write and direct because I love it, and have loved it, since I was in my first school production in the mid-1980s.

I find learning lines incredibly difficult. I shake like a leaf when I audition, to the point where I cannot hold anything in my hands. I have one or two minutes to deliver a rehearsed scene in front of a director or camera without making eye contact.

If I am auditioning for theatre, I have to act “bigger”. On camera, it’s “smaller”. It’s all about time limits, it’s about making choices that are in the moment. I would not trade that feeling of trepidation and inadequacy for anything, because the pay-off is so magnificent.

Sit me down in front of a SQL Server instance, and I am calmer than you can imagine, because the very last thing I want to do is make a choice in the moment. I have as much time as I like to investigate, to draw conclusions, to ask people if necessary, and then plan a series of steps to test, test and test again, to make sure the result is what is needed.

That is what prepares you for that emergency, where the CPU graph is at 100% on all 16 cores, the storage subsystem has 6,000ms latency, database connections are being dropped, no one can connect, and the CEO is glaring at the screen over your shoulder, asking when you will be done.

I would not trade that for anything in the world, either. The pay-off of query tuning, of improving the storage layer so that people can get their work done faster and more efficiently, is magnificent.

The two worlds are diametrically opposed on the face of it. Yet, one has prepared me for the other. I do not relish being in those stressful situations, but I do know how to act in the face of intense pressure.

Thus ends my writing drought for now. Come by next week and read some more.