Jorge Segarra aka @SQLChicken tagged me in a quiz asking how DBAs got started in the business, and I can’t believe I haven’t blogged about this earlier. Great question.
I Started as a Developer
That’s right – I was one of THEM.
But wait – it gets better. I started as a VBscript classic ASP developer. Using a Macromedia drag-and-drop GUI to build code. Hitting Microsoft Access at first, no less. I should probably break you in gently though.
In 1997-1999, I worked for a hotel management company as a jack-of-all-trades computer guy. I ran the network cables, I fixed the printers, I installed the OS’s, bought the desktops, yadda yadda yadda. As we speak, I’m wearing one of the shirts that PCConnection used to throw in the box whenever you bought a certain kind of HP LaserJet printer.
I’d come up through the ranks of the hotel business, and I was intimately familiar with the statistics that hotel regional managers wanted to see first thing every morning. How many rooms had each hotel sold? What was the average rate? How much revenue did the restaurant pull in? Every regional manager at every hotel company wanted this data, and they all had absurdly archaic ways of getting it. I decided to build a little web application so that the hotel night auditor could input the data, and then it would get emailed to the regional managers when all the data came in.
I started out using Macromedia UltraDev (which later became Adobe Dreamweaver) because it offered a slick, intuitive GUI that let you build code by dragging and dropping components onto the page. It worked great in the sense that a programming virgin like me could build an application that actually worked.
Right before the Y2K crisis, I went to work for a software company and learned Topspeed Clarion, a programming language that was supposedly database-agnostic. In theory, programmers could make a change to their data dictionary, target a different database platform, recompile, and bam – hook their app up to a totally different database platform. Unfortunately, if the program had anything hard-coded to take advantage of a particular RDBMS feature, then it didn’t work. I spent a lot of time learning the differences between Clarion’s native database format, Microsoft Access, and Microsoft SQL Server.
Getting Off the Hamster Wheel
After a few years of programming, project management, armchair architecture and honing my skillz, we decided that we had to get out of the dying Clarion and into a language with more legs. We were torn between Java and .NET, and spent several months building stuff with each one, trying to figure out what would suit our needs better. Suddenly, I realized no matter which one I picked, I was going to spend the rest of my programming career learning new programming languages every 5-6 years. I love to learn – but not new languages. I looked around at technologies to figure out what I could specialize in without constantly relearning languages.
It dawned on me that SQL as a language is pretty stagnant. DBAs don’t have to relearn a new language every time a new version of SQL Server comes out. Even better, if a DBA wants to change platforms from SQL Server to, say, Oracle or MySQL, they don’t have to relearn the language. They have to learn new tuning techniques and new management techniques, but not the language itself. Stick with standard ANSI SQL, and you’re pretty much safe.
That was it – I was hooked. From that point forward, I went from spending 20-40% of my time in the database to spending as much time as I possibly could. I’ve never looked back. This is one of the reasons I’m not really interested in learning PowerShell. A new language that I can use to manage SQL Server, Exchange, IIS and Windows, but not Oracle or MySQL? Thanks, but no thanks. I’ve seen what Exchange, IIS and Windows guys have to go through, and that’s the last direction I want to take my career.
In my presentations, I give developers a lot of flack, but it’s because I’ve been there. I know how hard it is to stay current and become a great developer in your primary development language, and mastering something else (like SQL Server) makes it even tougher. There’s just not enough hours in the day.
Who I’m Tagging
I’m tagging people who I’ve talked with a lot on Twitter, but I have no idea how they got started in SQL Server:
8 Comments. Leave new
This is always an interesting topic. I always find it fascinating to find out how my colleagues got to where they are at because it seems like, in this occupation, there is such a variety of paths people have taken to get here. I, myself, came into databases through a financial background. I started my career almost 20 years ago as a CPA and internal auditor and quickly was thrown into EDP auditing. I was fascinated with computers from my exposure through auditing and tried to automate my job as an auditor as much as I could through the use of electronic workpapers and schedules, DBASE IV code and Microsoft Access code to look for patterns, etc. All of this took me from auditing to Microsoft FoxPro development, which quickly turned into SQL Server development when the databases and number of users became too large and great. I have been a fulltime DBA for about 12 years now and consider myself more of an administrative DBA (manage for uptime, performance, etc) versus some of my peers who are great database developers or architects.
Thanks BrentO and SQLChicken for this topic. I look forward reading how others came into the SQL Server world.
I’m 26 years old and went to school to become a Network Administrator. I was able to pick up a job as a Network Technician and soon after promoted to a Network Administrator role. Yet after 4 years here, I find myself less and less interested in networking and windows administering, and more and more fascinated with the database role. Right out of school, the concept of a database was completely foreign to me. It’s not that I didn’t know about them, I just had no idea how they worked.
Now, as my role here as grown more into the reporting needs for our company, and I’ve gotten the chance to work with the couple different databases we have, I’ve really started to become obsessed with it. Several weeks ago I started researching what I needed to do to become a DBA, which has lead me to this site and several others that have been really helpful.
And now after reading how you’ve become a DBA, it’s even more inspiration to do the same.
So I just wanted to say thanks!
I agree that it is not cool to have to learn a new language all the time and that is one reason that I have never had any interest in becoming a developer. I agree that ANSI SQL is a good standard and that it is nice that you can change platforms easily to Oracle or Sybase without having to learn SQL over again. I disagree, however, with you on the Powershell front. I really think that PowerShell is the best thing that MS has done in years. Think about it, One, in my opinion, intuitive, easy to learn, language that can not only do server administration but also sql server, exchange, and many more to come now that PowerShell support is a Common Engineering Requirement for MS Products in 2009. Powershell lets you do so much I just do not understand not wanting to learn it. I have a Windows Administration Background and have been moved into DBA work in the last year. I work with Sybase, Oracle, and MSSQL Server. I will be changing roles and working more exclusively with MSSQL in the future but I still think PowerShell is the future for administering any MS Enterprise level product.
just my two cents. Good blog and I am glad that I found it from Denny Cherry’s link.
“I ran the network cables, I fixed the printers, I installed the OS’s, bought the desktops, yadda yadda yadda”
Exactly where I’m at and where I’ve been the past years. Touched a database here and there…but never really administered a “real” one!Frustrating. What again do they say about the difference between a jack of all trades and an expert…? Oh yeah…”One knows more and more about less and less until he knows everything about nothing. The other knows less and less about more and more until he knows nothing about everything.” Ouch.
I like your post, it’s inspiring.
Sorry to dredge up an ancient post…I wonder if in four years your opinions have evolved on PowerShell. Particularly for the stuff that is more the “A” part of DBA, I find it a really useful and flexible tool…particularly in areas where T-SQL/CMS just can’t get me there. Examples include SQL aliases on servers…I use Powershell for auditing those in a large multiserver environment. Another use we have for it is to audit what accounts are local administrators on the SQL Servers. Not aware of any way of doing that in T-SQL. 95% of the administrative problems for which I write code to solve are fixed with trusty old T-SQL, but those 5% or so would be really frustrating and laborious to try and solve without PowerShell. PowerShell for me is like a “Build-Your-Own Toolkit” sort of thing. I don’t use it a lot but every now and then I have a very specific need to solve an administrative problem, that may be relatively unique (how many folks are heavily depending on SQL aliases on servers these days? I don’t know, I assume not that many), and PowerShell allows me to build, or more often, cobble together from online code, a nifty tool that saves me time in the long run.
My own “becoming a DBA” story involves a good deal of credit due to the community, and specifically, a certain SQL Server consulting group with a penchant for teaching and sharing knowledge… 😉
Nic – interesting question. My thoughts on PowerShell are summed up pretty well in this post:
https://www.brentozar.com/archive/2009/06/give-me-a-coconut-and-six-months/
If you want to become a great DBA and that’s the end of the line for you, then great – focus on learning PowerShell. There’s nothing wrong with picking one specialization and spending the rest of your life doing it. I know some great career DBAs.
If you’d like to aspire to something else (and consultant is something else), figure out what that something else is, and what you’ll need to learn to get there.
I agree…PowerShell is a handy tool for getting tasks done and solving problems for me…but ultimately its small-scale, pragmatic stuff…a way of putting an irritating little problem behind me so I can move onto other things. For a career direction, becoming a script wizard isn’t a major goal. As a former systems admin type, I sometimes feel a reluctance to “get too close to the data”, that is I am tempted to treat data as generic data, just like an Exchange admin treats email as email regardless of what type of company he works for, and not worry about getting into the actual business concerns. Wouldn’t mind being a DBA lifer (talk to me again in 20 years…) but becoming more focused on actual business problems to be solved (ideally with data!), vs technical upkeep and optimization, is certainly good career advice for DBAs. Like the other article too!
“It dawned on me that SQL as a language is pretty stagnant. DBAs don’t have to relearn a new language every time a new version of SQL Server comes out.” G**gle tried so hard to make every problem into a computer science programming problem. Thankfully SQL has survived the onslaught of Hadoop ( a ecosystem of code to do a simple GROUP BY ) and getDBT using SQL to move data around, stopping Java BEAM.