Voice of the DBA

Tag: career

  • T-SQL Tuesday #196: Taking Risks

    This month we have a new host, James Serra. I’ve been trying to find new hosts over the last few years to keep this party going and to expand the ways in which people look at database work.

    There are definitely less bloggers, but in the age of AI, I think the more you can stand out and show that you add value, that you think about things, that you can spot AI mistakes, the better off you are, so keep blogging an encourage others to do so.

    This is a great invite, and I’ll give you my response below.

    A Big Leap

    I had changed jobs a few times after I moved to Colorado. I worked at an established small company, which was still a bit of a startup, and after sleeping in my office 8-10 times in a year, I looked for another job. Another startup, which failed, left me looking again. I got a job at JD Edwards, which turned into PeopleSoft after an acquisition. I was promoted, and in a good place.

    At the time, I’d been running SQL Server Central on the side with Andy and Brian for a couple of years. We were making it work, but it was stressful in that we spent time at night, on weekends, and during breaks keeping it growing. We were feeling the stress and decided someone needed to work at it fulltime. We’d made a big sale, so we had some cash to give us stability, but if things went poorly, this was about a half a year’s salary for any of us.

    We debated it a bit and I decided to make the leap to working for the company fulltime. I took a small pay cut to do so, but we expected a monthly dividends to make up for most of the decrease in pay. Not all, but most. The main reason I decided to make the leap was that my wife was working fulltime and provided our health benefits. That was a cost Andy or Brian would have needed to shoulder themselves.

    This was a risk. At the time, I worried about my skillset. Would they atrophy? If this didn’t work, could I go back to work as a consultant or fulltime DBA? Would I miss out on the learnings and growth that come from being involved fulltime in projects for an organization?

    Looking back, it doesn’t seem like a big risk, but at the time, in the 2003 timeframe, it felt like a major leap away from the security and stability of corporate work. Sure, I’d changed jobs in the past, but I always had a strong track record of delivering results in a position. I was giving some of that up and the longer I was away, the more I was worried about coming back.

    Over time I realized that a lot of what I do here with testing scenarios, mocking situations, and working through the challenges people face is the same type of work that I would do in a corporate environment. I don’t have the pressure from a manager, but I often put that on myself, so it’s very similar.

    This was a calculated risk, but still a work. Fortunately, it was a one that worked out well.

  • Writing as an Art and a Job

    I remember listening to an interview with Rick Reilly in the mid 2000s. He was the back page columnist for Sports Illustrated for years as well as a writer in various pieces. He talked about how he would lay on the couch in his office sometimes, trying to think of what to write. His kids would come in looking for attention, but couldn’t understand that Dad was “working”.

    I had been writing the editorials at SQL Server Central and I could relate. Moving from 2 to 5 (eventually 6) editorials a week was a lot of work. It was stressful in a way I couldn’t imagine when I started writing them. I quickly realized that if I had to produce a new one every day, I was in trouble. There would be days I’d struggle. I needed to have a queue of pieces at least partially ready if I were going to manage this job and find balance with my family.

    Recently I was listening to an interview with Lee Child, who writes the Jack Reacher series. He said that writing is both a creative endeavor and a job. It requires some inspiration and time, but it also requires you to buckle down and get to work. This is an area where delays are inevitable (everyone gets writer’s block) and if you aren’t thinking ahead delays will occur. Delays aren’t great for newspapers or other scheduled events.

    SQL Server Central became a newspaper.

    One of the things I did early on was start to enhance my powers of observation. There’s no magic here; it’s really a habit to look at things in your life in a different way. For me, this meant considering each question posted on the forums, each bug reported in SQL Server, each complaint/criticism/success through the lens of both telling a story and generalizing the wider issue.

    I learned to write about what I experienced by seeing the experience as a source of inspiration.

    I started keeping notes. First in a text file, then OneNote, then Evernote, and today, Joplin. As I would see something interesting in the world, I’d make a note, copy a URL, write a sentence or two. I then regularly go back and flesh out these ideas and add to them. It’s similar to the recommendations I make for blogging: make notes, expand those later.

    The job part of this was making time to write on a regular basis. I used to try and write every day. I had some success, but I also learned some days I struggle to articulate my thoughts. Rather than struggle, I learned to just abandon the effort and go do other work, or sometimes, go to the gym or get away.

    The flip side of that is that when I feel the writing is flowing, I write more. I don’t stop after one editorial (or blog) and I’ll try to tackle another one or two. If I struggle with one topic, I may find another easier, so I flip through notes and keep trying to get another one when I am in the mood to write. I sometimes find I can write 3 or 4 in a day and then not do much writing for another few days.

    Many of you reading this do technical work. You work on systems, or in code, or both. However, the world is changing. I started this piece with the 25th anniversary of SQL Server Central in mind, but really, AI is front of mind. I’ve had 3 conversations today about AI stuff, and the one thing that stands out is communication and clearly expressing yourself if crucial to getting AI to work well for you.

    Learn to write better. It helps in your communications with humans and with AI LLMs.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Engineer Lessons

    Many of you reading this have a number of years working with technology. You might have 1 year or 20 years, but you’ve likely grown and learned along the way. Some of you may also know someone who has several years of seniority in a position but not that many years of experience. In this case, a person might have been working at this job for 5 years, but they really have one year of experience that’s been repeated 5 times.

    That’s been a common complaint over quite a few years from people who interview others. They find candidates often have very limited experience, yet are applying for senior roles. These candidates are ones who have just a few years of experience, but have ended up repeating those few years over and over.

    I ran across an interesting piece that contains 21 lessons from the author’s 14 years at Google. You might not think Google is the place where great software engineering takes place, or where great careers are made, but Google has been a place where it is challenging to get a job, they work on truly large-scale problems, and Google has had many engineers who have gone on to success elsewhere.

    The first few lessons in here are things that I’ve learned in my career. Quite a few of them point to the value of being a team player, and remembering that being effective and efficient matter. It’s easy to be smart, or depend on one’s code to speak for our ability, but in many cases, we are working in teams. Our code is a team game, and others need to understand our code. It’s easy to forget that someone responding to a problem at 2 am might not understand the code. It’s also easy to forget that person might be you, and you might get confused.

    Others also need to understand and believe in us. Lessons 2, 14, and 16 talk about the value of working with others and not creating resentment or ill will in others. Even with AI help, most software will require multiple people working together, so building those skills and habits is important.

    I found this to be an interesting list, and there are other topics I want to discuss in the future, but the main thing I see here is that these are lessons from someone who has had to work as a technical engineer with others, while having success both at his job and outside of it. That resonates with me, as do these lessons. Individuals and teams that work in similar ways to those described in the piece have tended to have more success than those that don’t, at least in my experience.

    Learn to be a team player as an engineer, developer. DBA, or any other job, and you will have more success than if you expect to only be judged on what code you write.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • The DBA is Dead; Long Live the DBA

    I remember getting a job at a startup in the Denver Tech Center. This was shortly after SQL Server 7 was released, with a marketing campaign that the platform was auto-tuning and wouldn’t require a DBA. My colleague asked me if I wanted to learn Cold Fusion and have a longer career. I declined and stuck with this SQL Server thing, which has seemed to work out pretty well over the years.

    I was reminded of this when I saw a “Death of the DBA Again” post, this time from an Oracle DBA. There are plenty of links in there from Larry Ellison and Oracle about how some version of Oracle won’t require a DBA. I’ve seen questions on Reddit (and elsewhere ) about this topic where people seem to think DBAs can be replaced.

    Or maybe they want them replaced.

    There are no shortage of posts on why this isn’t the case (Grant, Kellyn, Brent, William, Boris). These all look slightly different, but the main thrust is that there is still data management-type work and people are needed to do it. Or maybe to direct the AIs to do it.

    An interesting post from Kendra last year that we will see less DBA jobs because good DBAs can leverage AI to replace a few less-good DBAs. I like her approach, and the key reason why AI agent usage will grow is that they can potentially just make less mistakes than a human.

    If that human making mistakes is you, then you might not have a job.

    I do think that the DBA as a gatekeeper or a single point of managing systems and ensuring backups/security/patches are made is dwindling. However, there are still lots of places for database-related work. High Availability setups are needed; someone has to work with InfoSec and auditors and implement their requirements. That might be especially important as those requirements might not be clear and clean enough for all your systems. While ETL might be a thing of the past with the various “links”, without a doubt, people will link too many tables to analytics systems, leading to overloaded systems, too many resources being used, and costs being too high.

    That might be a reason we will still need some type of DBA. They need to field the complaints from budget holders and work on resolutions to reduce costs.

    The DBA will continue to exist in many organizations, but the job will change, and you need to evolve. There might be other organizations that don’t want a “DBA” as a title, but they will need a data engineer, a full-stack developer spending more of their time on the database stack, an InfoSec person that mostly works on database security, or some other job that absorbs all the data-related chores.

    There is a lot of opportunity still out there, but the bar is being raised, and one end of that bar rests on AI. Improve your skills, show your value, and become someone who delivers results and doesn’t just say “No.”

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.