I started in databases in about 1999. My first job actually was customer service for a dental software company and so I learned a lot of my trade of speaking and talking to people through customer service. I would take phone calls on software and the company that I worked for purchased another company and merged and we just ended up having this database that came into our laps and nobody wanted to deal with it, and I just got interested in it and started learning about it. I just naturally took a liking to it and just kept going and then from there I took other tech jobs where I focused on databases entirely. I did attend college for one year, a long time ago, but it was just for a year and I learned some things that still helped me to this day, mostly about operating systems and about how systems work in general. But all of my other time and everything was directly on the job training. Some of the big things experiences that shaped it was about, I would say, three or four years into my career. I went to kind of a startup back then this was 2000 to 2003 so early startups and I really learned how it is to be in a very, very fast-paced, high energy environment that also you have to worry about if I come in the next day, are we going to still have a job. Some of those things give you a very interesting perspective when you start to work for other companies in the future. It really has shaped how I see companies and how I work with them because of that early on experience in the startup world, it was a big difference. Probably one of my biggest shapers was really starting out early. At that time we were doing technological things that nobody else was doing. So I was working on databases that shouldn't have been doing what they were doing so I learned a lot about that performance at that time.

I'll say as a standard database administrator. anywhere you go, you're basically responsible and you're responsible for the data, for the database, for keeping it up and running and the security of it and the data quality of it. So data quality is a little bit of a grey area because you run into a lot of times where developers and the engineers had designed the system put in bugs that will hurt data quality, and there's not a lot you could do about it but there's a balance there. For Podium specifically, we do a lot of management of working with just we have 80 to 100 databases essentially, so we have a lot of different little pieces that are moving that we always have to keep track of, lot of index maintenance, lot of general maintenance we do on those all the time and then we also have a lot of data that we have to update from time to time to just change hundreds of thousands of records to do this or that to do these different things. Again, that's kind of normal for a database administrator in the Valley or anywhere. You're going to find that a lot, you're also going to find them called database engineers, which are just database administrators that usually do a lot more development work. They write a lot more scripts, they write a lot more code, but in reality, they're both doing very similar things. I usually will spend in the office again Podium is a startup as well, so in the office, we're never there 9 to 5 let's put it that way, we're always there 9 to 6 or 7 to 5 or something like that. You're always there a little bit late here and there. I tend to avoid traffic, I'm not a big traffic person so I leave early and then I'll typically work from my house a little bit too at night and catch up on things. I would say database administrator work is what we call a roller coaster. At the beginning of the year and at the beginning of projects you're busy, and I mean busy by you are working at night, working in the mornings, you're working whenever you can and then there's also times where you're barely busy at all, and you've literally got nothing but time on your hands. So it's an up and down wave that we follow all the time whenever we work in database administration work. There's also a lot of that you will be on call and if you're on the call, you basically have to answer the phone whenever it comes up and that's very important because I have literally fixed databases on the side of i15, I have done it in a Starbucks parking. It's true that you've got to be available anywhere when you're on the call, you're not always on call, but when you're on the call that's what happens. Working from home does work for database people, but a lot of the times we're brought in to consult on a project and if we are brought in to consult on a project, it's best to be face to face for that consulting side of things. If it's just, here are your tasks, go do them then you can do that from anywhere, I can work from anywhere in the world but if you need to be with your team and say, Look, we need to design a new structure to do this, you need to be with your team for that side of things, you don't want to be remote for that that's too difficult. So we try to focus on that and we're definitely in the office there's a lot of the times engineers and developers will just come to our desk and say, Hey, I've got this problem and we work on that right there at the spot and that's best to just do that. So those were probably all the big things.

So I've worked in two major databases though I've worked with several different databases you have basically what's known as the open-source databases, and you have the Microsoft proprietary databases and things like oracle things that cost you money. I worked much of my first part of my career at Microsoft, and so I did a lot with the SQL server, and now I work in the open-source databases PostgreSQL and MySQL and some Oracle here and there too. All of the relational databases really boiled down to the same thing It's a relational database. When you go to the Microsoft and the oracles and things like that, you're given really valuable tools. You're given those tools and all of those things because you're paying for a service, and they give you those tools that are amazing. On the open-source side of things when you're working in PostgreSQL and MySQL you don't have those tools you have to go out and buy them yourself or build them yourself and that's a big difference. So you save on costs, but you're buying tool and you're buying that piece of it. Personally, I prefer, I wouldn't say I have a preference right now to me, they're all the same and I end up using things like Jetbrains makes a tool called DataGrip and DataGrip will connect to all the different data sources out there. It'll connect to the sequel server, it'll connect on MySQL, connect to Postgres and it gives me one consolidated thing for everything. I do have to pay for it, but at least that I've got the same interface for all of those things, no matter what I'm doing and it works really well for me. I would like to go back to the SQL Server Management Studio, one of the best tools out there, but it's limited to the SQL server pretty much it doesn't really go across to any other things and it makes sense to not try to use it for something else besides what it's intended for. So if you're in the database world too you're going to run into NoSQL databases or document databases, Elasticsearch, Mongo, Cassandra, all of those sort of things. Those run into the same problems they don't necessarily have a lot of tools with them. You have to either build the tools or you buy and then you use it with those tools. So any time you run into the open-source side of things, you typically have to either buy or build your own tool for whatever you're doing.