Voice of the DBA

Category: Editorial

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

  • Rollback vs. Roll Forward

    The Advocates at Redgate Software had an interesting discussion about deployments in databases and how you go forward or back from the point at which you discover a problem. You can watch the episode, but a few things occurred to me while we were having our discussion.

    The first thing is we all agree data makes things hard. A database is a stateful object, and dealing with stateful objects is hard. That is one of the things I’ve internalized the last few years that has tremendously changed how I work with Redgate customers. The more I consider state, the more I am able to work with the challenges that databases bring.

    The second interesting thing from the episode for me was that each of us had a tendency for what to do. Do you tend to aim to get to a previous state or move to a new state? Each of us had a preference.

    I think lots of us aim for a new state, mostly because we’re optimistic about our ability to “fix” the broken thing. I also don’t think this is a DBA, engineer, or technology thing. I find lots of people in the real world making mistakes and thinking they can do a new thing to fix the situation. Mechanics, lawyers, doctors, plumbers, they all think they can roll forward to a new state.

    What’s occurred to me is that the people I know who are very much in demand for their skills and expertise are often the ones with a tendency to roll back to the previous state. They acknowledge the mistake and undo it. I’ve seen people in construction and other professionals also try to go back to the previous state when they realize they are in a situation where their fix didn’t work, and they abandon that plan.

    In the DBA world, we might prefer this even when our deployment caused data changes. We often will save data, roll back, and then decide what to do. This often means reconciling data, which isn’t a fun task, but a necessary one.

    Watch the episode and decide what your tendency is for adjusting for changes. Do you think about patching the issue and rolling forward? Or do you want to roll back to a known state and re-test our changes in a lower environment.

    Steve Jones

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

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

  • Editorial Republish: Detecting Issues

    It’s the Redgate company wellbeing data, where everyone gets the day off. I’m traveling back from Florida after coaching all weekend, so you get to re-read Detecting Issues.

  • Having a Little Fun at SQL Server Central

    When we started the site, I had never met most of the other co-founders (we went from 7 to 3 inside of a few years). A few knew each other, but Brian, Andy, and I had only communicated through emails and phone calls. We ran the company remotely from Denver, Orlando, and Jacksonville. In fact, I met Brian for first time when he came to Denver for the 2002 PASS Summit (moved from 2001). I met Andy later that year at the Seattle Summit in November 2002. That, coincidentally, was my first meeting with Simon Galbraith, founder of Redgate Software.

    Over the years, we’ve tried to enjoy running an online community in different ways. We wanted this to be a profitable endeavor, but one where we could have some fun. We did this in few different ways. One was with some off-topic articles. Early on, Andy wrote a piece asking Is Steve Jones Really Steve Jones? I still enjoy reading that one today.

    Once I was running the site full-time, and stuck with the Question of the Day and editorial responsibilities, I added a category for humor that I used on holidays and other random times. April 1 was a fun day (and still is), with me trying to write plausible, but completely untrue articles about database topics. I’m still thrilled that my joke from Apr 1, 2005, SQL Server on Linux, finally came true.

    We had a Lighter Side category for editorials that didn’t fit anywhere else, which I and others have used to try and remind ourselves that not everything is about databases and it’s also not the most important things in our lives. We have had a lot of articles on career topics and soft skills, especially editorials, as the guest editors and I know these are some of the most important skills to develop for career growth.

    Thankfully, Redgate has supported some of my fun, as they agreed to pay for and publish a series of crosswords and cartoons over the years.

    Perhaps the most fun I’ve had over the years was running the SQL Server Central parties at the annual PASS Summit. In exchange for promoting the event and getting people to register with our code, we got a small payment for each person. This started in 2002, and we decided not to take this money as profit, but rather to have fun with it. Each year we’d get a few thousand dollars from referrals, so we tried to be creative. We gave away books and shirts the first year, with a line stretching out the door during the welcome reception. In Florida in 2003 or 2004, we decided to have a video game party with XBOX consoles. We not only purchased consoles, but also TVs, and gave everything away at the end of the night to random people.

    Somehow, I stumbled on the idea of a Casino party one year and contracted with a firm in Seattle. We ran those parties for years and even charged admission for people who hadn’t used our code. I would guess how many people would come and then go shopping at Best Buy when I arrived in Seattle, spending a few more thousand dollars on random prizes to give away. I’m sure we lost money in a few of those years, but it was all for fun.

    Maybe one of the most memorable things I did was for TechEd in 2004 or 2005. We wanted to brand ourselves and try to raise awareness of the site. Since I was in charge, I ordered 3 different styles of Hawaiian shirts for each of us, with a SQLServerCentral logo and name embroidered on each, intending to wear a different one each day. Andy and Brian were good sports, going along with me most of the time. There was a day Brian refused to wear my choice as it was a little too out there for him.

    However, I did meet Euan Garden (RIP) for the first time there and he loved our chili pepper shirts. I arranged for a shirt to be made and shipped to him and I loved seeing him wearing it at a events over the next few years. I also got inspired to do an interview series, which I really enjoyed.

    Thinking back on the history of this business, I’m both amazed by how it changed my life, and I can smile at so many good memories. Hopefully, you feel the same way.

    Steve Jones

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

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