T-SQL Tuesday #128: Learn From Others - July 2020 - Part 2

So I thought about this one a little more, and I think I'll make it into an unintentional two-part T-SQL Tuesday post. In my initial post, I expressed my gratitude to AirborneGeek (t/w) for bringing me into the madness that is databases. But I didn't really tackle the intent of his topic for the month. 

Kerry, you know where I came from. You know my aviation background. So you know that I 100% believe in the importance of being able to learn from other people's mistakes. It's a big part of how pilots learn not to break things. 

I didn't set out to be a database person. I didn't intend to be in this place. But I can't exactly say that I didn't ask for it. I'm apparently more masochistic than I thought. I mean, when I met you, I was a ColdFusion developer...... Now I'm a DBA. I could have had a much lower-stress life if I'd just stuck with being a pilot. Sometimes I question my life choices. But it is what it is, right?

I submitted late this month, and I wish I hadn't procrastinated. I think your topic was excellent, and it is something that I completely understand. The global airline industry had to suffer some very hard lessons before they realized that knowledge-sharing, especially of the bad stuff, was actually an extremely good thing. 

I spent years as a Flight Instructor. You don't learn from perfection. There have to be mistakes. That's what "learning" is. But, sometimes, it's better for you if someone else had to learn the hard lessons first. Just so long as they tell you about them. And if you listen to what they did wrong, maybe you won't go down the same path. 

I could probably write pages about how to assess a risk and how to manage that risk after you've assessed it, but it always starts at the same place: you have to be able to IDENTIFY that risk first. And no matter what the topic is, you don't know what you don't know. Murphy understood that. And I'm willing to bet that anyone who has worked with any sort of system for longer than a few months understands that sometimes things break unexpectedly. Most businesses that I've ever been associated with work at a pace that's much more appreciative of your ability to quickly find the solution on Stack Overflow. I'm willing to gamble that most people would prefer not to be the first person to write a blog post about what they found out and how they fixed it.

Honestly, off the top of my head, I can't think of any unique problem that I've run into that I haven't been able to Google my way out of. I'm also fortunate to have an exceptionally good team that is able to cover the subject areas that I'm not an expert in (like the network). I got a rather late start in the DBA game, so I don't have Bertrandian levels of experience as the Guardian of the Databases. But when I was primarily a programmer, I was grateful that I wasn't that person when a database went sideways, and I've also come to appreciate that I used to be an extreme database abuser. I never really would have had the opportunity to ask Kerry silly questions if I hadn't been. 

In answer of this month's T-SQL Tuesday, I don't really have my own individual story to share, but I can affirm the importance of both sharing information that you probably wouldn't want other people to know and of accepting that information without any sort of judgement. There's a reason that people warn about making sure that you have a WHERE clause when you DELETE something, or the joys of accidental Cartesian JOINs on large tables. At some point in a career, everyone has done it. Or they will. 

It's really hard to top a willingness to talk about what went wrong when your error cost millions of dollars and possibly hundreds of lives. But, if an airline can talk about how they screwed up, then no company should have even a tiny problem recapping the decisions they made that caused a multi-terabyte database to go poof at 4PM on a Friday. 

And no DBA should be too remiss to learn from (and not repeat) those mistakes.

T-SQL Tuesday #128: Learn From Others - July 2020

I don't write enough here. I let myself get too busy, and I often miss things that I want to write about. I have several articles that I've started and dropped and several ideas that I never even started. I do a great job of lurking and not a good enough job of participating when I should. So it's no surprise to me that I've been sitting on this post for a week and missed the deadline to officially participate. 

T-SQL Tuesday #128 for July 2020 was hosted by a friend of mine; someone I worked with a few years; and the person who is directly responsible for my transition from just a ColdFusion Programmer to also a SQL Developer (and now a DBA). 

When @AirborneGeek came to work with me, I was primarily a programmer who knew just enough SQL to literally be dangerous. I could get a query to return the data I wanted, no problems there. I had fallen into the normal trap of "My queries are slow. It's gotta be the database's fault." Or Network. But we all know the network is the cause of 99.9% of all problems, right? 

I think one of the primary reasons we even created his team was because we were an application running off of millions of records, with NO database experts, and our applications were slow. 

Specifically the reason why I became somewhat fascinated with SQL was because I ended up being responsible for an internal report that had to be run overnight because it ran for HOURS. I can't remember if I was the original author of said report or not (wouldn't be surprised), but it didn't really matter since it was my responsibility now. I thought it could do better, so I approached our new database team to see if they were smarter than me. Everyone knows that programmers are smarter than DBAs anyway, but I figured "What the heck?". I gave him my query. 

He held onto it for a couple of days, and when he handed it back to me, it looked nothing like what I had given him. But it gave me the same data and ran in only a few minutes! 

It may have been Voodoo, or it may have been Black Magic. Regardless, if not for my silly internal fault of always wanting to know "Why?", I'd be on a MUCH different career path.

Over the next couple of years, I had plenty of questions for him and the rest of the Database Team. The more I learned about how the database was supposed to work, the more I came to realize how wrong I had been doing things. That team taught me about how to do proper JOINing, proper indexing and generally how to make things faster and much more efficient. Also about how important it was to not accidentally write a Cartesian JOIN on a 10M row table.  ( Just FYI: That can apparently discover the memory limits of your SQL Server and earn you a desk visit from the DBA.) 

I know that my questions for @AirborneGeek probably seemed very basic to him. He always showed me patience when he answered my questions. He never treated me like an ignorant programmer, though in hindsight, I realize now how basic some of my questions must have seemed. So, What Can I Learn From Others?

As another pilot, I completely agree with the premise that piloting and DBAing have a LOT of similarities (disasters differ in magnitude, but are very similar in remediation, and a lot can be learned from other people's "Uh-oh" moments). 

My post really isn't so much about how I've learned to deal with SQL disasters, but about how I've learned to be grateful for the people who got me here. 

I can't say it enough, "Thank you, Kerry."

Though I guess I should also point out that the curiosity that was sparked has also led me to learn more about certain types of disaster remediation and recovery than I ever really wanted to know. So "Thanks again, Kerry."

T-SQL Tuesday #122 - Impostor Syndrome

This is the first time I've participated in a T-SQL Tuesday, and I need to start with an apology for being late. I know I'm technically violating the rules by several hours, so I don't expect to win the massive prize that these come with, but it is what it is, right?

The irony of my tardiness is that a large part of the reason I'm late (and the primary reason this is my first T-SQL Tuesday) is because I was waffling about whether or not I had anything useful to contribute. It feels a little odd to realize you are doubting your ability to talk about Impostor Syndrome.

On to my Origin Story:

 I've been into gadgets for pretty much my entire life, and my dad did his part to encourage my curiosity. He grew up working on cars and motorcycles, and he liked gadgets, too. The 80s provided him with plenty of geeky little things to play with. Fortunately, he was an airline pilot and had a little bit of disposable income for those geeky toys, so he could vicariously get his techie fix through my brother and me.

When I was a kid, I cut countless little snippets of wire for various iterations of the Electronic Lab Kits from Radio Shack (one of the BEST stores EVER). I disassembled numerous RC cars, so I could see how they worked. He bought a Commodore 64 and subscribed to Family Computing Magazine. I'm betting I'm not the first person to use those things to teach myself BASIC. I was off to a pretty geeky start.

In high school, I got two big things: 1) a serious girlfriend (who became my very patient wife), and 2) my pilot's license.

When it was time to pick a college, my mom wanted me to follow my geeky leanings and learn to be a programmer, but in the early 90s, a Computer Science degree was pretty much learning C and FORTRAN. No thanks.

After graduation, I decided to follow in my father's footsteps. I was going to be an airline pilot, too.

I immediately went off to Flight School, and for the next 6 months, I earned a few more certifications and became a Flight Instructor. I had been deemed skilled enough to teach other people how to fly airplanes. Cool, right?

I still wanted an airline career, so college was a Bachelor of Science in Professional Aviation . While there, I was also a Flight Instructor for other students in my same program. Several of my students are zooming around the skies today for Delta, United, FedEx and others. I was good at it. I knew what I was doing.

In the mid 90s, I got my nice, new degree, and I finally had enough qualifications for a move to the airlines. But it wasn't what I expected it to be. I didn't enjoying it as much as I enjoyed teaching, and a decent pilot salary was still about a decade away; it wasn't enough to feed myself, much less a wife and soon-to-be kid. I wasn't sure what to do with myself. Pardon the pun, but my life was kind of in a holding pattern.

 At the time, my little brother (who DID listen to Mom) owned a web development business and was looking for some help. He asked me to assist part-time, which shortly turned into a full-time need. I was enjoying myself, and didn't realize that I had just ended Career #1 as a pilot and started Career #2 as a programmer.

But this isn't where my Impostor Syndrome started. I knew that I was new and that there was a whole lot I didn't know; my expectations of myself were at an appropriate level.

It was a small company, so I learned way more than just how to program. I helped set up our network (a few times, since we moved). I had to administer all sorts of computers, including our application servers and databases and our workstations. When we acquired a company that customized portable computers (now called tablets) for pilots, my aviation knowledge turned me into a Subject Matter Expert and I became a lead for R&D. I was doing well and feeling pretty good about my ability to contribute.

And then the events of September 2001 made it difficult for both aviation and software development companies. We had to close a few years later.

I was a contract web developer for a few years, then landed at a Background Screening company. THAT is where my Impostor Syndrome kicked in. For several years, I was a software developer, then I did Support, then Business Intelligence (due to my earlier curiosity about our data), then back to Software Development. I learned a tremendous amount about all sorts of things, but I never felt like I knew enough about whatever it was I needed to know at the time.


I ultimately left there to get back into data, and since then, I've bounced back and forth between Software Dev and Database Dev, all the while, proclaiming that I couldn't help with X problem because I didn't know enough since "I am not a DBA". Which was usually followed by me researching whatever the problem was and ultimately helping anyway.

Throughout my career, I've worked with some VERY smart people. My curiosity has led me to read and follow other VERY smart people. This really hasn't helped me feel any better about my own skill level. I'm essentially a member of the unwashed masses who are "self-taught". My background and professional education are in Aviation, not Computers. I don't deserve to be with these people. Pretty soon, they'll figure out how clueless I am, and I'll be done. Humiliated and cast out.

That's pretty much the way I've felt for the last decade. I've worked many extra hours and done a ton of extra work so that my bosses won't discover that I'm not qualified for my position and should be fired on the spot. I started this very blog several years ago with the express purpose of being more visible and vocal for other devs, but I haven't written near the content that I wanted to because I've often feel like I don't really have anything to add to the conversation. For the last couple of years, I've wanted to speak at conferences, but I've procrastinated submitting my topics because I didn't want to try to talk about something I was clueless about (even though I did quite a bit of research to prepare). Too often, I sabotage myself because self-doubt creeps in.

 Last year, I realized that I've been working in IT over TWICE as long as I was an active pilot. I also can't really compare my skill level in Aviation to where I am in IT. They aren't the same. IT is a VERY broad field. There's way too much to know for any one person to know more than a slice of it. And Google has made me see how much there is that I just don't know.

Several years ago, I started going to a few conferences and actually began meeting some of the bloggers and writers that I had idolized. I discovered that they are every bit as brilliant as I thought they were, but they're also human and not the keepers of impossible volumes of knowledge that I'd built them up to be. They'd likely be the first to tell me that they don't know everything. And that's OK. The secret to being really great at something is to recognize your own weaknesses and cover them with other people who excel in those areas.

That realization has allowed me to understand that they are still extremely qualified EXPERTS, despite not having every answer, I need to learn how to accept the same from myself.

Today, I AM a DBA. And I'm still a Programmer, too. I'm doing what I enjoy doing. I'm not as fast as some people, but I don't have to be. I also don't know how to fix every problem that comes my way. But I don't have to be that person either. I still don't feel like I'm always the best person to fill my seat, but I'm beginning to realize that I know a bit more than I think I do. And if I don't know something, I find the answer. I try my hardest to make sure that my responsibilities are covered to the best of my abilities.

It's OK that I don't know everything. Nobody expects that of me. It's not realistic. I just need to convince myself to hold me to the same standards, expectations and limitations of everyone else.

It's hard sometimes.