At one time there were two different products named SSDT and that was confusing for lots of folks. and we’re pleased to have Kevin Cunnane, the program manager for SSDT, as our guest.  We wanted to ask him about some of the new database features in Visual Studio and what kind of problems they are looking to solve.

SSDTWe think it is awesome the Microsoft folks will take some time our there their schedules to talk with us and we think you will this episode an interesting discussion on the future of database tooling.

 

 

 Episode Quote

“If you’re doing any kind of adhoc development, Visual Studio is very complementary and it will work well.”

“Visual Studio components are much more focused on kind of the developer scenarios and light weight DBA scenarios.”

Listen to Learn

  • SQL Server Data Tools
  • The BIDS and Visual Studio components of SSDT
  • Visual Studio source control and schema compare
  • Differences of SQL Server Management Studio and Visual Studio

Kevin on Twitter
Kevin on LinkedIn
Kevin on Channel9

About Kevin Cunnane

Kevin Cunnane is a Senior Software Engineer working on SQL Server client tooling. He has been creating developer tools in the NLP space and for the last five years in the SQL Server team at Microsoft. He is also involved in client tools (mostly Visual Studio), command line tools, SQL Server Data Tools, APIs for DacFx and the Microsoft Azure SQL Database Management Portal.

 

Transcription: SSDT

Carlos: So Kevin welcome to the program.

Kevin: Thanks very much for having me on.

Carlos: Yes it’s great to able to talk with the Microsoft folks and so we appreciate you take a little bit of time to chat with us today. Why don’t you first go ahead and introduce yourself and tell us a little bit about your role at Microsoft.

Kevin: Sure. So I’ve been working for the SQL server team for about five and a half six years now. I’m an engineer working directly on the SQL server tools and over my time I worked on a bunch of different areas but I’ve kept coming back towards developer tools specifically the SQL server data tools that shipped into Visual Studio. So, well sometimes I work on other things that’s all is kind of something that keep coming back to you. And that’s what I’m hoping to be here to talk about today.

Carlos: Yes actually that is our, our topic is the SQL server data tools. Now as we get in to this and if this is something new to you, you can maybe fast forward for just a minute or two but we want to make a clarification potentially. Because at one point it was a bit confusing as to the names SQL server data tools and what they meant. So there was kind of two veins. One of which we were familiar with so there was a, the biz, the BIDS for the Business Intelligence Development Tools which have been renamed SQL server data tools. And then there was a Visual Studio components that if you wanted to do some BI things on the visual studio – there was that. So I guess help us understand what are we when we say SSDT now, what is it that we’re talking about?

Kevin: Sure so, the reasoning now behind having two SSDT brands was a little bit accidental. There was a grand plan back in 2012 to unify all of these SQL tools and business intelligence and database relational into one product. Ultimately it didn’t quite land in terms of timing so it ended up with two products. The core SSDT which was the relational projects, and SSDT BI for business intelligence which a lot of people thought of just as SSDT. So with SQL server 2016, we actually took a big step and back and actually did that work to align the two together. So what you get now is as you install Visual Studio, you still got the database project and relational tool built-in since it’s really used by everyone. But if you go to the web and you search for SSDT what you’ll get is a package containing all of the Business Intelligence tools along with the Relational Database tools in one package. So it finally gets packed to that thing up. All of the SQL tools you might want to use in Visual Studio are SSDT. So and when you install them you get the choice of which ones that you want to actually use.

Steve: So then for instance, I mean if somebody was previously using the Business Intelligence Development Studio and they were working on reports. Is that what installs now as part of Visual Studio or is that for instance part of the SSDT add-on component?

Kevin: So for all of the BI tools, they are just part of the SSDT add-on. So they’re not shipped with Visual Studio just because they are a little bit more optional. They’re heavily used but they have always shipped that outside of Visual Studio. I would note though that in Visual Studio 2017, they actually have the reporting services and analysis services project types as extensions on the Visual Studio gallery. So if you don’t want to go outside of Visual Studio and find it on the web, you can actually search in extensions and updates and look for the online updates and find it them right there. So that’s another improvement going forward to make it a little bit more lightweight and easy to get your tools.

Carlos: So in this new environment, you mentioned right the, that idea that the tools are going to join forces or they’re going to become one product. It’s caused a little bit of heartburn if you will from the data perspective which is most of our listeners come from. And they’re used to using SQL Server Management Studio and now we’re kind of being led into the Visual Studio side. I guess, thoughts on how we can, I guess as you backup a little, that pill seems to be a little bit harder to swallow than maybe originally, you know I thought I think you know we as IT people sometimes we are very stubborn in the way that we go about things with this much as things changed. So I guess I’m curious to get some of your thoughts on what can we, yeah what are we doing or how can we make that adoption a little bit easier for those who have been so traditionally used to just work in SQL Server Management Studio.

Kevin: Sure, we’ll say that SQL Server Management Studio is still hugely popular and really will continue to be the flagship of all of our tools. And if you are serious about SQL server there’s, just the odds are that you’re going to use that. That said some of the more modern practices such as DevOps continuous integration making it easy to automatically deploy, those aren’t covered in SQL server management studio so you, you do need to step outside your comfort zone a little bit if you want to truly embrace those. But there’s a nice sliding scale of where you want to go on that. If you look at the, the database projects systems we have lots of functionality for producing these deployable packages that can be used in continuous integration but you can also develop the scripts and have them ready to publish and hand off to a DBA or more data focused developer on your team. So that they can comfortably deploy using SSMS or using sqlcmd from the command line and do that in a more controlled fashion. So that’s the first sliding step is you partner with other people on your team. They hand you off the assets and you go there and then moving on towards you know getting Git integration or TSF integration into your workflow and being getting more comfortable with that. It can definitely be a little bit, little bit more of clickstop on the way. So you don’t have to jump right in, you can partner with others and find ways to do this, and there are a lot of you know third party tools and also with the new Visual Studio team services, Visual, TFS 2015 and 2017, they’re making it really easy to set up these processes so that you don’t have to be a coder or somebody deep in doing these things just to get a continuous integration or continuous deployment process going. And that you’d hopefully keep it all pretty comfortable without actually getting deep into Visual Studio coding all of those things.

Carlos: Well I think it’s more, you’re seeing more and more opportunities jobs right in the all these SAS companies or organizations that are doing development that need the DevOps environment. The data folks are going to have to suck it up in the sense and you know and get familiar with that because it does make that process just so much easier and I think of getting into, using the SQL server projects even as an example. It gives you another reference outside of just the database so as you wanted to you know move those objects like you mentioned being able to hand-off the script. If that’s even a maybe another variation of that is I can then go to source control and use that as a comparison before I actually ended up deploying those changes. So it gives me another way to review what’s happening or the changes that are going inside of the database. And ultimately for that reason I think it’s a good thing to know and to become familiar with.

Kevin: That’s for sure and there, people build up all sorts of different solutions for this. Like you mentioned just having changes being compared against different versions of your source controlled data and produce scripts from that is something that a number of more serious users of our system actually do develop really nice systems are end up because it gives them that control that they want, assurance for data folks and but also makes it very easy to rapidly apply changes. And you know one of the big things with the DevOps movement especially for data is just being able to deploy your data changes at the same time as your application has huge benefits. It really helps speed things up but application developers are really not going always going to do the right thing. You need the help from data folks to make sure that you’re designing things correctly. And so getting involved earlier on that DevOps process, reviewing the changes and code review etc can really help make the whole team more productive.

Steve: Okay, so speaking of the source control side of it, so then is it with Visual Studio or with SSDT that you get the option to be able to like commit your database in the source control.

Kevin: Sure, so it comes with Visual Studio, Visual Studio Community and up for 2015 has source control. If you just install SSDT on its own, we put in a minimal version of Visual Studio just with the bits that we need. And unfortunate for 2015 that did not include source control packages, our source, support for source control. Now with 2017 we’re working on a similar, you know like external updater that will install just the pieces we need. And we are hoping to get some basic source controls support in there so that would come back to where we were in 2013 and earlier versions. But that is a little bit to be determined but ideally if you can use either one of the Express Editions of Visual Studio 2015, which includes the SQL server data tools for relational projects or the community or up. Those all have source control.

Steve: Okay. So I haven’t used that source control through Visual Studio in the past but I have used for instance the Redgate SQL Source Control through SQL server management studio. And that was one area that you could go and just point at the database, it would scan the entire database, put the whole thing in the source control, broken out by object types, tables, stored procedures, functions, views whatnot. Is that similar? I mean is that what the source control does in the SSDT in Visual Studio side of it as well or does it do something different there?

Kevin: It’s quite similar but it is a little bit of a change from the Redgate Source Control treats the databases as the source of truth still so it manages things in source control but you keep going back to the database for reference. With database projects in Visual Studio, you, if you want to start with the database you can import the contents into a project. And that just pulls all of the files locally into your machine where you can see them just like source control organize and then you will check those into Source Control. But those files we have a build process to validate all of the things that are happening in all of the contents. So often when you first import you’ll actually find all of the things that are broken in your database. Most commonly stored procedures and views that refer to tables or columns that are no longer there and somehow they’re still working but if you ever try to deploy it to a different database those will fail. So that’s pretty common. So yeah with SSDT it’s a much more project-centric view of the world where you start with the project and then you deploy from there. That’s the key change compared to Redgate Source Control.

Carlos: And then because I’ve worked with it a little bit you know, deciding what you’re going to do with your security as well because you know you’re going to import those users and the owners of objects get imported. And so what’re the things you’re going to find out pretty quickly is do you have a good structure for who owns all those objects and in your schemas and things like that. Because as you know, as we’ve mentioned kind of moving around from environment to environment, you’re going to see issues if that’s not setup well.

Kevin: That’s correct. One thing that we have improved on is we have much better controls when deploying on what to ignore or leave be when actually publishing. So you can pull in your user’s permissions, etcetera for reference but you can actually ignore them during deployments so that they don’t interfere and if you do have different systems for different deployment environments. It’s a little bit easier to configure that now.

Steve: Okay. So then beyond the Source control side of it. I mean what are the most common things that people use in the SQL server data tools to do beyond what you would get in Management Studio or in Visual Studio?

Steve: I guess what I’m thinking there is that if you, if there’s a DBA out there who’s been using SQL Server Management Studio for a long time and they’re comfortable with it and they do most what they needed to do today with that mechanism, what are the things that you really need to use SSDT to be able to do that you can’t do in Management Studio?

Kevin: Sure. Especially for DBAs there’s a couple of hidden features that are worth the price of admission we’d like to say. Particularly Schema Compare is built-in to Visual Studio and it’s free. And that lets you compare two databases contents to each other, database to project system or a DACPAC which is the compiled version of that. And so there’s great benefits there and if you want to be able to see hey what’s the difference between staging and production in terms of my database contents. That will give you that view and make it super easy to understand that. Similarly we have data compare for if you do want to compare for example hey what’s the reference data looking like in these two tables that are in different databases. And making sure they’re up to date or identifying issues. Those two are really huge features that a DBA might not be aware of but give then a massive amount of benefit.

Steve: Okay, excellent. I know those are two pieces that I have in the past looked at like third party add-ons trying to achieve and if that’s something, I mean I know the Schema Compare has been in there with the Visual Studio but didn’t realize that Data Compare was in there as well. Nice.

Kevin: Yeah. So both of those are there, I mean there’s a lot of the other functionality is around lightweight you know project system development but those two are useful for everybody. And schema compare is actually now supported in our command line tool which is called SQLPackage that lets you deploy all of your database project information up to a database where you can also do a number of other actions. And one of those is you can get a saved schema compare file that you’ve developed in Visual Studio and run it through this process or indeed using APIs you can actually build up entire workflows on top of the schema compare engine since we now just have a very simple API for it. So if you want to do some very simple logic and if you’re comfortable with a little bit of C# coding, very little that kind that you would do in a Power Shell script, you can do amazing things with that.

Steve: Very nice. So with that I mean if someone want to just build a script that would tell them what’s different between two servers and two SQL servers and it would run daily and send out an email. I mean is that the kind of thing you’re talking about or it’ll be really easy to do with that SQLPackage and a little bit of scripting?

Kevin: Exactly. You can do it directly with SQLPackage where you just send that straight to report and pre-configure what type of things to exclude; or if you needed to be more dynamic and respond to the result before formatting it for a result. That’s where you might write a little script that iterate it over the results and did it in a more controlled fashion.

Carlos: Yeah, and this an area that I think for still, even though it’s been in the couple of versions of Visual Studio is well, still appears to not be getting a lot of love and you know as we go to different conferences or talk with others that are using the projects. You ask like who’s using it and it’s kind of crickets. Now maybe I’m not in the right circles admittedly but I think there is a lot of value to moving to the SQL server projects and you know integrating with the source control you know components. And then of course you know you talked about the data, the data comparison components. Now one of the things, I guess maybe, I don’t know for some of the developer side but what gets included with Visual Studio now is actually a LocalDB copy. Do we need to be concerned about database sprawl as we look to be using Visual Studio?

Kevin: That’s a good question. The nice thing with LocalDB is that when you’re not using it for a long time it will stop running. It spins down and just keeps a very lightweight listener that will let it spin off again. So it’s not going to be using resources on your machine, that’s for sure. In terms of database sprawl and all of the databases you’re going to connect to there, it’s only if you got a local project develop, in development that will create a temporary database under LocalDB for you.

Steve: So then with the LocalDB there is that intended for like desktop applications that are going to be deployed and they would just use a local database or is it really more intended just for development purposes to.

Kevin: It can be used for either. We have people building, using LocalDB for like that desktop applications lightweight as a replacement for SQL CE or other lightweight database options. So that’s one of the scenarios for it. The reason it’s shipped inside Visual Studio is it really helps with your local development and debug loop. So every time you make a minor change in a project in SSDT, if you had it will deploy it up to LocalDB. So it can verify the deployment works, you can you know edit the data in there and compare it, verify everything works. And you can even run unit test against it to make sure that everything’s working okay. So that’s one of the most common scenarios. Similarly, for people who don’t want to use database projects, the web application development inside Visual Studio uses LocalDB too. It uses that as like a reference database. And when it’s publishing it gets a snapshot of that using our technology and publishes it up. So there are a lot of different ways to develop for SQL inside Visual Studio and it just depends on your workflow. Those web apps tend to be very simple it gets you bootstrap, you’re not worrying about a DBA for those and then often if you scale them up, that’s when you might want to move over to a dedicated SQL project or set a migration scripts which are much more controlled approach to go in through things either of those. But for rapid development LocalDB is great for these kind of scenarios.

Steve: I mean this sort of interesting is, sounds like again kind of that rapid development and I can’t help but think of kind of the open source maybe mentality or like, “Hey, I want to try something out and see that it’s working.” I know that again on a database side SQL server has made some changes to I’ll say I use the word compete with the MySQL because it is open source right from the data science perspective, analytics components. MySQL was being adopted much faster than SQL servers then they made some changes here. I almost feel like there’s a similar component there to Visual Studio’s, you know let’s put the tools in here so that people can quickly kind of see this is what they want to get bigger and then they can use something, something else that they need. Is that a fair,assessment there?

Kevin: Yeah I think that’s fair. And we are also by the way working to be more transparent and open source in our tools in general primarily with our new multi OS tools. So we have a visual studio code extension where it’s being develop fully in the open with SSMS and SSDT people have actually asked us about can we just open source this and they have pretty complex build system there’s some legacy stuff in there that would be hard to make that possible but we are trying to embrace that in any way we can in terms of extensibility points, making it easy for you to contribute, making it easier to raise issues and like that as well, just making it easier to adopt whatever tool that you use to deploy we want to be there and make it easy for you to develop SQL server.

Carlos: Now, you’ve mentioned you said before right SQL Server Management Studio is not going away. It will be there for those who want to continue to use it, one of the things that we also know I noticed in the Visual Studio component is that the SQL Server Object Explorer is now in Visual Studio. So I guess to reverse the roles a little bit, maybe let’s say I’m new, I’m a new DBA, I’m kind of coming up could Visual Studio be the tool that I learn in and grow in to manage my database?

Kevin: I think being honest it would be a little hard. We’ve had people asking why don’t you merge this two? But there’s a huge amount of functionality in SQL Server Management Studio around backing up, around different types of profiling, etc., There’s so many different piece of functionality there that you might need to use as a DBA that I think if you are actively managing databases, SQL Server Management Studio is still the tool that you should use. But if you’re doing any kind of adhoc development or want to explore that kind of side of things Visual Studio is very complementary and it will work well.

Carlos: It sounds like a tool, so the wizarding components that it gives you that’s what’s going to continue to be in SQL Server Management Studio, from the ability to get to the database and kind of specific to T-SQL statements and things like that, maybe there’s more options available.

Kevin: That’s correct, it’s just a little bit richer in that, the Visual Studio components are much more focused on kind of the developer scenarios they have all the common things that you might need to use if you’re a developer or a light weight DBA but once you get into managing, dozens or hundreds of databases and doing them at scale, there is just certain things that SQL Server Management Studio will do that I think people are going to want to install it and use it.

Steve: Sounds like there’s a hand full of different versions out there than with a SSDT and Visual Studio 2017, 2015, 2016 which ever.

Kevin: 2015 for that one, 2013, 2012, 2010 we’ve been in them all. Yeah, that’s correct. So one of the things that it is important to note is that all we actively develop on and ship into are the most recent two versions of Visual Studio, so that means that what’s Visual Studio 2017 at, we’re going to keep shipping updates into that with new features similarly Visual Studio 2015 will keep shipping features into that until there’s a new version of Visual Studio and for Visual Studio 2013 and older we will do security patching and maintenance and all of those things if needed but it won’t get any new features. So that means in particular if you want to use the latest versions of SQL Server, SQL Server 2016 or above and SQL Server VNext which our latest RCs are letting you use or if you use Azure SQL DB which tends to keep iterating and moving on and moving forward you should be using one of Visual Studio 2015 or Visual Studio 2017.

Steve: Okay, I know that’s an area you’ve mentioned the Azure databases, that scenario that I ran into using the Azure parallel data warehousing where I needed to get a specific version of the Visual Studio that was different than what I was normally using to be able to use the tools to connect to that location.

Kevin: That’s correct, so for that, if you want to use Azure SQL Data Warehouse you should be using Visual Studio 2015 or above and you should just update the SQL server data tools to the latest version. We’ve had support for quite a number of versions now but obviously with visual studio, you know 2015 came out 2 years ago, SQL Data Warehouse came in 2016, so naturally you just need to update to get support for that. And one other thing to just call on this is that with the SSDT for VS 2015 release and onwards, we do now have backwards compatibility support for previous SQL Server versions not just in the database projects where they always were but the all of BI project types, so the database project type analysis services and reporting services all have support officially for SQL Server 2008 and up and for integration services it’s SQL server 2012 and up, so if you do want to use this with older versions in the past you needed to be tied to a specific Visual Studio version, now our recommendation is just get the latest and will support your SQL Server.

Steve: For people who need to work on multiple versions of SQL Server that’s certainly a big win there, I know for instance working with SSRS a few times I’ve had to have several different installs to be able to work on different SQL Servers at different client sites.

Kevin: Well one thing that I like to bring up is ignore column order support which is a major feature people have asked for and just to get advertising out there that this is now in SQL Server Data Tools, if that’s cool? Great I’d like to talk about that briefly, we added in our most recent version of our SSDT or release candidate support for ignore column order so people have been asking for a long time and a little background is that if your deploying from a database project we try to be very accurate about making what’s in your project system be what’s in the database. The challenge with that is that people often add in your columns in the list kind of alphabetically or they just add one in the middle which they don’t realize will cause a data movement operation because you can’t do that via T-SQL syntax, you need to always add to the end. So we finally brought back support for ignoring column order when deploying which means that if all the columns are there it doesn’t matter what order they are in we will leave them be and we’ll add new columns to the end rather than doing a much longer running operation. So we’d encourage people to try the release candidate and we do have the full version will be coming to Visual Studio 2015 as a GA within the next month or two so keep your eye out for that it will go the regular update channels.

Carlos: Okay and that makes me feel a little bit better, so I think previously the 2015 version there was this option in the project which made my heart stop a little bit where it would go through the process of creating a new table, moving the data over, dropping the old table and all the constraints and everything that was needed. And I was like, “Ooshh”.

Kevin: Yeah, and just to point out we do have so, one thing that it’s not built in to detect those kind of changes and warn you about it. We do have people who built that though on top of our extensibilities, so if you do want to do it, it’s there but it helps as well as we say trust but verify where before deploying to production in particular just make sure that somebody does review the deployment script. And if you see those kind of things it’s unlikely to be what you intended so go back, check this option to ignore column order or redesign it and realize that this is a breaking change. So we have extensibility where you can actually do that programmatically but that’s a little bit more cumbersome than some automatic processes, so just people can just build those on top.

Steve: So then if you’re doing the ignore column order rather than the old process of renaming the table and then creating a new table and throwing it up and swapping them around, it’s just going to drop the new column at the end of the table if you add one?

Kevin: Correct, it will just do an alter table add column and your good to go.

Steve: Very nice, that will be much faster, assuming that it support the applications using it are fine with that layout.

Carlos: So I did want to circle back around for a moment because you have talked about the different versions that got pushed out even we talked about 2012 or 2010, 2012, 2013, 2015 and so there’s which is great and everybody is excited to see the “New Microsoft” and the speed of what you guys moving and its mind boggling sometimes. But that does beg the question a little bit you mentioned that the new features get into the last two versions of visual studio. It can go pretty quickly there, I guess thoughts on how or the organization would attack the idea of keeping up with the newest versions?

Kevin: That’s a good question, well one of the things that’s been happening which will hopefully make it a little easier is that with Visual Studio 2017 in particular, the installation has become a lot more light weight and installs a lot less global components, so you’re less likely to run into problems if you do try out the new version while still having the older version on your machine. What we suggest is even with this you’re still getting about a 3, 4 year process were you need to update at some point during that if you’re going up to the lasts SQL Server version. When it comes to build processes etc, one thing is that we now have a new get package with all of our MS build components to make is easier to have kind of unknown version when you’re doing your proper CICD so that it builds standard version that can avoid some of the trouble there that you get into with these where at least your build process will always be consistent no matters who’s developing on which version. The other one is that probably what we’re seeing is that usually because it’s backwards compatible you can have a handful of people in the team try at 2017 even if you’re still in 2013. Stuff still works certainly on the database project side. I think some of the other projects types you may need to be prepared to do a one way upgrade so it needs to be more blunt. For the database project type you should in the vast majority of cases be fine trying it out getting maybe a mini team to do it on a certain project and then adopting it once you realized there are no issues. And also, a lot of things have gone through more of a subscription based models so if you have Visual Studio 2013 it should be pretty easy to update without any pain straight up to 2017 and use it there.

Carlos: Got you. Well, awesome. Kevin, thanks so much for being with us today. Any last thoughts before we move to SQL Family?

Kevin: You know, I’d encourage people if you haven’t tried it already, try out the RC. I mean it has support for SQL Server vNext and one of the most fun parts of that is that we now have docker support for containers so you can install SQL vNext in a few seconds without it squashing anything on your machine which is the best part of it. So just try it out there. You’ve got no risk of damaging anything and pretty exciting to do that and give us feedback on it. We’re going towards GA so we’re focusing just on the quality of the tools that will support this even though obviously it will be a while yet still SQL vNext is released. We want to be there with the tools ahead of time. So everybody please write that out. Please write Visual Studio 2017 and the tools in there as well. And we’re looking forward to hearing you feedback on it.

Steve: Well, let’s move on to SQL Family then. So Kevin, how did you get started with SQL Server?

Kevin: That’s a great question. So I have been a tools guy for a while. Before I join Microsoft I’ve been working in different company developing tools as part of a larger set of things but I really enjoy that process of kind of getting the complex requirements on deep things. And when I came to join Microsoft I had a few different areas. But this one really descended by far the most interesting. So I joined and I knew nothing about SQL. I barely done any database development so it was a little bit of a trash course learning all about it from the schema point of view. And luckily on the team that I worked on, you have to learn all breadth and depth of how you can configure SQL server in terms of schema changes. That was really fun and I just love that process and I really like that kind of people we worked with in the user base. So that’s been very rewarding for me.

Carlos: Now, if you could change one thing about SQL Server what would it be?

Kevin: That’s a good question. From my side I wish it was easier sometimes to add new features into the tools that support the latest features, so we have some really amazing things that makes stuff super simple for people such as temporal tables. Unfortunately it can take a lot of effort to make the tool support that so people don’t realize that’s why sometimes we don’t always have as many new features in the tools as we’d like because we’re supporting these new SQL Server versions. And with SQL Server 2016 in particular, there were just so many features which people should try at which we supported, OS encrypted, temporal, just a huge number. So I wish it was a little cheaper to do that just so that we could add more value for people. But on the plus side people get to try out of all these new things and it should all work pretty smoothly for them. So I do upgrade and do try these things because they’re pretty awesome.

Carlos: Very cool.

Steve: What is the best piece of career advice that you’ve received?

Kevin: That one has, I mean, my first manager here, his best piece of life advice was buy a house because the market will be crazy and I regret not following that one. In terms of career of advice, I think the biggest one really was don’t be afraid to just on quality and always good feedback in terms of code reviews, and that’s just have been a huge benefit whenever I’ve done it. Just always be willing to ship a week later but have it be good and I think that’s done for pretty much everything.

Steve: Ok.

Carlos: Especially for somebody who is working in the tools, I’m sure you can appreciate that as well.

Kevin: Yeah, you know, we don’t like to do hot fixes. The good thing is when we have to do them occasionally and we can turn things around in a day now which is amazing. So we have shipped and gone, “Oopps”, something is wrong and by the next morning we have a new version that’s been patched which is great but we really don’t like doing that. It hurts our customers and it hurts us.

Carlos: Sure. Last question for you Kevin is, if you could have one superhero power, what would it be and why do you want it?

Kevin: I think I would like to have the power to turn back time sometimes, and just redo those decisions we’re like, “Oh, this is definitely what we need to do and going to it.” Specifically sometimes we get a very principled on we must support a certain scenario and then we spend weeks trying to do it and then realizing, “Ok, we could have done this much quicker at different way or avoided it all doing together.” I think gotten more than in my career if I could turn back time and change those decisions a little bit.

Steve: You could even turn back time and have bought a house when it was recommended by your manager.

Kevin: Yeah, I should have listened to him. He was a very smart manager and that’s the piece of advice for everyone if you could back to 2011, that would be good time to do.

Steve: Alright.

Carlos: Well, Kevin, thank you so much for being on the show with us today.

Kevin: It has been a real pleasure. Thanks for having me on.                                         

Steve: Yeah. Thanks a lot, Kevin.

Share This