Voice of the DBA

Tag: career

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

  • Learning From Breakage

    I’ve had the fortunate, or maybe unfortunate, experience of being thrown into a few jobs with no training. At a couple of my bartending jobs, I had to start working without any training, calling over someone to help run the ordering machine while I made and served drinks. I managed to slowly learn how things worked throughout that first shift, so I was ready to work on my own the second night. I had a similar experience at a tech job, starting as the lead DBA/IT Manager in a crisis, having to try and solve problems after ask others how things were supposed to work. I ended up fixing a bit of code, adjusting networking, and directing others on my first day.

    When we have a crisis, we often learn a lot from the situation. I’ve been through crashed upgrades, virus breakouts, hardware failures, and more in my career. While each was stressful and often not enjoyable, I learned a lot each time and came through the incident a more capable developer/DBA/whatever. When we work through a tough time, we are often better equipped for the next time something goes wrong.

    I ran across a great piece that says you never really know a system unless you’ve broken one. This is Tim O’Brien, a software architect who has learned a lot about databases from failure. In fact, I love his interview question for data professionals: “tell me about the worst database schema you ever created. What did it teach you to avoid?” I’ve certainly learned a few things over time from my schema designs, but those are stories for another piece.

    The piece draws parallels to today’s use of GenAI technology and vibe coders who seem to have success that they highlight in posts without discussing the problems. I do believe AI technology is going to make a lot of things easier (and faster) to build and then fix when they break. And they are going to break, partially because AI tech might not do a great job, and partially because we might not direct it well enough. Clear communication is key when working with AI.

    I’ve started to build some skills with AI, but as I try to tackle more complex tasks or scale up my work, I realize that I often don’t know enough about either the problem or AI technology, and I’m going to make mistakes. I’m going to break things and then have to fix them, or more likely, learn how to get the AI to reduce the number of broken things in some way before I have to take over.

    And learning to take over might be the number one skill with AI tech, but that’s something that you will only learn from the AI not working well for you in a variety of situations.

    Steve Jones

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

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

  • Where Your Value Separates You from Others

    I ran across a post that discusses what makes you a senior engineer (via Brent Ozar). The main point of the post is that there is a core skill that separates senior engineers from others, which is reducing ambiguity. When a senior engineer gets an ill-defined (or ill-communicated) request, they can deliver a solid, or even great, result.

    When someone says “performance is poor,” what do you do with that? Can you build a plan to identify the issues and solve them? Or do you expect the customer to explain what is slow and why it’s slow? Do you ask what metrics they have showing things are slow? A senior engineer can ask questions to find the problem and then determine how to move forward.

    The post also discusses the way many companies hire senior people, often basing decisions on years of experience and answering specific questions in an interview or on a test. It’s hard to interview and test a person who is given a vague requirement and develops a solution. Most interviewers don’t want to have to wprl that hard and compare what might be very disparate answers to ambiguous questions. How can you judge two people who give very disparate answers to questions with no clear answer?

    It’s hard, and I know this because when I’ve run interviews that lightly describe a situation and let the candidate lead me to the next question, so that I can see how they work and think. It’s very hard to judge the end result and rate the candidate as effective. Often, I find myself deciding if I like the person more and if they fit in our company. That’s if I think they can probe to find information and make decisions when that information is incomplete. If they can’t probe and find a way to solve the problem without direction, that’s an issue.

    And that really is the senior skill. In all fields, not just engineers or DBAs. Managers, customer service, analysts, and more. Can someone handle an unstable atmosphere and clarify, identify, simplify, and present a way forward? If they can, then they are likely someone to consider for a senior role. They still need expertise in their area, but can they get things done when they aren’t being directed?

    Are they self-starters?

    That might be the main thing I consider for senior people. Can they drive themselves and get things done, things we need done, but without a lot of direction and hand-holding? If a senior person struggles to move forward without more direction or supervision, then maybe they aren’t really a senior-level employee.

    Steve Jones

     

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

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