Voice of the DBA

Tag: career2

  • The Real Scary DBAs

    I ran into someone recently that told me they were scared at their job. This person had built a number of ETL jobs to move data around between systems. They were trained as a developer, but had a little experience, got sucked into working with SQL Server, and had made a career without really considering themselves a DBA. They seemed a bit bewildered that they hadn’t messed up the data in any of their employer’s systems.

    I’ve met quite a few people like that, who seem amazed to be trusted to accomplish the work they do on a regular basis. It’s good that many people can go through a career in SQL Server and successfully accomplish the things their employer needs done. However there’s no shortage of “scary DBAs” out there that are in over their heads and do cause damage to data and systems.

    I see questions at SQLServerCentral on a regular basis that scare me. Not because the question is particularly hard, but because the person asking the question seems to be trusted with way more responsibility than they are capable of handling. I’m glad they’re asking questions, but often the additional questions they ask, or the lack of understanding they display about the answers have me worried. It’s not that these people are stupid, but often they don’t have the experience to do the job they’re assigned.

    All of us have things to learn. Many of us continue to learn on the job, often as we’re getting work done. I think that’s a valid way of going through your technology career and I hope most of you continue to improve your skills on a regular basis. However there are quite a few people that have little aptitude for their chosen field, learn the barest minimum to get by, and often implement code and configurations without understanding what they are doing.

    Those are the really scary DBAs and I’m amazed that so many of them are trusted by their employers to actively manage organizational data.

    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. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music.

  • Advice for Steve Jones

    I was tagged by Mike Walsh in a blog post entitled: 4 Attitudes I Wish I Had Earlier as a DBA. It’s a look back at Mike’s career and a few things that he wishes he’d known earlier in his career. These are four mental ways of viewing the world, soft skills that might have made more successful, or successful faster. Mike asked a few people to share their thoughts, and there are some good ones from Brent Ozar, Erin Stellato, and my favorite Aunt Kathi.

    I’ve got lots of advice for the young Steve Jones. I’ve had a successful career, with few regrets, and I think a small number of decisions I would undo. However I have some advice for myself, based on things I’ve learned, or things I’m still learning.

    There is no Plan
    There is no master business plan, and the people making decisions don’t necessarily make the best decisions. They’re not right, but they are in charge. Argue your position, give your professional opinion, and when the decision is made, support it and make it work.

    Take a breath
    Before you rush into decisions or actions, especially in a crisis, take a breath. It’s better to be a little slower than compound one mistake with another.

    We’re not saving babies
    Most of us don’t work on systems that affect human life. If you do, that’s fine, but for most of us our jobs aren’t that critical. Learn to keep things in perspective, and try to help your boss remember that as well.

    Be your own person
    Be honest with yourself. What do you like, and more importantly, what do you not like. It’s easy to get caught up in what others think. It’s easy to let yourself get drawn into a path that is not your own. Choose your own path, but more importantly, learn where your path really leads.

    I’ve written a bit more, a slightly longer post on my blog with a few more items. However these are the pieces of advice I’d have liked to have learned earlier in my career. Perhaps hearing one of these items will help one of consider yourself a success a bit sooner in career.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music.

     

  • The Time Machine: Four Things I’ll Tell Steve Jones

    I was tagged by Mike Walsh recently in a blog post he wrote about 4 Attitudes he wished he’d had earlier in his career. It’s always interesting to look back at the past and think about how things might have been different. It can also be instructive for others to see what you’ve learned and would do differently. That can certainly shortcut someone else’s journey to be a better professional.

    If I look back at my career, I’ve learned lots of lessons. Some I learned early on, some later, and some I’m probably still learning. I’ve had a lot of success, but there are a few things that I’d go back and tell the 24 year old Steve Jones to remember.

    Technology is not religion

    To start this off, I’ll look back at something that I’ve argued far too often about early in my career. Is Windows better than Linux? Should we choose Java over .NET? SQL Server v Oracle?

    It’s fine to debate the merits, but there are many ways to solve problems, and many of them work well. There’s no need to take hard lines for or against any technology. If it works, use it. If you get the chance to learn it, learn it.

    Fortunately I learned this fairly early in my career.

    There is no Plan

    I used to think that successful businesses had things figured out while those that struggled just made mistake after mistake doing things they should know better than to do.

    Having owned my own business, having worked in large and small companies, often in close proximity with upper management, I’ve learned there isn’t much further from the truth.

    So many business decisions are guesses. They’re gambles. They’re hedged bets; sometimes well hedged, sometimes not at all. Often business people use their experience, but in a world that changes rapidly and in strange ways, no one has all the answers. I used a capital P on Plan because The Business Plan is just a direction to start moving. Things can, and will, change.

    How many enhancements in the SQL Server platform have worked out well? How many haven’t? There are examples of each, and while it’s easy to second guess the directions a business takes, I wouldn’t bet that I’d do something better, and perhaps not even different.

    I bring this up because I’ve had so much angst and anguish about decisions made by the business. I’ve argued hard for certain directions and choices, and when I haven’t had things go my way, I’ve held onto resentment or concern for far too long. I have far too often ignored my own management advice when I was an employee.

    We should argue for more space, or a DR plan, or an upgrade. Argue passionately. However when the decision is made, in line with your position, against it, or even at a wide diagonal, go with it. Support the decision and do the best you can to make it work.

    Take a Breath

    Crisis situations are stressful. It doesn’t matter if it’s a disaster from a hardware failure, or a software rollout that doesn’t go well. People get emotional (upset, angry, fearful) and may say or do things that they might not do otherwise. Management doesn’t help and I’ve had no shortage of CEOs, CIOs, CFOs, and assorted VPs and directors that haven’t helped the situation.

    When you are trying to decide something, take a breath.

    When you’re trying to determine the cause of an issue, take a breath.

    When you’re about to implement a fix, take a breath.

    When you get an error message from whatever thing you last did that was supposed to fix the problem, take a breath.

    When you think things are fixed and are ready to inform someone, take a breath.

    Basically take a breath before you rush into anything. No matter what the pressure you feel or the confidence you have, stop and double check your work. I do woodworking and there’s a saying many of you may have heard.

    Measure twice, cut once.

    Take a minute and be sure that you are doing the right thing. Stop and read error messages and read your code again. Think about the ramifications of changing that setting. Ensure that you really do want to click that particular button or press those keys. Most of all, be sure things work before you tell anyone.

    I’m still learning this one, both in technology and woodworking. I won’t lie, this is a hard one, but I  rarely regret following this advice.

    We’re Not Saving Babies

    This is an expression of my wife’s, but I really learned it at a large company. Around the time of the SQL Server Slammer worm, there were a lot of virus outbreaks of various flavors. I was a part of the response group as the senior SQL Server DBA.

    One day a virus hit that shut down our email system. That meant that not only were employees effected, but systems couldn’t alert operators and for a billion dollar company with many thousands of employees, this was a big deal.

    Our incident group was convened and gathered together in the Operations area near my cube. Over a dozen of us were looking at systems and discussing the issue. We narrowed it down quickly to a particular virus, but to clean system required a good deal of scripting and manual work to deploy to thousands of Windows hosts. One of my good friends was a senior person in his area and when we narrowed down the work and realized that 4 or 5 of us could do it, it told the manager in charge he was leaving. His child had a sports event, and the rest of us would be fine.

    The manager wasn’t happy, but he realized that only a few of us could script well enough to set things up for the rest to deploy and monitor. I stayed late getting things working, but I’ve never forgotten that lesson.

    Most of us aren’t making life altering impacts with our work. My apologies to those of you that work on computer systems that do impact the life of death of a human. Our companies might make a little more or less based on our work, but plenty of people make mistakes all the time that cost revenue or lose sales. Almost none of our efforts are that important, contrary to the managers that lose perspective on a daily basis.

    Learn to keep things in perspective and don’t kill yourself over work that can be done tomorrow. Hint: that’s most of the work.

    Note, this isn’t an excuse to slack off. If you’re behind on work because you haven’t been doing it, then you might need to put in a few more hours.

    Be your own person

    I once got called about an interview with a company in the mountains of Colorado. It was a neat job, in an interesting business. They needed a production DBA, and I didn’t like my current job. We chatted and they told me I’d “get to manage a 13TB database.”

    This was on SQL Server 6.5,

    I ended the interview (politely) then, saying I wasn’t interested in the job. I had a small child and an infant. I was already spent a few nights sleeping in my office. I already had a blanket and a pillow in my desk. I didn’t want to move those things to another office.

    I’ve learned over the years that there are things I like and things I don’t. I continue to learn about myself, the things I like and don’t like. Most of all, I continue to learn to be honest with myself about how I really feel about the things that are a part of my career.

    I’ve watched friends stick with employers and even career fields or positions because of money, commute, prestige, and more. I’ve seen people spend far too much time working in positions that they hated every single day.

    Life is short. If you don’t like administering servers, change to another career. If you struggle to sit in front of a computer and write code, find something else to do.

    Change is hard and it can take time. I certainly don’t advocate quitting your job tomorrow, but I’d highly recommend that you make a 2, 3, 5, even 10 year plan to move into a career that you enjoy, or at least, don’t hate.

    Hindsight

    There is much more I could write. More advice I’d give myself, but I will say that despite the setback and stutters in my career. Despite the decisions I have regretted, I’m not sure I’d change much. I’ve had a great career, and a great life, and while I’d ask myself to think more about my decisions, I’m comfortable with where they have led me.

    I hope many of you can do the same.

    Tags

    I’m not tagging anyone. If you want to write, write. If you don’t, that’s fine. Either way, think about where you’ve been, and if you read any advice that catches your eye, think about taking it.

  • Artist or Scientist

    Which are you, an artist or a scientist? If you automate, you’re the latter. If you are a scientist, you can go on vacation. You can be more productive. People can count on you. You get things done quickly, consistently, and reliably. Everyone knows what to expect when you’re done with a task. They can expect things to be completed a certain way.

    If you manually run installation programs, click GUIs to configure options from memory, and customize each system you work on, you’re an artist. Artists build works of art, each of them unique. I know some incredibly talented artists working in technology, people who duplicate their work over and over extremely consistently. However at some point they’ll make a mistake, and then I’ll never know what state the system or code is in.

    While we need artists to push boundaries and experiment with new techniques, we don’t want them managing production systems or writing production code.  I want production code to use well known and proven techniques, best practices, good error handling, application of standards, logging and more. I want production systems to be stable, not with a lack of change, but with a lack of issues. I need scientists that produce work that can be counted on.

    Don’t build works of art. In development you must be an artist at times, but when you solve problems, ensure that the code contains best practices (secure coding and error handling among them), and make sure that your team understands and can reproduce the code later. In production, ensure you learn automation (PoSh, scripting, templates) and can build, or rebuild, your systems quickly and consistently. Deploy your builds to QA and development so that all the environments are the same.

    Become more of a scientist and not only will people depend on you, they’ll be less worried when you go on vacation because there will be fewer surprises for the person covering your work.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.