Voice of the DBA

Category: Editorial

  • Salaries and Experience

    This editorial was originally published on Aug 31, 2010. It is being re-run as Steve is on vacation.

    One of the main reasons that I got into IT was the salary. Honestly, there were relatively few places where I thought I had a skill AND could make good money. I graduated with an economics degree, with the idea that I’d go to Wall Street, follow Gordon Gecko, and work 140 hours a week and make a few million.

    That was until I wrecked my shoulder playing rugby my senior year, realized that I wasn’t invincible, and decided there were more important things than my salary. However I still wanted to have a good living, I had some skills in technology, and I moved in that direction. When I heard that our DBA was making $90k a year at a time when I was making $45k, I decided I should learn more about databases.

    Across the last two decades of my career, I think I’ve been fortunate in my career. It’s been a lot of work, , and a lot of fun. I’ve tried to grow my career, learn new things, and find better opportunities over time and in new positions. I’ve had success, and I’ve found the experience has resulted in higher salaries for me. I founda blog about salaries recently that says it’s not only experience, but also location that matters in terms of salary. That’s probably true, though I think industry, the particular company, and other factors are important as well.

    For most of us, we don’t necessarily want to change locations, but we can do something about our experience. I’ve seen it written before that for people that have 10 years of experience, it could be gained two ways. They could have one year of experience ten times, or ten different years of experience (or some combination). The point is that you should be continually expanding on your experiences, not just relying on skills you learned a long time ago.

    You may or may not be able to get a job that pays you more with more experience. I’d like to think, however, that any investment in improving your skills and learning more about your craft, is never wasted.

    Steve Jones

  • Closer to the Heart

    Most of us take whatever jobs we’re offered. We send out resumes, go through interviews, and often accept the first offer for employment. In fact, I bet most of us rarely have more than one employer to choose from at a time. Perhaps two if we’re looking for a job while still working, but I bet in many situations the current employer isn’t one we’re considering working for in the future.

    What’s more, it seems that many people working in technology can work in a variety of industries. A database that stores sales information for a retail company isn’t managed a lot differently from one that captures inventory information for a manufacturer. I know I’ve worked in the power generation, education, finance, software, and other fields. I’ve found that my job as a DBA or developer hasn’t really changed much. I could work in any of these industries.

    However, I’m sure that most of you have interests and attractions in areas. Perhaps some of you have really enjoyed working with certain data, or there are applications you think you’d enjoy. This week I wanted to ask what might be your ideal field.

    In what industry, or with what data, would you like to work if you had the choice?

    Or perhaps, where do you think you’d have a connection with the technology as well as the business. Imagine that you could choose what data you’d work with, and some employer in that field would offer you a job.

    For me, I think if I had the chance I’d like to work with a professional sports team in the US. In Denver, I’d really be interested if the Broncos, Rockies, or Nuggets needed some technical help. These organizations are starting to use more and more data to analyze their players in order to gain some competitive advantage. I find all the numbers published to be interesting and think it would be a fun job helping to find patterns and meaning in the data.

    Let us know this week where you might want to work.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Starting a New Job

    I’ve had practice here, and was reminded of this when I ran across this thread on starting a new job. In my career, I’ve had far too many employers. I’d like to think it’s not my fault, but after having double digit jobs, I have to take some of the blame. I’ve often been looking for positions that I expected to last for many years, but something always seems to crop up. Even the jobs I’ve loved have ended sooner than I would have liked.

    As a result, I’ve gotten used to starting new jobs, learning a new environment, and quickly getting familiar with people and processes. I thought of this when I ran across a thread that talked asked about the first few things you should do at a new job. There are some good answers, and it’s worth a read.

    For those of you that start new jobs regularly, or are consultants, do you have a routine? Do you have scripts you bring along? When I saw sp_Blitz presented a few years ago, it seemed like exactly the type of thing you would want to have with you and go through on each instance you encounter. Something that gives you a good overview of how things look. While each environment is different and the configuration and settings will vary, it helps to have a view of the situation you’re familiar with. Even if you don’t change anything, at least you understand how the systems are set up.

    There was a time when I had a complete evaluation routine similar to sp_Blitz and an install that would create jobs for backups and maintenance in a consistent way. I had more a few jobs switch to my way of managing things because it was very efficient. These days, I think I’d use tools that are tried and true, using sp_Blitz, Ola’s backup routine, and @SQLFool’s indexing routine. I wonder if the rest of you have similar preferences.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Ship Safe…Ship Often

    The Red Gate tag line has been Ship Often…Ship Safe, which works great for developers. Make the changes to code as fast as you can and get them deployed. Keep things smooth (or safe) with a routine and a standard way of deploying code. Everyone wins, right?

    When we were rehearsing the SQL in the City keynote last year, we came to this line in the script. I wanted it changed. As a DBA, I need to Ship Safe first. If I can do that, then I’m happy to Ship Often, as often as changes can be tested. I haven’t ever worried about changes being made too fast, as long as they can be made safely.

    These two principles seem to be fundamentally at odds with one another. Certainly there is some tension and conflict, but if those pushing through changes can follow a well engineered process, then dangers shrink. If the people responsible for stability and availability accept the changes coming through a process, then they can accept them rapidly and more often.

    Ultimately the closer we move to an engineering process, the more likely that we can deliver software at a higher quality level and quicker. However we need to define our engineering processes using the best practices and knowledge we have, and then stick to the the steps we’ve decided upon. Only then can we Ship Safe, and Ship Often.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.7MB) podcast or subscribe to the feed at iTunes and LibSyn.