Voice of the DBA

Tag: career

  • Looking Forward to 2019

    It’s the final Friday of the year, between the Christmas and New Year days off that many of us have as holidays. Since this is often a very quiet workday, I thought it would be a good day for many of us to stop and think about our future plans for next year.

    I write often about career topics, encouraging you to improve your skill sets and actively manage your career. I think too many of us have been passive in our careers. We learn what our boss asks us to learn. We change jobs when we need to, often just accepting the first offer we get. We let ourselves be interviewed without interviewing the hiring organization. In most cases, we fall from position to position, which often might not be what we did if we actively managed our career.

    I talk about the different things you can do to brand yourself, market yourself, and improve your career in various presentations and writings. However, before you brand yourself, you really need to know what skills and abilities you want to brand. For many of us, this means verifying, practicing, and improving the skills in areas we want to work. To do that, most of us need some sort of plan.

    That’s what this piece is about. What is your plan for 2019? Are there things you want to learn for fun? For your current position? Maybe to set you up to get a new job in a year or two? Andy Warren has written a bit about this, and I think he has some good ideas. We need a plan that’s manageable, but also helps us move forward. We should write this down and have some way of measuring what we want to do with this plan. I’m asking you today to think a bit about what you might want to do and then make some plans.

    I’ve tried a few ideas in the past, with various levels of success, and in 2019 I want to try something else. I like books and learn from them well, so I’m going to take a number of books that I bought from Apress during their $7 sale and start working through them. My goal is to get through a book a month in 2019, adding some skills and practicing some of the techniques to see if I can learn some useful skills in this way.

    If you’re not busy today, work on a plan. Outline the time, the money, and the way in which you plan to learn in 2019 and write that down. If nothing else, maybe you want to go through one article we publish each week and practice some of those skills. You’d certainly learn quite a bit doing that in 2019.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Full Stack DBA

    The last couple of years have seen the job title “full stack developer” posted quite often. With the popularity of DevOps, companies are hoping to hire a developer that can work on the database, understand some networking, and continue to build front end applications. In my career, I’ve done all of this while being just titled a programmer, but apparently with more specialization these days, some want to differentiate themselves as being able to do it all.

    I saw this tweet from Erin Stellato, asking if people manage multiple items. Specifically, she asks about “the virtualization, the server admin, the storage, and system security”. No networking, firewalls, etc. in there, but I’ll add those in as well. This week, can you answer this question:

    Are there any of you full-stack DBAs? 

    By that I mean you work on more than the database. Do you manage storage at all? Are you a domain admin with AD responsibilities? Do you manage applications or perform some development? Is there any networking in your daily work?

    I’ve actually done all of these before. At one startup, my primary responsibility was a database developer and administrator, but I had AD rights and needed to help our sysadmin with Exchange and various other servers. I setup and configured our T-1 line to the co-location facility, and explained how to get two NICs in our SQL Server working so that backups and office access didn’t interfere with application access from our web site. I even had to help build new network cables one day.

    In a few jobs, I’ve actually been a domain admin, even though I was primarily a DBA. That was because we shared responsibilities and on-call on the team. Even though my primary work was with databases, I ended up helping work on other systems at times. To me, these were welcome distractions and also chances to build knowledge that was useful in troubleshooting and narrowing down the scope of problems.

    Are any of you still doing that today? Whether you are or not, let us know what types of responsibilities you have at work.

    Steve Jones

    The Voice of the DBA Podcast

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

  • T-SQL Tuesday #109–Influence

    tsqltuesdayThis month’s T-SQL Tuesday host is Jason Brimhall. He asks everyone to write about influence, which is something that I should know about and think I have, but am somewhat uncomfortable writing about.

    That being said, here’s my entry this month.

    Influencing Others

    One of the motivations behind creating SQLServerCentral was to educate and help others. Our goal (Andy, Brian, myself) was to try and find ways that we’d had success, solved problems, or handled challenges and share that with others by writing articles, answering questions, and creating questions for our Question of the Day quiz.

    Across the years as I’ve done that, and I’ve written many editorials, there have been plenty of occasions to meet members of the SQLServerCentral community. Many of them have thanked me or talked about how the site and community made a difference in their careers, which is something I’m quite proud of. Helping others is a form or volunteerism and service, and while this is a vocation for me, it’s also a passion.

    One of the things I think that I’m most proud of us influencing others to also give back and share. I can only do so much, but if I can also convince others to share their knowledge, there is a level of helping and sharing that grows exponentially to everyone in our #SQLFamily. To that end, I have two stories.

    One is about blogging, which I tend to do regularly. I had a friend, someone I met years ago that wanted to start blogging and asked me for some hints and idea. I shared a few things that help me, but also challenged this individual to set a goal for writing. They did, and years later, they have quite a blog. Many of you have heard of this person, but I won’t mention the name here. That’s not important. What is important is they have helped many others and continue to do so today.

    The other story is a person I met at a user group meeting. I was giving a presentation and this individual had some intelligent questions to ask. Over a few meetings, as I talked with this person, I realized they were someone with a lot of talent on the data platform and encouraged them to think about speaking. I did this regularly, and while it took over a year, this person now has spoken at many events, including the PASS Summit.

    It can be scary and intimidating to share knowledge with others publicly, but it is also immensely rewarding and a way of helping others walk the path you have already covered. Perhaps I’ll influence one of you reading today to share some of what you’ve learned with those hungry to learn.

  • Automation at Work

    I do worry about the future of work for large sections of people. When I read pieces like this one in the Atlantic on automation, there are two things that come to mind. First, we are mindlessly sticking with 19th century models of work in many cases. Second, there are opportunities that could dramatically utilize the leverage of computing power to reduce our need for humans in many cases.

    Far too often I’ve seen processes and procedures in place that exist strictly because of historical precedence. We developed some way of working, likely because of expediency. We needed something done, so we found a way for a human to do it. We continue to do it that way, often because of a factory mentality. We don’t trust workers, who come and go, to handle the process correctly, so we specify a way of doing things that we know works. Even if it doesn’t work well.

    What’s amazing to me is that many of us still do this in technological jobs. I find lots of DBAs and infrastructure people that still do an amazing amount of manual work to check logs, jobs, backups, etc. They avoid automation for a variety of reasons, but often because of laziness and fear. They don’t want to think and put time into changing a process, both avoiding coding as well as asking permission. They also fear for their jobs, as shown in the article. Automate too much and maybe the company will replace you with a less skilled, far cheaper worker.

    Perhaps I’m an outlier, but this has never been something I’ve seen in my career. When I automate things and free up time at work, I don’t sit and browse Reddit play chess, as a few profiles from the article show. Instead, I’m more like Gary. I look for, and find, ways to improve other aspects of the company. I help others. I provide more “value” for my salary. This has worked well, even in companies that had a culture of “just do your job.”. There are always a few managers that want thinkers and doers, not just people that mindlessly move through each day.

    Automation is coming, more and more every day. As I look at the evolution of the data platform from Microsoft, the growth and capabilities of cloud services, and even the amazing third party products that free up our time, I know that the bar is constantly raising for the skills we require. What we might have expected only senior level people to do in 1999, we expect juniors to know now. Not everywhere, and certainly plenty of older management is stuck with their historical views of “just do this job,” but times are changing if you seek a new employer.

    I want to see more scripting, more PowerShell, more Bash scripts, more DevOps pipelines, more systems doing tedious work. That’s because many of our scripts and our flows are still rudimentary. They’re basic, expecting the happy paths to work, with limited testing and error handling. Instead, I’d like to automate myself out of work, but then find ways to better script more robust processes, with ways that double check my code is working, and alert me when it’s not. With new responses that are more intelligent than  a simple IF..THEN statement.

    We have lots of room to improve in how we structure systems and code, whether in application development or infrastructure management. Hopefully we’ll all start to embrace more automation, and look for new opportunities rather than being fearful of change.

    Steve Jones

    The Voice of the DBA Podcast

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