A look back, and a look forward

Time flies. My father used to wear a t-shirt that claimed, “When you’re over the hill, you pick up speed.”

I’m turning 40 in a few days. I still feel like a teenager in many respects.

SQL Server, released in 1989, is 27 years old now. It’s about the same age I was when a career change became necessary. I became a lecturer, briefly, then a high school teacher, and a tutor on the side, sharing my knowledge, all the while learning how people learn.

Combined with my so-called “train the trainer” learning a decade prior in college and the help desk support job from around the same time, it allowed me to unlock ways to explain technology to people. In so doing, I realised that I had a real arrogance about technology. Whereas I wanted people to bend to its ways, I realised that it was technology that had to adapt. Now when I build products, the aim is to be as simple as possible.

When I went back into the tech world after teaching (for money, as it turns out—it’s always about the money), I tried to keep this new perspective. We need to review our thinking and assumptions more often than we do.

SQL Server, and Azure’s Platform as a Service, have come a long way in a relatively short amount of time. Things we had to worry about as little as four years ago are being made much easier by the newest versions. Self-tuning databases, the Query Store, In-Memory OLTP, and recent changes to SQL Server 2016’s Service Pack 1 are all things Microsoft has learned and borrowed from competitors and customers alike, to produce probably the best relational database engine currently on the market.

Microsoft challenged their own assumptions. The market required it. Five years ago it was unheard of, the thought of Azure hosting Linux and Windows equally, with NoSQLs and Red Hats and Oracles and SAP HANAs, oh my! We even have Linux on SQL Server now. I still don’t know what it’s for, but it’s really very clever how they did it.

(Full disclosure: I didn’t know what cameras on phones were for, either.)

I’m a technology Luddite. I literally break technology more often than I care to admit, though admittedly not because I think it’s taking my job. I call myself a living edge case and a human beta tester. It’s usually accidental, but if something is going to break, it’ll break around me.

As a result, while I tend to have the latest shiny computers and electronics, I write my important notes in a Moleskine notebook I carry with me. It was a gift from my spouse and has Smaug on the cover. It has no lines on the pages, because sometimes I need to sketch things in meetings. I prefer a resilient hard copy any day of the week, and flipping back the pages of the book has a certain feeling that technology can’t touch.

When SQL Server 2000 was released, Microsoft’s marketing claimed that the database server could look after itself. Of course this turned out to be false, and I was still working with 2000-era databases until quite recently. Marketing played nicely into my bank account, thank you.

However, the trend towards not having to manage databases is continuing apace. Azure SQL Database takes much of the administrative burden away so that most people who need a database can get one easily, without concerning themselves about maintenance tasks and how the data drive was formatted. Technology is getting better. It is adapting better to people.

Looking back on 2016, I recognize my only fondness for past eras of computing is borne by nostalgia. SQL Server 2016 is the best version of the stand-alone product. Azure SQL Database keeps getting new features so frequently that it obsoletes my blog posts, sometimes only days later.

I am looking forward to the new challenges this brings. I feel overwhelmed sometimes, but I know I’m not alone. There will always be performance issues, and database corruption, and customers not taking or testing their backups. I’ll find a gap there, and as for all the other stuff, I’ll keep learning.

If you would like to chat about this some more, feel free to contact me. I’ve taken a break on Twitter, but you can find me there at @bornsql , and I respond to direct messages.

SQL Saturday in Calgary!

I am very happy (and terrified) to announce that Calgary will host its very first SQL Saturday, #607, on 29 April 2017.

Noel Tan and I are organising it (though Noel is doing all the hard work), and my company is sponsoring the main prize, a Microsoft Surface Pro 4.

I would like to invite all my readers to attend this event, and if you are in the general vicinity of Alberta and can take the week off to also attend Edmonton’s own SQL Saturday a week prior to ours, on 22 April 2017.

It’s a comfortable drive from Edmonton to Calgary, and you can take in many sights, sounds and tastes over that week. Both Calgary and Edmonton have international airports only 30 minutes from their respective city centres.

Speakers are welcome to apply. We already have interest from Canada, USA, and Australia. You can speak on any number of topics, including Azure SQL Database, SQL Server on Linux, Best Practices, SQL Server 2016, and so on.

To register to attend, speak, or sponsor the event, visit the official Calgary SQL Saturday website (http://www.sqlsaturday.com/607/) by visiting and clicking on the Register Now button. We will be Event #607.

To stay abreast of what’s happening in the lead up to this event, you can also watch the #sqlsatcalgary and #sqlsat607 hashtags on Twitter.

If you would like to know more, find me on Twitter as well, at @bornsql .

Interview Questions for a SQL Server DBA

When I’m interviewing a SQL Server DBA, I have three questions that I always ask.

My favourite interview question is this:

“What is the difference between a clustered and a non-clustered index?”

My second favourite question is this:

“What is the right disaster recovery strategy for my company?”

The first question is one of basic understanding. Depending on their work experience, the candidate may have an inkling about why such a distinction matters, and this lets me know how much I have to teach. What it does not do is disqualify them. I am not averse to teaching, which is why I write on this website in the first place.

The second question should be answered with “it depends”, followed by the candidate asking me questions about my company so that they can figure out a way to begin answering it. If the candidate blurts out an answer without asking questions, well, their résumé goes in the garbage. This is the disqualification question.

I’m mostly self-taught, with formal training to fill in the gaps much later in my career, so I know the difference between “I know this thing, but not the textbook definition”, and “I read this somewhere on Google and have never used it”.

If the candidate uses words that are blatantly wrong but have the right idea (“the blob is sorted on the disk, but the non-blob one is a copy of the blob, but smaller, because you can only have one blob, and it’s shaped like a Christmas tree”), then that’s a pass for me. SQL Server doesn’t care how you describe an index to an interviewer, as long as the syntax is correct, and that’s what Books Online is for.

Heck, I might even say “if you can’t explain it with words, draw it for me on the board”. I love pictures. I’ve drawn many lopsided databases in my time. That’s what the dry-erase board is for: working through a problem that exists in the real world. It’s not there to make someone regurgitate a textbook definition. Again, that’s what Books Online is for.

Here’s a practical example from my school days, as a student and as a teacher: the notorious open-book exam.

In this scenario, the exam taker is allowed to refer freely to their textbook throughout the exam, and the invigilator is there to make sure no one is distracting their fellow students.

The open book exam relies on the exam takers having a working knowledge of their subject. In the case of English literature, for example, it helps to have read the book. Summarised study guides only get you so far — if I’m asking why the love between Catherine and Heathcliff can be described as “demonic”, providing examples from the text, you would have to know where to look.

Even so, the open book exam is unfair for those people who haven’t read the book but have seen the movie ten times and can quote their favourite lines from it. Or if they prefer the audio book, because they struggle to read words on a page, especially under stressful situations. Or their parents read the story to them many times in their youth. Or English isn’t their first language. Or their second language.

If you have haven’t read the book, you will run out of time to answer the questions, because you’ll be frantically reading the textbook for the first time, trying to understand why anyone wants to know what a linked list is for (a very typical interview question for software developers). Meanwhile, you’ve used linked lists before in that job you had writing code for your cousin’s bicycle store, but you didn’t realise that was their actual name.

If I’m asking you, with only a few years of experience administering an Access database for your uncle’s grocery store, to create an index in SQL Server, without using the graphical interface of Management Studio, the first place you’re going to look is Books Online.

As my friend Gail Shaw (b | t) once said many years ago, when you are working on a SQL Server database, you should have two windows open, and one of them is Books Online. Why guess arcane syntax when you can simply look it up?

Which brings me to my third favourite question:

“What was the last mistake you made, and how did you recover from it?”

I’ll go first.

This morning I was working on a stored procedure for a new system. The code called for an upsert-style stored procedure (INSERT and UPDATE in one block of code, to check for the existence of a row of data in order to update it, or insert it if it doesn’t exist). My UPDATE statement was missing a WHERE clause.

Fortunately, the tools that I have at my disposal managed to catch this before the code was ever run. My point is, even with decades of experience, and being able to recite all of the keywords in an UPDATE statement, even the most battle-tested person forgets a WHERE clause once in a while and updates or deletes the entire table.

This is why I love my second favourite interview question, because I get to ask the candidate this bonus question:

“Does the disaster recovery strategy you came up with in question 2 cater for the scenario you just described?”

After all, backups matter only if you can restore them promptly and accurately.

Final Thought

This discussion has made a resurgence thanks to my friend Janie Clayton, who has posited (in my interpretation anyway) that technical interviews are designed to exclude certain people from applying for a position, for arbitrary reasons (university degree, culture, gender, language, etc.), for the sake of some puritanical ideal.

My take is obvious: If you have working knowledge that you can demonstrate, and some experience, you can learn the rest on the job. Every system is different, with different goals guiding a decision. It takes time to become accustomed to a new system, and even the smartest person in the room will have to ask questions.

The question is not “what have you memorised?”, but “what can you learn?”.

By all means, if you’re applying for a specialised role (for instance, performance tuning), then you need to have specialised domain knowledge. For everything else*, there’s Books Online.

* MasterCard did not pay for this post.

Automation is the new Black

I’ve been toying with the idea of automating a set of diagnostic scripts that I run on customer sites, when doing my checkup. It mirrors the automation that a lot of consulting shops do, but when I run them, I like to spend more time with the customer explaining what each script does and why it only forms a small part of a big picture.

That way, when I present my findings, a lot of the key points have already been covered, and it’s extremely effective (and comforting) to see a customer understand instantly what I’m referring to and ask questions relating directly to that issue.

Although I call that “face time”, it’s more accurately described as “side time” because the customer is sitting beside me, watching me run scripts and dump the results into Excel, talking a lot, speaking with my hands, and so on. Numbers start to blur and they stop caring about what is obviously a very important problem if I’m being paid to figure it out.

It does get a bit overwhelming for the customer, though, especially if they aren’t technically inclined. This is obviously not an efficient use of our time.

So I’m changing things up a little from my side. I’ve figured out how to automate the diagnostics in such a way that I can let them run for about 15 minutes in total (automation means I don’t have to run them in sequence, I can run them all at the same time with a random delay), and once they’re done, produce what is effectively a highlight reel.

Then I can use the rest of the hour to go through these results and explain, using graphs if necessary, the most interesting things I can see. Normally the customer has to wait as long as a day until I produce a 16- to 20-page document, but this way they can see things almost instantly, and if there’s something important to discuss, we can do it immediately.

My consulting style is very conversational (much like this blog), because I want my customer to understand, if not in the same detail as I do (though a significant percentage do), at least what to look for when troubleshooting performance problems and identifying issues with maintenance and disaster recovery planning.

For competitive reasons I can’t disclose my full methodology (I still have to eat!), but I thought I would share some consulting mindshare for a change.

Career Limiting Moves – Reply All

In a recent episode of a Netflix show called Grace & Frankie, a vitriolic and profanity-ridden email with very damaging statements was accidentally sent to a mailing list.

Fortunately for the characters involved, Siri auto-corrected most of the really bad stuff, and Vin Diesel became an unwitting participant in the storyline.

Unfortunately, there’s real life, and in real life I’m sure we all have stories where we hit Reply All in our email unintentionally, with detrimental effects.

Instead of telling you my own story here, I’d like to hear from you, either in the comments or on Twitter (@bornsql). What was your worst Reply All incident?

Career Limiting Moves – Assigning Blame

I worked for a vendor implementation partner in the early part of my career, and oftentimes that meant having to set up a training lab, from unpacking rented PCs and plugging them in to getting a full training environment installed and configured.

This included the operating system (usually Windows NT 4 Workstation or Windows 98), installing all Windows Updates, and Microsoft Office, plus the vendor’s training software. It was easily a four- to six-hour long process per PC, though of course I could parallelise my tasks and set them up at roughly the same time.

One Friday, I was asked to go into the office over the weekend to make sure that around ten machines were ready for a Monday morning training session.

I asked that the PCs be installed with the operating system and Microsoft Office before I got there on Sunday because it would be quite time consuming to do everything from scratch. The person I asked said that they would be done on Saturday, so that I could go in on Sunday and at least enjoy half of my weekend.

Sunday rolled around and in I went, only to find that the PCs were still in their boxes. I was furious, so I phoned a colleague who worked for the vendor to find out why it hadn’t been done. The call went to voice mail, so she had an excellent quality recording, of me saying I was having to work the entire day on Sunday “to fix [redacted]’s f**ckup”.

Classy, right?

On Monday, the boss called me in. This was the managing director, not my immediate boss.

She proceeded to quote back to me my voice message verbatim. While surprised that my colleague had ratted me out, I of course was still upset and suggested that the person didn’t do their job and I was left to sort it out.

She explained to me that whether or not that was the case, the language was totally inappropriate and calling a vendor on the weekend for something that did not constitute an emergency was unprofessional. In any number of scenarios, I could have been fired for my behaviour.

Chastened, I took away several important lessons: it doesn’t matter whose fault something is. The job had to be done, and I was around to do it. Furthermore, it is important never to be caught bad-mouthing someone on the record, no matter how good a relationship you have with a vendor. It will always come back to bite you.

Have your own career limiting story to share? Find me on Twitter using @bornsql.

Career Limiting Moves – Saying No

IT departments get a lot of flak because members are accused of saying no to what staff think are perfectly reasonable requests.

In this second post of my series about career limiting moves, I’m going to tell you about the time I told someone no and immediately regretted it.

My second full-time job, after working in a call centre, was in a technical support role. I didn’t have my driver’s licence yet, so I was based out of the head office. My job was to make sure the network was running, software was kept up to date, consultants’ laptops ran properly, and so on.

The same large customer from last week’s post had a Microsoft Access database system that was written when 16-bit Windows was the big kid on the block. I’d offered to convert the VBA code in the database to 32-bit, so that it could run on Windows NT 3.51 and Windows NT 4 on servers, as well as Windows 98 on the desktop.

My immediate boss was a director in the company, and I had been told on several occasions that it was a flat structure. We all socialised as equals, so I never paid much attention to reporting lines.

My boss told me to work on this Access database upgrade, and say no to anyone I considered a distraction. I took that to heart.

Another director of the company had some issue or other with her laptop that was affecting her ability to work and generate income for the business. You know: her job. She came to me and said, “I need your help with this problem”, and of course I said, “I’ve been told that I cannot have any distractions while working on this Access project”.

My job was to provide technical support to a senior staff member, and I said no because I was busy on something that was, for all intents and purposes, not as important.

This was of course escalated very quickly to the managing director, who in turn shouted at my boss, who in turn shouted at me. If I recall correctly, my boss eventually helped his colleague with her important problem and only reamed me out after the fact.

The moral of the story is that my priority list is meaningless to other people. It’s all very well saying no to a customer, and in my trade everyone I offer a service to is a customer. I have to be very sure that if I do say no, I’ve made that decision based on a clear understanding of the customer’s needs, not just my impressions.

Professionalism doesn’t mean a collared shirt and tie

Working from home, consulting with companies all over the world, has changed how I interact with customers. The last time I was physically on site was seven months ago.

We deal almost exclusively with each other via conference call and video using Skype, LogMeIn or GoToMeeting, juggling webcams, headphones, microphones, email, text messages, phone calls, instant messaging, and so on and so forth …

Scott Hanselman wrote on Twitter recently about spending more than 20 minutes of a one-hour meeting getting microphones working for all meeting attendees, and this is in 2016!

Being professional means treating your customers and colleagues with the respect you think you deserve in return.

Put another way, if you treat other people with contempt, you can’t expect to be taken seriously.

Missing meetings, not having your equipment set up correctly, not wearing camera-friendly clothing (or any clothing at all!), having an inappropriate backdrop, or having an inappropriate desktop background if you’re sharing your screen, all amount to contempt.

Take the time to set up your work space correctly by keeping the webcam-visible area behind you friendly to anyone watching you on video.

Learn how to use your webcam or microphone or headphones correctly. If you have to share your computer screen, make sure you have turned off notifications. Even better, try to keep to one virtual desktop away from email, web browsers and social media.

Do you use a Mac? Did you know that there’s a way for you to set up your microphone to send clear and crisp audio through Skype or other tools? It’s called Loopback.

All that money you’re saving on gas? Buy a decent condenser microphone, over-ear headphones, and a high-definition webcam. Don’t rely on your laptop’s built-in speakers. You know what microphone feedback sounds like, and wearing headphones is a great way to avoid it.

Don’t pick your nose. Don’t get too close to the camera. Someone might have you on a giant television screen with lots of people in the room. Because you’re not physically in the room, perception is everything. Even I make some of these mistakes, which means I’m also guilty of behaving in an unprofessional manner.

This post is not only to let you know how to behave, but to remind me how I should behave. We’re in this together.

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.