Kevin Feasel is a Microsoft Data Platform MVP and the engineering manager of the Predictive Analytics team at ChannelAdvisor, where he specializes in T-SQL and R development, fighting with Kafka, and pulling rabbits out of hats on demand. He started his post-graduate career as a web developer working for the Ohio Department of Alcohol and Drug Addiction Services, where he was the slowest to run away from the database and thereby became the de facto database administrator. Later, he became the de jure database administrator for the agency. Eventually moving on from there, he did additional work as a database administrator focusing on data warehousing and ETL solutions. At the end of 2013, he became a database engineer at ChannelAdvisor. In January of 2017, he started his current role as the manager of a new team dedicated to predictive analytics.

Kevin holds a Bachelor of Science in computer information systems and German from the University of Dayton and a Masters of Economic Policy from Albert-Ludwigs-Universität in Freiburg, Germany. He is the benevolent dictator of the Triangle Area SQL Server Users Group in Raleigh-Durham, North Carolina, and a co-organizer of the Triangle Area .NET User Group. He is a contributing author to the book Tribal SQL (Red Gate Books, 2013). He is also the curator for Curated SQL ( www.curatedsql.com ), which is a daily compendium of interesting blog posts in the data platform space.

A resident of Durham, North Carolina, Kevin can be found cycling the trails along the Triangle whenever the weather is nice enough. You can also find him online at www.catallaxyservices.com or @feaselkl on Twitter.

Mala Mahadevan: Describe your journey into the data profession.

Kevin Kevin: I had a background in computer science—that was my undergraduate at the University of Dayton in Ohio. I’ve always had a liking for stats and analytics, but I never really spent that much time with it outside of occasional coursework. At various jobs, I ended up doing things in Excel, but nothing serious.

After I graduated from Dayton, I got a DAAD Scholarship to study economics in Germany.

Mala: Oh my! Wow!

Kevin: Yeah, it was a lot of fun. I got to travel around and see a lot of Europe. I got a master’s degree in something that was a topic of interest. I thought about getting a PhD, but I decided it was probably time to join the real world.

So, I landed at the State of Ohio as a web developer. I turned out to be the guy who was the slowest to say “not it” when there was a database problem, and that turned out to make me the DBA. A strange way of doing it, but they had their reasons.

It turned out that I loved that work. I really enjoyed picking up, learning a lot about SQL Server, and really digging into it more. As a result, I went from accidental DBA, to real DBA, to database developer, and then I went into analytics full time. I just kept doing those types of projects, and a position opened up at my current company running an analytics team. So, of course, I jumped on it.

Mala: Awesome. Fantastic. So, you’re one of the DBAs who got there really early, looks like.

Kevin: Yeah, it was my first real-life job. So, is it the norm that people spend a lot of time elsewhere first?

Mala: Yeah, right now every single person that I’ve been talking to wants to get into analytics. Also, normally, companies tend to associate certain things, and one of the associations that I’ve been dealing with personally is that they think everybody in data science needs a PhD, and the only task is to come up with math algorithms and such. But, there are so many other things that you can do.

Kevin: Yep.

Mala: Describe a few things you wish you knew when you started your career that you know now and you recommend to people.

Kevin: I think the biggest thing is soft skills. I always wanted to be the guy in the back who just hacked on stuff, and that turns out to have been a mistake. Being able to talk to the other side, the people who are generally considered the profit centers, and to make some relationships, really helps you in your job. First, you’re going to be able to understand what others want. You’re going to better understand how you can write applications or how you can focus on what types of query tuning that is needed most.

But also, people are social animals. They work better when they have relationships. When you sit down to have lunch with people, they’re no longer some abstract concept, like “the salespeople.” They’re humans. They have names. They have personalities. Some of them have interests. You probably won’t like some of them, but yeah, this “cardboard cutout” is a person. It’s a lot harder to act poorly toward a person than toward an abstract concept.

Another thing that’s really important that I wish I knew early on—though I was lucky to have my first boss make this clear to me—is to make time to learn. Nobody else is focusing on building your skills. It’s on you. You have to be the person who’s going to be responsible for your development.

I’ve had great bosses who pushed this on me, but I know the norm is not, “Hey, I’m going to force you to take time and study this thing, even if it’s during work time because I know that a year from now it’s going to pay off for me.”

Most bosses aren’t going to think that way. Not necessarily because they’re careless or anything. It just slips the mind. There’s a lot of stuff for a manager to think about on a day-to-day basis. So, you’ve got to focus on this yourself.

My last advice is to get involved in the community. I did not jump in for several years. I finally started going to user groups and conferences after about four or five years as a web developer–turned–database administrator.

My first SQLSaturday was in Columbus in 2012. I really wish that I had gone earlier. I really wish I’d gotten involved in the local PASS chapter and the .NET User Group. I could always find some excuse. “Oh well, it’s too far of a drive,” “I have things to do that night,” “Oh, I’m so tired,” whatever. It’s something that I really wish I’d beaten myself out of earlier. Now that I’ve moved to the Raleigh-Durham area, I’m much more active in the community. When I came down here, I was working from home and so, I would use the user groups as a way for me to get out of the house and actually have face-to-face conversations with people.

So, I kind of had that carrot in front of me where, “Yeah, I’ve been sitting at the house for three days straight. I should go out and talk to people.” It took a lot of stress off my wife.

Mala: It doesn’t work to talk work with family people at all.

Kevin: Nope.

Mala: What’s a typical day in your life as a professional?

Kevin: So, my life nowadays is managing a team of data engineers. For the management portion, I absorb reams of paperwork. I basically knock down barriers. They have things they need to get done. We have things we need to get done. It’s my job to keep outside people from bothering them.

We run as a scrum team, so we’re constantly talking with our product manager, and trying to figure out what features to implement and what products to develop. There is a lot of research on this team, but there is also quite a bit of development.

On the nonmanagerial side, I’m still the database engineer for the team. We have a small team of developers and statisticians. One of our developers specializes in application development, doing what I call “statistical implementation.” He’s not the PhD statistician. He’s the guy who, once the PhD statistician figures it out, implements the solution and makes sure that everything works as expected.

We do have a trained statistician on our team, and we also have a computer scientist with a PhD who specializes in neural nets.

Mala: Oh, nice. Wow!

Kevin: So, the three of them are different parts of that data science triangle, and I’m the database guy.

Mala: That sounds like a really cool thing.

Kevin: It is. I really like this team. They have made management easy for me.

Mala: Describe how a DBA or a BI professional can expand those skills and embrace the new world of analytics.

Kevin: The easiest way to do that, I think, is to pick up a book on stats. I mean, there are a lot of stats books. Go back to the college textbook if you have to, but there are books that are focused on statistics. There are online courses. edX has quite a few of them. You could go to Pluralsight and learn more there. And, start applying some of these things to your own life in a small way.

Let’s say you’re a database administrator. Something I love doing in one of my sessions is show the Glenn Berry DMV query for what your CPU utilization is by minute, over the past 256 minutes. You can scroll up and down that and get an idea, but I could throw that data into R and graph it very quickly.

Collecting this data over time, I can perform outlier detection. I can follow techniques for trending where I can see hey, we’re always in this eighteen to thirty-four percent range, and yet suddenly we’ve jumped to seventy-five for several minutes straight. Something has changed. That might be worth looking at.

So, finding these types of techniques and just putting them into place at your job now helps give you that bridge from “I’m a data specialist” to “I’m now a statistician and a data specialist.”

Mala: That makes sense. Some people say that they’re not into math and that they’re not math people. Do you say that there is a strong connection between doing analytics and being good at math? I’ve seen debates go both ways on that.

Kevin: I like to troll people and say that statistics is applied philosophy. In truth, I think statistics is more philosophy than math. In some fields, like neural networks, you have to be familiar with calculus and understand the chain rule and gradient descent, but for the most part, you’re trying to understand concepts more than performing calculations by hand. We have computers for that.

That said, there is some math involved. And, yeah, for people who say, “Oh, I’m not good at math,” if you want to go into the field, you’ll have to get over that fear and dive in. Be able to read an equation because it’s not really as bad as it seems.

You’ll see a paper, and it’ll be full of these formulas. I saw the same thing in economics papers. They’re full of these imposing-looking formulas, but by the time you’re done going through it, you say, “Oh, this actually wasn’t that difficult at all. It was all really simple. You just threw in a bunch of scary-looking Greek characters.”

Mala: You said a little bit about working with agile on your team. Can you get into that a little more in detail? And what are the tools you use to make it work?

Kevin: Sure. So, I guess I’ll start back a few years at a prior job, because I had created the first set of tools. We had a continuous integration process back in 2010 using TFS [Team Foundation Server]. We automatically deployed applications, databases, reports, integration services, packages, services—the whole works.

The database portion was built around Visual Studio database projects. And then, I really got used to that. We were pushing things out nightly and responding quickly to user requests and needs.

We purposely chose not to implement the rules of scrum or kanban, but we had a process in place that worked well for us. My next position was at a company which did only manual deployments, and it was a big step back. I had gotten used to automatic deployments for so long, and now I had to run developers’ scripts manually and make sure they actually worked.

In my current job, most teams use scrum. We have about a four-week cycle for development, and we have a continuous integration process. It’s too large of an environment not to have automated tooling for deployment. Most of that tooling had been handcrafted a long time before I came in. We’ve got people who have been maintaining it since then—improving it in various ways and adapting as we shift technologies.

I’ve been a database engineer—a database developer—on a scrum team. Scrum purists hate the idea of generalists. I enjoy explaining why they’re wrong—that databases require specialization. You cannot be the database guy, and the application developer guy, and the UI guy, and the QA guy, and all of these other things very well.

You can be certain parts. You could be a generalist who is okay at several of these things, but when you’re in a system that actually requires saying, “Oh look, we’re calling this thing 500,000 times an hour, and it’s running at about one second,” that’s what a generalist can get you.

A trained specialist who’s good at performance tuning might get you down to a few milliseconds. Somebody who’s awesome at it might get you down into microseconds. Because there are so many different levels, this is like going to a hospital with a railroad tie coming out of my sides. I could see the general practitioner, but I’m going to want to see a specialist.

I consider application development in a similar vein. You’ve got to have specialization once you reach a certain point—once you reach a level of difficulty.

Mala: Makes sense. So, are there any tools that you currently use with the frequent deployments and such?

Kevin: We have an entire release tool which was custom-built. Within the database world, we will save all of our code in Git, but we don’t use Visual Studio projects. Database projects turn out to be a little too limiting for our system.

There are so many interlocking pieces in our solution that people have tried but after about a month, they get a tiny fraction of the way, and then you say, “This isn’t really maintainable because, in order to go any further, you need to create circular references,” which Visual Studio database projects don’t like. It ends up being more pain than it’s worth.

So, the database deployments happen through this release tool and also through custom-built PowerShell scripts, which take files and run them on the servers that they need to go to.

Mala: Describe your experience with cloud deployments.

Kevin: Prior to 2013, I was very strongly against it. So, this was when I worked a state agency. I considered it to be a huge amount of risk, and if there’s a security problem with the provider, it is our liability.

In other words, if I took all my data and put it up in AWS, and then it turned out that there was some sort of security vulnerability that allowed a neighbor to get my data, that’s my fault. Amazon is not going to say, “Oh, whoops, that’s our fault. We’ll take the lawsuits.” It ends up being on us.

So, prior to 2013, I really preferred on-prem. Then, I started using Azure for an ill-fated startup that a buddy of mine and I worked on. I got a taste of what that “no data center, no hardware, no problem” development looks like, and I started to understand that there were some scenarios where it made sense. I still was saying I wouldn’t put a lot of very important data in there. I wouldn’t put PHI—protected health information—data in, but I could see data that’s just okay for the public to view.

Then, I started working at ChannelAdvisor. A lot of what we do sits in the cloud. We’re often using services like Elastic MapReduce to get Hadoop clusters, or Lambda, which lets us run serverless functions. There is Kinesis, which I like to call Kafka-as-a-Service, but it is message brokering. We make considerable use of [Amazon] S3, heavy use of [Amazon] EC2, and we even tried out RDS [Amazon Relational Database Service].

Some of those EC2 virtual machines run SQL Server, too. We started using it for Disaster Recovery but I think that we as an industry have gotten to the point where there are still security risks, but this is something that companies are understanding better. We’ve seen enough breaches that we can price the risk value there.

Mala: Right.

Kevin: So, that said, there is still that big trade-off between OpX and CapEx, that is, operational and capital expenses.

OpX sounds wonderful for companies because there’s no down payment. You get benefit immediately and you can start the bill small, at least until you realize that you made a mistake and a bill that’s two orders of magnitude bigger than you expected comes in. So, that’s when OpX starts making people upset.

But with that said, it seems companies are focusing more on the OpX model where they can scale as there’s growth instead of buying the bigger hardware locally, making it a capital expense and depreciating it over four or five years .

Mala: That makes sense. I think that’s just picking up as of now.

Kevin: That sounds right. I didn’t hear a lot of it, say, four years ago but I’m hearing a lot today.

Mala: One of the much sought-after skills right now is data visualization. What has been your approach to this, and how do you recommend learning more about it?

Kevin: So, I’ve really gotten into data visualization over the past few months. And, I was lucky that many of the people I know really well in the community are data visualization experts, and so I got to sit down and watch them. I got to listen to them explain concepts, pick their brains a little bit, and then start learning it on my own.

There are a few really good books on the topic. I haven’t picked up most of those books yet. Instead, I’ve gone more secondhand— reading a lot of blog posts, watching videos, getting the synopsis of the topic, and kind of digging into some of the more technical aspects.

I see visualization in two angles. There’s the technical side and there’s the aesthetic side. The technical side is things like the rule of thirds in photography, where if you can segment a photo into thirds vertically and horizontally, the intersections of those lines are the parts of an image where people are naturally inclined to look. Another example is color vision deficiency, where we can see what an image looks like for a person who is protanopic [“red colorblind,” meaning no red cones], deuteranopic [no green cones], or tritanopic [no blue cones].

And so, you can see the technical part. This isn’t how to make a beautiful design, it is more of how to make something that people can see knowing that about eight percent of my population is going to see this color scheme differently than I do. And, that’s kind of the area that I’ve stayed in on—the technical visualization side.

I’ve been able to take advantage of tooling like Power BI, where they already give you a lot of this stuff for free. I don’t have to design a bar chart. I can just layer on a bar chart that looks pretty solid, and then I can focus on color selection or the layout of the screen.

The next area that I’ve delved in to is ggplot, a library that implements the grammar of graphics in R. The grammar of graphics is an idea that I can distill from a very complex image as a series of rules, as a series of layers—one thing following after another.

Hadley Wickham has a book on the topic, and there are other great resources, including cheat sheets and tutorials, where the author walks you through fifty lines of code on designing a beautiful plot. Here’s a complex plot that looks professional grade, and you can reverse back, and say, “Oh, well, all it is is a bar plot, and then on top of that, we’re changing the theme, and we’re changing labels, and we’re resizing fonts. We’re layering it on some annotations. Here’s some text on the screen that helps explain this little portion of the plot and softening it up. We’re removing some of the sharpness of the image.” And, by the end of it, you have a really nice looking visual.

That’s how I got into the technical side of visualization. I am interested in digging deeper into the aesthetic side as well. Visualization is an area that I’ve historically been awful at, but it’s kind of interesting to slip my foot in the door of this field.

Mala: What are some of the new technologies in the data world that you are looking out for and that you think a SQL Server person should keep up with?

Kevin: First, definitely streaming technologies like Apache Spark Streaming or Apache Kafka Streams . Even if you love SQL Server—and I do love SQL Server—or if you love Oracle or DB2, there are a lot of places where you want to use a streaming technology. You can use SQL Server as the source or as the destination. But in between, let’s say I have a lot of messages coming in IoT devices. In that case, I don’t want to hit that SQL Server hundreds of thousands of times per second if I can avoid it.

Mala: Sure.

Kevin: I want to instead have a message broker buffering and maybe aggregating the data, but definitely feeding SQL Server data in chunks because that’s generally more efficient. If I can bulk insert a million rows into a column or a table, that’s going to be a lot more efficient than inserting one row at a time a million times.

So, that’s an area where you easily see integration. But, you can also use Spark Streaming or Kafka Streams and take advantage of the quick retrieval and aggregation of data and feeding that out as a real-time stream of information.

When you have that real-time stream of information, things like a dashboard now get to be a lot more interesting, because I can see in real time what’s going on. I don’t even have to wait two or three minutes.

Mala: Oh, that’s fascinating.

Kevin: Yeah, if I have a fast enough system, I can just fire off messages, put them through Kafka, and pull them back in through another application. It’s like Service Broker if Service Broker actually worked, which is mean because it does kind of work but ...

Mala: It does kind of work, that’s a good way to put it. What is the role that documentation and communication play in your job?

Kevin: As a manager, I probably should say lots of documentation is critical because we need paperwork and blah, blah, blah. In reality, it’s reasonably important. It is most important to us when we’re doing research. We want to be able to say, “Here’s the stuff that we’ve done. Here’s the conjecture that I’ve got. Here’s how I tested that conjecture. I formed it into a hypothesis, and here’s how we can validate what we’re doing. Here are the things we’ve tried, the things that have failed, the things that have succeeded.” That’s important I think.

That’s vital to our team because we build up a set of information, and if one of us leaves, or if my team expands and I bring somebody else in, then we have artifacts to a piece of that culture. So, there are benefits to it. But, probably a little bit less than if I were a database administrator. If I were still a DBA, I want to document everything because something weird is going to happen at three a.m., and if I have it documented, if I have a policy written out, then when I’m completely exhausted, and I get that on-call message, I can just go through the list and get the right result.

And, the more wakeful, energized me of three months ago when I wasn’t stressed was able to go through and build a policy. In our team, because we are mostly a research and development type team, we don’t have those three a.m. emergencies, so our documentation tends to be a little bit more geared toward research.

Communication. So, our entire shtick as a team is we build tools. We build microservices for other teams within our company to use, and part of my job as manager of that team is selling our microservices. It’s talking to other teams and figuring out what they want. What kinds of things are helpful? If we build something, what kind of value would they get? What do they need? What endpoints do they need? How can we do this? What are their demands? And then we try to figure out if we can do the product.

So, that level of communication is critical for us because if other teams don’t know that we’ve got something out there, then either they’re losing out on something interesting, or they try to do the same thing. That unnecessary duplication of effort is something I’m trying to prevent.

Mala: Makes sense. What are your favorite books, blogs, and other means of learning? How do you keep up? Are there any from the non-SQL Server world?

Kevin: Yes. Confluent, the company behind Kafka , has a blog that has a lot of great information and some nice tutorials that go into great depth. Cloudera’s engineering blog is also great because they work with customers, and show architecture and implementation details to help organizations get a performance benefit, or show how they’ve been able to scale out their solution. Instead of just giving the marketing fluff, they go into detail and show the types of tools they used, how they configured it, and how they changed things to get a much faster performance.”

There’s another blog I like that’s run by Knoldus, a consulting agency out of India. Each of their consultants does some blogging. Some specialize in Cassandra, some in Spark, some in Kafka. Quite often, I can read through and find something interesting about Spark Streaming that I didn’t know. Many of the posts start basic and build up knowledge over the course of a series of posts. That’s another blog that I recommend checking out.

Mala: That’s a good list. What is your style of interviewing the data professional? What do you look for in people you wish to hire. What are some examples of questions you ask?

Kevin: I want people to say, “I don’t know.” I’m going to push you until you say, “I don’t know.” I dig deeper into a topic and what happens is either the interviewee will say, “I don’t know the answer to this,” or they’ll start making stuff up. If they start making stuff up, that’s an immediate red flag, and most likely I’m not hiring you.

For the phone screen, it’s about seventy percent technical questions and thirty percent nontechnical questions. Technical questions are pretty simple, like, “Can you tell me the difference between a clustered columnstore index and a clustered B+ tree index?”

And then, I go into some nontechnical questions. My favorite one is, “Tell me about a great business problem that you’ve solved with SQL Server.”

This question makes a person think. I have had cases where interviewees stopped to think about it, and then they’ve given me an interesting scenario like one where the business was having a crippling issue where they had to take data out, put it in to Excel, go through all these formulas, put in an ugly macro-filled workbook, and then manually type in the results in some other application. So what they did was use Integration Services and automate pulling the data out of the first system and putting it in the second system.

That’s the type of thing that I want to hear about. If I hear, “Oh, well, I rewrote this query to make it run in a second instead of a minute,” that’s not answering the question.

Mala: Wow! That’s interesting.

Kevin: Sean McCown had a great question that I’ve stolen and that I use a lot. “Ask yourself a question and then answer it.” That gives me a chance to see if I am missing something. It could be that this person knows a lot about merge replication, and I will admit, I ask zero questions on merge replication in my interviews. But, if this person knows a lot about it, that’s wonderful. You can ask the question, you can answer it, and then I can ask you some follow-up questions or for more information, and go down a road that I otherwise would not have been able to.

It’s also an indicator. If a person asks a question that they cannot subsequently answer, that’s a pretty big problem. I’m even willing to accept something that’s a really easy question and say, “Okay, that’s not a great sign but at least you didn’t ask yourself something you can’t answer.”

My in-person interview is a lot different. On the phone, we have plenty of give-me-an-answer type technical questions. In person, it’s screenshots and conversation. I’ve got a slide deck full of screenshots, and all I’m asking is, “What do you see in this? Is there anything that’s interesting? Any questions you would ask about it?” and I explicitly tell them there are no right or wrong answers. This is a technique that I stole from Brent Ozar, and it works wonders.

We spend the interview time talking about what that person sees. If I show the interviewee a screenshot from SQL Server Management Studio, they might respond, “Oh, well, you’ve got columns, keys, indexes, and statistics,” but then once they start getting into it, the good candidates start asking real questions, “Why do you have these columns? These columns look like they’re pretty similarly named. This is a strange primary key.”

Mala: Right.

Kevin: I can always come up with a justification—sometimes it’s the real reason, sometimes it’s something I made up. I want to see their thought process. I want to see where they ask questions. Are they going to say, “Oh, I think I can understand this but could you tell me the story behind it?"

And so we’ll do that with screenshots from Management Studio, with code snippets, and a few other things that they’ll do as part of the job. On the analytics side, I want people with the capability to research and read academic papers. People who are not afraid of those scary Greek characters.

I can train skills. I can teach you how to write SQL queries. I can teach you how to code in .NET. I can teach you R or Python. But I can’t train you a desire to learn.

I can’t train up a willingness to dig in to research papers. Those academic papers are where the best information is. They show up in papers first, and then six to twelve months later, that’s when you start seeing them in blogs. Then you start seeing them in tools, and then in videos, and then in books.

If you’ve got somebody who’s only going to read the books, that’s about three to four years behind state-of-the-art.

Mala: That’s a fascinating tip. I’ve never heard that from anyone yet.

Kevin: It’s worked pretty well so far.

Mala: Are there any websites or any places you go to read research papers? Are they the same as the ones you mentioned before?

Kevin: So, no, different places. Basically, if you still have a university email address, there are a lot of places where you can get access to technical papers, but there are journals that are pretty good for statistics like the Journal of Applied Statistics.

Back in my economics days, I spent a lot of time on SSRN, the Social Science Research Network. But, there are stats-based journals. There are computer science-based journals like the Journal of the ACM, or IEEE journals, or the International Journal of Neural Systems. Unfortunately, for most of these, you have to pay to read the articles. But, with a university account, sometimes you are able to read the papers for free.

Sometimes you can get ungated versions where the professor will just post a draft copy of the PDF on their website. It may be a working paper but not quite the completed version. But if you’re in academia, your goal is to get people to pick up on interesting ideas, and I appreciate it whenever an academic freely offers up their work in order to improve the state of the art.

Mala: Are there any conferences or technical events that you’re particularly fond of and you like to go on a regular basis?

Kevin: I love SQL Saturdays . I travel around, see the world, talk to people, see them over and over. It has a carnival feel to me. So, where it’s like, “Hey, I get to see you. We haven’t seen each other in two weeks!” So, I enjoy that aspect of SQL Saturdays a lot.

There technical conferences that I mark on my calendar as must-go events. PASS Summit for a while has been that for me. I did not have the chance to go last year, but I have been several times.

IT/Dev Connections and NDC [Norwegian Developers Conference] are a couple of others that I really enjoy because of that mixture of development and database administration. I actually prefer going to developer conferences because developers tend to be so optimistic—“I'm going to write an app that'll change the world!” Database administrators—we tend to be much stodgier, like, “I don’t want you touching production because your app that’ll change the world is going to take down our system and I’m the one who has to field that three a.m. call.”

So, over on the developer’s side, they’re so wild-eyed and full of enthusiasm. It gives me an energy kick for a few days until I realize the folly of my ways. But, yeah, I do enjoy going to those type of developer conferences a lot.

Mala: Good to know. I think you’re the second person I’ve talked to who says they like the developer conferences.

Kevin: Yeah, and you learn some interesting things. I still learn something new.

But, even within an area as broad as SQL Server, where, yes, you could spend your entire career and miss things, there comes a point where you say, “I’m probably never going to use this.” The slice of talks that are really interesting decreases and decreases over time simply due to repeat exposure.

With developer conferences, you can pick different languages. Go to an R developer conference, or to PyCon to improve Python skills, or to NDC to bone up on .NET. This provides a larger surface area for learning.

Mala: What has your experience been with the MVP program ?

Kevin: It’s been positive. I’ve been a Microsoft MVP for two years now. 2016 was the first year that I was awarded, and that was shocking. I was happy to be selected, and it has opened some doors for me.

I believe that having an MVP on staff has helped our company. Now we have two MVPs on staff. This helped us make inroads with Microsoft to a point where our company has been part of the EAP, the Early Access Program.

Mala: Oh, nice.

Kevin: And, so, we’ve gone out to Redmond a couple of times, worked with a SQL Client Advisory Team. For example, we got to try out production workloads on SQL on Linux before it was released.

It’s been a lot of fun, and it’s also helped our company a lot because we found bugs in Redmond that never made it to the product because they sprouted during this testing phase. I know other companies that have sent people out to these labs, and they get the same thing. It’s a great experience. It’s nice being part of that.

As an MVP directly, having access to the other people who are MVPs is very helpful because I get another chance to network with some extremely smart people and get a better idea of, for example, who the Hadoop experts in the community are. That way, if I run into a problem with Kafka, I have some smart friends able to help me think through a problem.

Mala: If you had one super power what would it be and why?

Kevin: My superpower would be phasewalking. That’s the power that Kitty Pryde [Shadowcat] from the X-Men has. She has the ability to phase through things, so she can walk through walls, can drop through floors. It’s not a very common power. I know on the SQL Data Partners podcast, Carlos Chacon asks this question of everybody. I’m the only person who has ever said phasewalking. And, admittedly, I would use phasewalking to troll people more often than not. Like, “Oh, I’m driving on the road. Let me drive on the wrong side of the street right in front of a car and I’ll phase through them.”

After the first couple of heart attacks, I’d probably stop doing that, but otherwise, it’s not a very useful day-to-day power unless I want to go downstairs to the kitchen, and I don’t really want to walk all those pesky stairs.