Apr 22 2014

I Am Better Than You

That is a patently false statement and total BS. It sure does crawl up your spine though doesn’t it? Why then do we need to do this?

I read an article, “How DevOps is Killing the Developer,” and, frankly, was a little put off by this:

Good developers are smart people. I know I’m going to get a ton of hate mail, but there is a hierarchy of usefulness of technology roles in an organization. Developer is at the top, followed by sysadmin and DBA. QA teams, “operations” people, release coordinators and the like are at the bottom of the totem pole. Why is it arranged like this?

Because each role can do the job of all roles below it if necessary.

Nice to know I’m almost as good as a developer. Now, I could go off on a “bash the developers” rant, but I think that would be seriously silly and counter-productive, not to mention completely against my beliefs. I really do like, admire, respect, developers. I also respect system administrators and SAN admins and QA people, hell, project managers. You can go find a web site or a blog specializing in any of these IT disciplines and locate the “DBAs are better than developers” article or the “QA people save the universe” article or “Thank the gods project managers keep all you poo flinging monkeys in line” article. They’re out there. And every single one of them is wrong.

My actual job title these days is Product Evangelist, but I’ve spend the last 15 years as a DBA, database developer and data architect. I feel like I have a handle on that job. I’ve specialized around the Microsoft stack, not because of any sort of religious beliefs, but because it pays the bills. Before that I worked as an application developer. Before that I was in tech support. And you know what, at no point in my career was any of the jobs I did literally more important than the others. You know why? They’re all in support of the same thing: the company succeeds.

Now, fine, developers are smart people. No question, no argument. Developers are capable of learning other jobs (I’m living proof). But you know what, so are people in all those other positions. How do I know this? Because I’ve worked with the QA person turned developer. She was a GREAT QA person. She was so great because she learned the full stack. She developed an understanding of databases and systems and code in support of doing a better and better job at QA. Then, she finally decided she wanted to fix the code a little earlier and switched over to development full time. I’ve also met the QA person turned sysadmin. I’ve met the developer turned SAN admin. The system admin turned DBA, the DBA turned developer, a million and one support desk people turned developer/dba/admin. Every one of these people followed similar trajectories. They started learning the full stack and found areas where they could specialize while using their knowledge of the full stack to make each position they were in better.

But all these jobs and all these people are all, or all should be, focused on one thing, helping the business to do what the business does, for most businesses, support the customer.  Regardless, the focus needs to be on the goals of the organization, not on the purity of a job, a process, a software stack, or a system. Purity and perfection are dangerous concepts within IT. We need to keep our focus where it belongs, not on MY code or on MY database or on MY servers, but on OUR BUSINESS.

And DevOps (I wish the term didn’t have such bad connotations), is about breaking down communication barriers, not just putting all the work on one person/team. Again, focus back on the business and what the business does.

So no, I am absolutely not better than you (the title is just click-bait). I’m not. But, you’re not better than me either. If my saying that makes you angry, maybe you need to reexamine your assumptions.

Jan 08 2014

Sausage Making

For those who don’t know, I work for Red Gate Software. I’m not a developer, but I work directly for the development teams so I spend a lot of time with them. This week I’m over in the UK, where they are headquartered, meeting with the different teams and discussing our products, their future, issues with them, enhancements, and all the rest. Suffice to say, I’m excited by the future.

But the really fun bits are when you see behind the scenes stuff. Red Gate is pretty well known for polished, intelligent, elegant UI design (yes, they keep me away from that stuff). Behind those pretty pictures though is code. And our developers are just like your developers, smart, capable, skilled, but still learning. And it’s those learning bits that are the most interesting.

Now, I’m not going to tell tales and get myself in trouble (I’m just recording everything for the massive tell-all when they inevitably fire me, HA!). But what I’m fascinated by is the fact that, despite the incredible skill of the developers here, and they really are damned amazing, they are all dealing with loads of code debt. Don’t know what code debt is? Sure you do. Everyone has it. Remember that time you thought that you could massively improve performance and maintenance by using a single lookup table for all the database rather than a large series of tiny tables? Don Peterson (he doesn’t blog or tweet, he just is, like Chuck Norris) coined the phrase Massive Unified Code-Key table (MUCK) for this design. Remember the intense pain it caused you? Remember how you then had to live with that design choice for years and years? Yeah, that’s code debt. Well, we have it too.

The thing is, you have to pay for code debt in some way. TANSTAAFL always applies, right? So you pay for it through maintenance over time, or you pay to replace it, but it doesn’t go away. Well, we have code debt that we’re paying to replace on several tools, and I’m wicked excited to see it getting taken care of. I’d say it’s a sign of maturity that an organization is not only able to recognize the debt, but is able to determine that NOW, right NOW, is the time to get rid of what had simply been a long-term irritant. Far too often we kick the can down the road and worry about what to do about it later.

Your homework: Identify some piece of code debt that you’re currently paying off. Determine the amount of pain it’s causing you. Calculate if that pain is increasing or remaining constant (it’s almost never decreasing). If it’s increasing, when will that NOW moment occur for you that you will absolutely have to fix it? Got all that? Cool. Now present it to your boss and see if you can’t pay off a little of that debt. It’ll be a great test of the maturity of your organization.

Dec 18 2013

Speaking in 2014

I love that I get to travel around and learn from my #sqlfamily. We’re still filling in the majority of the 2014 schedule, but the plans are to go to as many events as Mrs. Scary will let me. I’d like to alert you to a couple coming up in January, and then I should be able to get a fuller schedule for the first quarter posted soon (that way you can complain to me in person about Managed Backups).

On Friday, January 10th, I’ll be presenting a SQL in the City Seminar on Database Deployment in Cambridge, UK. Presenting in the UK is just fantastic. And this is a live event. And it’s at the stately Red Gate Towers. Oh, and this is a free event, but seating is limited. Make sure you follow the link and register soon. I can’t guarantee you a seat otherwise.

At the end of the month I’ll be speaking at SQL Cruise. I’m pretty sure that’s sold out at this point, so I’ll see you there if you’re going. If not, you missed out. Keep an eye on Tim’s web site for the next one. For a lot of people, this trip changes their lives. You’d think it was just an excuse to work on a sun tan and ride on a boat, but Tim makes it an Event by bringing together great speakers and knowledgeable engaged people who interact, guide, teach and just plain chat about all things SQL Server and all things SQL Family. Get on the next boat.

Nov 11 2013

For the Aspiring DBA

Getting started as a data professional is an incredibly daunting task. If you’re not concerned that you’re going to mess stuff up and cause a system to crash and burn, maybe you’re in the wrong job. The amount of information you have to learn is insanely huge, coupled with the fact that you are straddling application development, system administration and business needs, multiplied by the factor that all the apps, all the code and the very server structure on which you’re building everything is constantly changing. Concerned now? Good. Stay that way.

The one piece of advice I want to offer you is that very state of concern. You are in a wonderful and horrifying position. If you’re working in the database administration space, you’re tasked with protecting the data that the business needs to run. This means you need to worry about backups and database consistency. You need to sweat whether you can run a point-in-time restore operation at 3AM. You have to worry about security on the system and whether or not you have disks laid out correctly. In short, you have stuff to worry about. If you’re working as a database developer, your worries are no less than the DBA. You have to ensure that you’ve got a system that will collect the data needed by the business and do it in a timely manner. You have to have appropriate data constraints in place, or you will get bad data into your business. You too need to worry. If you’re working in the business intelligence space, you don’t have any room to breathe either. You have to ensure that your queries are well written, pulling back the data accurately and with adequate performance. You have to ensure that you’re feeding information into the business that allows them to make correct decisions so you can keep collecting your pay check. Worry central.

Now, relax. My real piece of advice to you is to relax. You are launching yourself into a vital position within most companies. You know this. So, take your responsibilities seriously. Take your time. Relax. There’s a saying I read about from Special Forces (that my cross fit trainer also uses), slow is smooth and smooth is fast. Make sure you do the things you have to do. Slow down. Get them right. Slow is smooth. Then, you’ll deploy your backup process once and it will work, the first time. Smooth is fast. You have to be the person that takes a breath before you commit that change to the data structure so that you know you’ve tested it so it won’t break production. You’re the one who will run the report twice to validate the outcome before it goes to the decisions makers. You’re concerned, but you’re relaxed.

This post is part of a series of posts from all over the SQL Server community. The inspiration came from John Sansom (b|t) who is gathering everything together in an e-book. I’ll announce that as soon as it is available.
May 09 2013

Book Review: Business in the Trenches

I’m trying to improve.

That’s at just about everything too. I know I don’t know enough or have enough skills to always get things done in an efficient manner, so I’m trying to learn more. One way is by reading, a lot. I’ve read a number of management and leadership books, many of them reviewed on this web site. I just finished the book Business in the Trenches. I really enjoyed it. It combined two of my passions, self-improvement and history, specifically history of World War I. Now, this is a tech, community and business blog, so I won’t go on & on about the Great War (although I could if you wanted). Instead, I simply want to provide you a link to my review of this book. It really is a worthy read that teaches important lessons in a fun and interesting way. That made me want to be sure that you all had the opportunity to learn about it.

Jan 09 2013

Plans for 2013

I have lists. Lots of lists. I even have them in different locations sometimes. Some of them are carefully written down in my notebook, others are typed into OneNote and I’ve been experimenting with Remember the Milk and Trello (Trello is winning). These lists include ideas for presentations, blogs, articles. Notes from sessions I’ve attended or meetings. Lots and lots of plans and ideas and all that sort of stuff. I try to keep it organized, but sometimes it runs away from me. However, I find writing things down helps me to keep things organized. Between very carefully scheduling out my calendar and all these notes, I only occasionally completely drop the ball.

One ball I dropped was coming up with some goals, some plans, for 2012. I just plowed through 2011 and then 2012 and here I am, two years an employee with Red Gate (and I’m sorry to say, terribly happy there, my apologies) and I’m not sure where I should be going. I don’t mean within the company. We’ve got lots going on there (more than I can keep up with). No, I mean career goals, work outside work, all the extra stuff.

I’m going to break these down into pure technical issues that I want to spend more time on and professional development. Let’s start with the easy stuff, technical.

First, HDInsight. I absolutely believe there’s something big possible with this technology. I could be utterly wrong (I sure thought SCOM had legs too, oops). But I’m going to keep slogging on this stuff til I get something of a more thorough understanding of it. I doubt I’ll be presenting on it except maybe for introductory sessions, and not even those for the next 3-6 months. But I’m going to get my mind wrapped around it and understand how it works. Maybe then I can better determine if it’s just a highly specialized impact wrench or a true paradigm shift.

Next up, more Azure. Go ahead, giggle. Microsoft keeps doing more and more stuff with it. You know you can store spatial data in Azure now? I didn’t either until earlier this week. I’m going to be presenting on how to do query tuning using Azure SQL Database tools. Actually, I’m thinking I’ll only use the online tools. Everything you need is there. You can access most of the Dynamic Management Objects (DMO) and you can read execution plans from queries there. I’ve got presentations already scheduled for this. I’m pretty excited about others that might be scheduled (LOTS of noise if those come to pass). I’m going to continue expanding my learning here.

As to professional/personal development, I’ve got something somewhat trivial I want to work on, and something that, frankly, scares me. I would also like to find a coach or coaches.

The trivial task is that I want to work on pumping up my slide decks. I’ve long simply used them as markers for my talks. Bullet points as reminders of the topics I want to make sure I cover. They somewhat act as a point for taking notes for the attendees, but they are excessively dull. I’m going to work with Mrs. Scary (a graphic artist, good at her job, freelance if you need some help and are willing to pay for it, get in touch) and punch up my presentations. I had about 12 or so different presentations last year. This year, I’m dropping that number down a little.

Scary. Really scary. No, not me. Me. I mean I’m scared, not scary. I’m scared because I’ve taken on the task of acting as a mentor to an actual human being. I don’t know about the rest of you, but I find that extremely scary. I’ve got a level of responsibility that I’ve never had with putting up a blog post or even making a presentation. It’s as bad as writing a book (and if you think putting your name on a book isn’t scary, wait til you see your first bad review). But, I’m excited by it. This is something new and different. I’m really looking forward to it, and I think the person who approached me has a lot of potential. They’ll be great without my ever getting involved, so if I can take some of the credit, I win. Sorry, joke. I’m going to try to help someone who doesn’t need it, but will benefit from the help. Assuming I get it right… Scared again.

Coaches. Am I doing the marketing bits of my job right? I don’t know. I need some help in that area. Am I approaching learning HDInsight correctly? I could use a coach to talk with and get some guidance from. Maybe some suggestions on my slides (although my wife is going to supply a lot of that). Pro athletes do it. Good surgeon’s do it. They must know something. It’s an approach I want to try.

That’s it. I’ll be continuing things like working on books (yes, I’ve committed to writing one and editing one, so far), presentations, light consulting, and working for a fantastic organization. But these are the current plans for 2013.

Jul 16 2012

SQL In The City: London 2012, Recap

Presenting on Ring BuffersWow!

How’s that for a recap?

The concept for the SQL in the City events is pretty simple. Put on a free event that instructs people on SQL Server, Azure, and related technologies along with a healthy smattering of Red Gate tools. All teaching is done by some of the best people in the business (and me).

This was the second event in London. The concept was launched there last year and succeeded quite well. This year the event filled it’s registrations so quickly that Red Gate felt obligated to have a second day, which almost completely filled up too. There were more than 350 people in attendance on Friday, and then, on Saturday, a day off, another 250+ people showed up. That’s well over 600 attendees over the two days. And what people! The UK audience is just excellent. These people really pay attention to what you’re saying. They don’t make many comments while the presentation is going on, but oh my gosh the detailed questions you get afterwards. It’s just wonderful. Plus, these guys are part of my #sqlfamily. I got to meet several people that I’ve met before in both the US and the UK. I love spending time with Tobiasz, Dave, Kev, Annette, Jonathan, Thomas, Neil. I also got to meet people that I had interacted with only online and they’re wonderful in person. Thanks to everyone who sought me out, especially Colin and Stephanie. It was a real privilege to meet you two (although neither of you knows the other). It’s the interpersonal aspects of these events that makes them great.

It’s so nice to be able to relax and show people something like how to get a sandbox environment set up, but all the ways that using Red Gate tools to do it can help you make the job easier, faster and cheaper. Normally you can’t give an open answer when someone asks how to do something better or easier during a session. This venue makes that possible.

I put on three sessions during the day. One on how to improve performance, yours and your code, in T-SQL. I got to regale the crowd on all the evils of ddltbl (not a typo, you had to be there) as well as common, simple, mistakes made all the time in T-SQL code. I also did a session on sandbox deployments. While I’m personally against giving everyone & their brother a copy of the production database for development, I acknowledge that it is a good set of data to develop against. So, if you have to do it, you may as well use Virtual Restore to save some space. Finally, my last session was on some of the lesser used performance metrics that are actually more useful than people give them credit for.

I sat in on some of the other presentations and they were great. I really liked Steve Jones (blog|twitter) session on handling disasters. I also liked watching a new speaker, Annette Allen (twitter), stretch her legs for the first time. She was good. UK user groups take note. You have another resource available.

I had a blast presenting all these sessions, twice, and the crowds seemed receptive. I really appreciate everyone who attended and the excellent feedback that they politely (but firmly) provided. Then we had beer.

Yeah, you heard me. Wonderful, glorious, Red Gate beer served right there at the event. It was a great batch of Select * Ale. Highly recommended at the end of a hard day of T-SQL learning and networking.

It was a magnificently run event. The only complaint I heard was that we had an inadequate number of bathrooms for the men (which, I learned, are not called stalls in the UK, some humor doesn’t translate well). Thanks to Annabel Bradford and all the team at Red Gate who put the event together (even if I do work for them, it was a really well run event). You guys are magnificent.

If you missed a session while you were there or you want to see a session again, keep an eye on the SQL In The City web site. Videos of the sessions will be uploaded. If you weren’t there, you missed it. But, I have good news.

We’re taking the show on the road. We’re going to be hitting five cities in the US in September and October and then Seattle in (which I think is still in the US) in November. It’s going to be a lot of the same people presenting the same topics, but it’s also going to include a ton of excellent local speakers at each of the cities we hit. This means the excitement and education that SQL In The City represents will be accessible to lots more of you soon.

Feb 06 2012

Meme Monday: Deadlines

Tom LaRock (blog|twitter) has assigned an interesting topic for Meme Monday this month, working with deadlines.

Some people hate deadlines. Some people love deadlines. But when you have one, there’s a good chance you need to really meet that deadline or there could be repercussions.

I have a tip that I’ve found useful in the past. When I have a deadline for delivery of X, I evaluate that requirement and determine what, if anything, is dependent upon other people. I’ve found this to be the biggest issue because my deadline is seldom their deadline. So if there are parts of my deadline where I’m dependent on others, that’s my first task: Go have a chat.

Here are a few questions:

  • Is X a deadline for them?
  • If so, when do they expect to deliver?
  • If that negatively affects my deadline, can they adjust? If not, you may need to talk to someone about your deadline.
  • If it’s not a deadline for them, when can they deliver?
  • Can I hold you to that? Meaning, I’ve just given the other person a deadline.

Obviously you can’t just storm into an office and start rearranging people’s schedules (trust me, they get upset). You’ll need to work with them. But, it needs to be your first priority because, you can put yourself on a 24/7 alert to make a deadline if you want to, but, unless you’re in management, you don’t get that kind of control over your fellows.

To make your deadline, priority one is to recognize your dependencies on others.

Jan 13 2012

Friday SQL Nugget #1

polishGee thanks Jes (blog|twitter). Just what I wanted, a little extra work on a Friday afternoon. I used to like you.

We have a tagging theme started by Ted Krueger (blog|twitter) who I also used to like.

The theme is: Deciding that I need to delete and start all over

Lordy I hate this one. See, I find it easy to decide that I need to delete and start all over. My challenging task is persevering. But… here’s the rub. Because my challenge is persevering, I have a tendency to try to persevere when I really should be throwing in the towel.

I don’t have a technical example of this ready at hand (I did mention it was the afternoon on a Friday, right?), but I do have a presentation example. One of my presentations from last year… let’s say the topic wasn’t one I wanted to do. But, I had to. So I busted my hump on the slide deck. When it was done. I knew it was a steaming pile. But I sent it out for review anyway. Guess what. It was a steaming pile. They really didn’t like it, but suggested changes.

So I went back to work on the pile. Basically trying to take the substance, brown & smelling, and rearrange it to something resembling a pleasing shape. I worked at it. Hard. I tried different slides, jokes, anything I could think of to try to make this stuff resemble something of value. When I finally thought I had the pile in as pretty a shape as it was going to get, I sent it off to a second person for review. This person, a friend, didn’t pull a single punch. “Throw this out and try something completely different.”

Now that’s what I had wanted to do ever since I struggled through the first four or five versions of this slide deck, but I fought against my common sense and tried to do the hard work rather than take the “easy” way out and chuck it all and start all over.

Sometimes, you need another person’s perspective to realize what you’re vigorously polishing is not actually a diamond, but something entirely different.

I’ll tag… Gail Shaw (blog|twitter) cause it’s her turn.

Dec 09 2011


Microsoft is supporting an effort by PragmaticWorks targeted at supporting technical training for returning veterans. I can’t think of a single better cause to throw some support behind. Not one. They’re going to donate money based on posts about #sqlfamily.

Well done to Brian Knight (blog|twitter) and all the team at PragmaticWorks. I knew you were great people, I just didn’t know how great.

Thanks to Microsoft and the SQL Server Team for their support of Brian. Oh, and for all the work you guys do with SQL Server. I may bitch about you guys more than you’d like, but it’s only because I live inside your software, constantly. I wouldn’t be there all the time if you didn’t do great work. Keep it up. We can talk about this issue with rpc_complete and sql_batch_complete showing TSQL in two different fields in extended events another time.

Enough fawning. This post is supposed to be about #sqlfamily, so let the fawning begin.

My previous post for #sqlfamily didn’t go much into specifics. I don’t have a deeply personal story of support to share. I do have a story of technical support to share. I’m not going to name names on this one because the person involved gets paid to do what they did for me for nothing. If this person reads this, thank you.

I’ve only recently started working with Extended Events with SQL Server 2012. I know, I know, I should have been using them for years. What can I say. I’ve been busy and trace did most of what I needed. Anyway, I tweeted about the experience of getting going and a particular problem I had hit and how I solved it. I received an immediate direct message asking me for my skype account and if I had a minute. Sure, I thought, let me get five minutes of face time and I’ll be good. After a 40 minute drink from the fire hose, I had a much better understanding of extended events, as well as several pages worth of notes and links to information I had previously missed. Why did this person do this? Because someone they knew needed some help. That’s #sqlfamily to me.

You gotta think of it like this. Technically, we’re all competing for jobs. If I know something really well and you don’t, that makes me more marketable than you so I’ll be damned if I’m going to give you a leg up for free. And there are technical communities out there that behave exactly that way. We don’t. We share. We share our knowledge, our time, our struggles, our passion.And the funny thing is, we all get better for it. Will there come a day when I’m sitting in an interview room with someone I know next door interviewing for the same position? Ha! Already did that. I recommended the other person (neither of us got the job). Will there come another day where the same thing happens? Yes. And I’ll do the same thing again. I’ll list the other persons strengths and suggest they’re perfect for the job if that’s what I think. After all, we’re #sqfamily.