Voice of the DBA

Tag: career

  • Would You Retire Rather Than …

    Bjarne Stroustrup is the creator of C++. I read a few of his books and alternately loved what he’d done with the language and hated having to write C++ code in university and at a few jobs. I found it tedious and hard, though arguably better than C once you had a decent set of classes structured. BTW, I love his website, the basic text view of the world, which is how I have built a few sites on my own.

    I caught an interview with him and this short response on AI and coding. He had this quote: “Senior developers are already retiring rather than deal with it.” He doesn’t love the results from AI, which is fine. And it’s not what I want to talk about today.

    The idea that senior developers, presumably like Mr. Stroustrup, would rather retire than work on codebases that are being changed by AI is interesting. I suspect that in some problem domains, you might hate AI code and not want to deal with it, but would you retire? Is that the answer?

    I have known some IT people who retired because they didn’t like their jobs. My wife left tech because it was too stressful, but it wasn’t an easy decision. She’s questioned it a few times, but she had a passion for something else and wanted a new job. I think that in both cases, someone moved towards something rather than away from something. They had another thing they wanted to do in their lives.

    I wonder how many of you would really retire or leave your job because you don’t like the work. Most people I know who don’t like the work are looking for something else to do until they retire. I would be sad to hear about someone who is hanging on to a bad job until they retire, especially if retirement isn’t coming soon (like the next 2-3 years). I would also hate to think that some people see AI as making their job so un-enjoyable that they decide to retire earlier than they expected.

    I do have a good friend who was close to retiring in his early 60s. He decided it was too soon and took another job after his previous employer was sold and closed their local office. He’s spent a little over a year working remotely and he doesn’t like it. He’s going to retire this year because he doesn’t like the job and doesn’t want to look for a new one. He is close enough to retiring that he’s looking to the future doing less and finding a way to enjoy life without work.

    AI might force some people out of the industry, but I think it’s more likely that there are other factors, like a poor work environment, bad management, or some other factor. However, if you disagree, let me know. If you would stop working because you don’t want to deal with data or technology, let me know. As always, if you don’t want to post publicly, message me and I’ll post something anonymously for you.

    Steve Jones

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

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

  • There’s Too Much to Learn

    I remember getting started on SQL Server and trying to upskill myself in the mid-1990s. At that time, my employer was running a SQL Server 4.2 instance for a third-party application, but we wanted to rewrite our internal bespoke sales app to run on SQL Server. We were upgrading from Foxpro to Visual Foxpro and looking to move from shared dbf files to a SQL Server. There was a new release of SQL Server 6.5 during our development, and I wanted to learn more about it. I purchased Inside SQL Server 6.5 and read the entire thing, getting prepared to finish development and then manage a new platform in production.

    I had updated copies of that book as SQL Server released new versions until SQL Server 2005. When that came out, there weren’t one, but rather 4 books to cover the Inside SQL Server details (Programming, Query Tuning, T-SQL, and The Storage Engine). A similar thing happened with the SQL Server Bible, which grew in size to over 1400 pages for the 2012 version. It was a backache in a book if you put it in with your laptop.

    Since then, the growth of the Microsoft Data Platform, which includes SQL Server, has been incredible with lots of changes not only to the box/on-premises product many of us install, but to the related systems in Azure. The SQL variants, Fabric, Power BI, Azure Data Factor, and more. It feels like there is way too much to learn  I know I can’t keep up, and I expect most people feel the same way.

    Coping with the load and the accompanying imposter syndrome is hard. It’s hard on your psyche and it’s hard when others in your organization, especially your boss, expect you to understand how to work with T-SQL, even when they might refer to SQL Server in one request and SQL Database in Fabric in another. They might even expect that you know “everything database-related”, including how to troubleshoot their Azure PostgreSQL Flex server performance issue.

    AI can help, as can some strong Google skills and an eye that spots the information you need. Whether to do actual work or help guide an AI LLM along a path. I would argue that improving your ability to differentiate what’s better from what’s worse is becoming even more important in the age of vibe coding. Even if you aren’t a YOLO, let-Claude-Code-do-it’s-thing, others are and they’ll call you when they don’t get the results they want.

    Or when their system performs poorly against your database system. Who knows how many implicit conversion issues or RBAR pieces of code an LLM will write. There’s a lot of that sample code out on the Internet, and much of that code goes into training these models.

    I don’t have a magic solution for keeping up, other than build the habit of learning. Practice new techniques, play with code, conduct experiments in the things that plague your environment, or that you see others working with. I don’t mess with Hyperscale much as I don’t see it with customers, but I do see other technologies, like System-versioned tables. So I spend time there, learning what works well and what doesn’t. Those are the skills that help me keep up with the knowledge I need to work with LLMs and humans.

    Steve Jones

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

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

  • Half of All Engineers

    The AI LLM boom seems to show no sign of slowing down. Each time I think we’ve reached some level of crazy use or predictions, things take another turn. I still find myself pinging back and forth between this will be amazingly good and horrifyingly bad.

    Sometimes on the same day.

    Today, I’m a little more down on AI. I was listening to Steve Yegge on the Pragmatic Engineer podcast, and they were discussing the curve of AI usage at companies. He points out that he’s mad that Amazon let 16,000 engineers go and might let more go. He worries that companies might let 50% of their engineers go. Not necessarily because the top 50% will be more productive with AI than 100% of engineers without it. Rather the concern is that companies will get rid of half their salaries to pay for the AI tokens for the other half.

    Steve Yegge is an accomplished software engineer that has worked at Amazon and Google. Steve wrote Gastown and has been someone who not only is successful at producing code but also thinks a lot about how we produce more software.

    How coordinated and powerful are the new models? Can they really do a lot of software work that we do today? Steve thinks so, but to be fair, he’s got a lot of experience and can architect and design software well, which means he can also guide AI LLMs and agents to write more code. He also thinks the latest models, like Opus 4.6, are way more capable that most people believe.

    I also caught this post on X about a paper predicting that AI might cause economic collapse as less knowledge workers are used in various tasks. This might happen faster than we can absorb those workers who are laid off in the name of AI back into the economy in other positions. It’s a scary thought.

    The positive side of this, at least from me, is that so many organizations move slower, and so many people aren’t extremely competent software engineers, so we’ll get a lot of bad software written by non-technical people that doesn’t scale. We’ll have more database (and application) performance issues, and that will slow the use of YOLO, vibe coding.

    Plus plenty of companies just aren’t implementing or looking to pay for lots of tokens. They’ll just move slower and the world will change, but not anywhere near the pace that Steve or others think it will. We’ll see, but let me know what you think.

    For a more positive spin, I’ve been reading Reshuffle, which is a little less depressing about the future.

    Steve Jones

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

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

  • Acting with Confidence

    Recently, I saw a graph about making decisions that showed the impact of both reversibility and consequences. Here is an example of such a graph and how one might approach decisions. If things are easily reversible or have a low consequence, we tend to make a decision and move on. Or we are willing to make a decision. One of the examples of such a decision was choosing what to wear out to dinner. It’s easy to change, and (in general) of little consequence. Choosing to send a large amount of money to someone through Venmo (or some other mechanism), can be hard to reverse and have substantial consequences.

    This made me think of some of the DBA and developer decisions I’ve made in the past. When we work with databases, the changes we make can have a large impact and be quite consequential to our organization. Downtime, data quality, etc. could all impact revenue, profit, reputation, or even future prospects of survival. That can be a lot of pressure when you are deciding to refactor a data model or adjust a lot of data during a deployment.

    We might think we can rollback or undo changes, but often we would end up applying reversing transactions. If I change a data type, the data is changed ( assuming the DML completes). To change back, I can’t roll back outside of a restore. I would change the type back and have an equally large and long transaction run. Having HA or replication technologies in the mix can dramatically impact the scope of both the initial and reversing transactions.

    How confident must you be in your actions before you undertake something of consequence? Do you require an easy rollback, or are you willing to act even if the rollback is painful?

    Maybe a better question is how do you appraise the consequence of an action? Is it the application/database or perhaps the data? You might consider all the dependencies from other applications or pipelines on this. I know many DBAs worry about the performance impact of changes that can slow or stop other work. I constantly see people asking if Flyway can estimate how long a change will take, especially when dev/test environments are a poor representation of production sizes, scales, and workloads.

    If you have a 2GB database, you might just make changes. A restore is quick, and I’ve often found greenfield applications taking this approach since the data sizes are small and even consequential actions can be undone with a restore operation. Many of the “code-first” technologies work great in these situations, but once we have multiple application dependencies and large data sets, restores can be non-trivial or even unacceptable ways to deal with issues.

    The image linked above talks about gathering data and analyzing, which sounds like the prudent thing to do, but this can be easier to say than do in practice. Deciding what analysis to undertake and how long to spend on it are the real tricks. Those are the judgment calls that only experienced humans can make. While AI might help, this is an area I really want capable humans with the final say.

    Steve Jones

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

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