Voice of the DBA

Tag: career

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

  • The Next Generation

    I was sitting in a Women in Technology luncheon recently when one of the other attendees talked a bit about her career. She said it had been filled with long hours, late night calls, stress, and plenty of other negative events. Although it had been a good career for this lady, challenging, stimulating, and she was well compensated, her daughter wasn’t interested in pursing a career in this field. I’m not sure if that’s because of the demands she had faced in this business, but I was interested in a (rhetorical) question from one of the panelists.

    “How do we get people to enter IT in the future?”

    As much as I do want to encourage more diversity in technology workers, I also just want more people working in technology. We have a shortage of talented workers for many jobs. I think there are lots of opportunities, better than average pay, and a career that you can enjoy for your entire life. It’s a career that could easily be continued into your 70s and 80s if you chose to do so. I hope you don’t have to work that long if you don’t want to, but it’s nice to have the choice.

    With that in mind, how do we continue to excite and interest people in technology? I’m not looking to convince anyone to enter this industry if they don’t want to, but I’d like to see more people experimenting with SQL Server, .NET, and other technologies as a career. I really just want more people to consider working in technology. If they choose not to, that’s fine, but at least give it a try.

    I’m always surprised at how many people I’ve met that studied other subjects in school, and even worked in other industries before discovering that they’d rather work full time with computers. I’d like to see those people get into the computer business earlier in their lives if that’s a field they enjoy.

    Of course, there’s a down side to having more workers in technology. Competition will increase, and those of you already working with computers will need to continue increasing your own skills if you want the best jobs.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio (3.0MB) 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.

  • Frustration with Bad Design

    This is not how you handle things. When you find security issues, and they don’t get fixed, it’s one thing to attempt to prove a point with a PEN test. It’s quite another to publicly expose information. You might find yourself in trouble, and you should be in trouble. This is a violation of the professional responsibility you undertake when working for someone.

    This is the type of frustration that occurs in many IT workers. I’ve seen more than a few people working in technology that are sure they know how to properly configure and manage an application. They know how to set up security, and they become upset with a company that doesn’t do a good job of running internal systems. They know that the architecture chosen for their application will fail when a load is applied.

    There are some smart people in IT, but sometimes they think they’re smarter than they are. Bad design, bad decisions, mistakes, even poor security practices will occur. However it’s usually not your company, and it’s not your place to prove that there is a flaw in a system. It’s especially true that it’s not your place to prove things without having been given permission to do so. Proving a point on your own is something children do, not professionals.

    When you find problems in your organization, it is your responsibility to report them. I hope you think it’s your job as a professional to do the best job you can, following the best practices as we know them. It’s also your decision to choose to leave a job if you can’t go along with, or abide by, the decisions made by your management.

    If your company has chosen poorly in their technology decisions, I understand your frustration. I’ve often shared it, but I’d advise you to do what I’ve done. State your objections and either support the chosen path or find another job.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.3MB) 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.