Voice of the DBA

Tag: career

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

  • 25 Years of SQL Server Central

    The oldest article we have on the site is Tame Those Strings! Part 4 – Numeric Conversions, by me. It’s dated 2001-04-18, though I think that’s a date we picked when we converted all the content from one database to another. The founders agreed sometime during Feb 2001 to jointly run SQL Server Central. Since we each owned the copyright of our articles from another site, we migrated several articles to build up our content library. This was back when Andy, Brian, and I all had full-time jobs and managed the site during breaks, nights, and weekends.

    That was 25 years ago.

    Twenty. Five. Years.

    It’s incredible to think that almost half my life has been spent working with this community. That joint effort morphed into a full-time job for me sometime in late 2003 or 2004. I took a pay cut to run the site, though as we grew from one to two to five to six newsletters a week, we started to make enough money to make up the difference. I was a horrible salesman, but fortunately, we had a great site that kept growing week after week, and we didn’t need to rely on my salesmanship. The site grew from dozens of users when we started to thousands in a few months to tens of thousands in a year. Eventually, we reached a million registered users, which was quite a milestone for us.

    Apart from the site, we published books and gave out copies at our annual party during the PASS Summit. That party was one of the highlights of my year. We also used to publish a magazine in partnership with the PASS organization. That was a stressful time, with me trying to manage an every-other-month schedule for the magazine, which had to be laid out, printed, and shipped to subscribers. While that was going on I had to keep a couple of yearly book projects going and still get daily articles published.

    I started writing these editorials because I was a little bored with the job. I never imagined how popular these pieces would become and how many people would read them. I suppose I should have as I was the one who negotiated and paid for our emailing software. We used to pay for Lyris Listmanager, which cost a few thousand dollars when we started. As we grew, we needed to send more emails overnight. One year I received a quote from Lyris for a few hundred thousand dollars to add the additional sending capacity. When I called the sales rep, he told me the only small companies sending more emails than us were the porn people. Needless to say, Andy took that as a challenge, not wanting to pay hundreds of thousands of dollars for email software.  we designed a system using an SMTP component that would let us send a lot more emails. At our peak, we were sending over 8 million emails a week.

    I had to learn a lot about running this site, from SMTP tricks and the how CAN-SPAM act applies to negotiating advertising contracts with customers. I had to manage hosting locations in the early 2000s. We first rented a VM, but they were too small after about six months. We moved to the house of a friend of mine, where he had 3Mbps broadband connection (this was 2002). At the time, I only had an ISDN connection, which wouldn’t cut it. We migrated through a few different co-location facilities in the Denver area that I had worked with as a corporate employee. Those moves entailed me physically moving servers into cages (or partial cages) in cold rooms, re-configuring our switch and firewall, and ensuring everything connected to the Internet. I even had an account at Dell as we regularly upgraded hardware.

    When we sold the site to Redgate, some of those hassles went away, and I could focus on just being the editor of the site. I no longer had hosting responsibilities or even coding ones. Things were good and bad with that change . Good as I had developers to whom I could send bugs, but bad in that they had other, higher priorities. In the last few years, I’ve struggled to get things enhanced or fixed on the site, though I’ve been promised that is changing this year.

    Despite all the changes over the years, I’m still thrilled to be the editor of SQL Server Central and glad that Redgate continues to run and support the community. Most of my time is spent doing other work with Redgate, but managing this site continues to be a significant portion of my work week.

    And I still enjoy it.

    I want to thank everyone who has read an article, asked or answered a question, syndicated their blog, tried the Question of the Day, written an article, or just left a comment on a piece. This has been an amazing community where many of you learned to be a better data professional. Lots of you asked, debated, and shared your knowledge with others in an extremely neighborly way. It’s been a joy to see this community grow into one where we appreciate, value, and love each other. I’ve made many friends here, met many of you in person, and seen you get a value from this community that cannot be measured. The success of this community is because of all of you.

    I’m blessed to have joined you here for 25 years, and I look forward to many more.

    Steve Jones

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

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

  • Deep Learning and Craftsmanship Matter

    There’s concern about the future of AI and how it may affect jobs and employment for the masses. I see plenty of people on both sides of the issue. Some are sure AI technologies won’t replace people; some are concerned their jobs will be eliminated, and some are hoping that we will eliminate some jobs and create many more.

    Sometimes that’s the same person.

    A GenAI can replicate a human, or maybe more accurately, mimic one. That might work well enough for some people to trust the technology more than humans. Or maybe it works well enough, enough of the time, and lots of us are OK with well-enough. After all, I think a lot of us already work with “well-enough” or “good-enough” code on a daily basis.

    However, the GenAI is based on what other humans have already done. It’s “trained” on lots of existing ideas, decisions, codebases, etc. It can recall and use those quicker, and often as well as many humans. It might be a light craftsman, but it can’t be a great one.

    Humans will be able to deeply understand problems and create better craftsmanship for many systems. Across time, an AI can learn from these craftsman and repeat their work in other systems, but an AI will often struggle to understand the entire context of whether we would apply that solution or a slightly different one this time.

    That’s the human advantage. Deep learning and craftsmanship will differentiate us from the AIs because we can contextualize things better than an AI. Or really, we can internalize the context better than another human can express it to the AI. That will be the difficult part of working with AI LLMs, agents, and whatever comes next: explaining what is really needed in a new situation.

    Communication is hard. Because many humans aren’t good at communicating, they won’t be able to use an AI to replace other humans. They’ll struggle with the results, and they will need to hire a craftsman to help. However, that also implies that more of us need to become craftsmen, not only for the advantage it gives us over AI, but because those skills will help us better judge AI output, as well as express what we want to see the AI do.

    There will be lots of work in the future, even with AI, but I also believe that the jobs that are desired, that will pay better, will go to those who learn to use AI tech and who can judge when the quality of the work is appropriate for the situation.

    Steve Jones

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

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