Category: Editorial

  • Is SQL Server Feature Complete?

    I heard Brent Ozar recently talked a bit about the SQL Server platform and its future. He also mentioned that Fabric has distracted the data platform team and it isn’t a great product. I tend to agree, and I see too many bugs, holes, and problems. However at the end of this short snippet, he talks about SQL Server with an interesting comment.

    Is SQL Server feature complete?

    That was Brent’s opinion, which is one that I tend to share. I think that the platform is very feature-complete. There aren’t a lot of things I think I really need in order to choose SQL Server as my database. I wish some functions (FORMAT, MERGE) ran faster, and there are a few items (AGs, replication) that could be easier to work with or were more robust under load. However, overall, SQL Server runs well.

    It’s a good choice, there is mature tooling available to help, it’s well understood, easy to administer for the most part, and there are lots of people that have experience on the platform. There are ample reasons to choose SQL Server as a solid relational database platform.

    At the same time, if the product is feature complete, then that gives PostgreSQL, MySQL, and assorted other platforms a target to aim for and potentially displace workloads at a lower cost. Even if the features aren’t quite the same, a much lower cost can be enticing.

    That ignores the cost, often a very high cost, of switching platforms. However, I do see plenty of people investigating other platforms, not to migrate or move, but for new work. That makes sense, and I suspect that is part of the reason that Microsoft keeps trying to raise the bar with new features. I’d prefer they focus more on stability and performance than new stuff, but I get that doesn’t always sell well.

    Are you happy with SQL Server? Looking elsewhere? Ready to learn a few platform? Let us know today.

    Steve Jones

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

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

  • 50 Years of Microsoft

    I get the Gates Notes email periodically and I always find it interesting to read. Like Bill Gates or not, he is a very smart individual and has thoughtful things to say. Even when I don’t always agree with him, I enjoy hearing his view and have enjoyed seeing him deliver presentations. In fact, one of my career highlights was at SQL Saturday #175 – Fargo, held at the MS campus. Bill Gates was speaking to employees that day and we were allowed to watch the Q&A from the balcony. Later, I saw him start to leave and stop by a sign. He asked someone about SQL Saturday. When they explained the idea for free conferences, he said “that’s cool.”

    One of the recent emails talked about the 50th anniversary of Microsoft, with the original source code available for a BASIC interpreter. It’s an interesting read to me, since I learned BASIC first (and a little assembler) on an Apple II and a TRS-80. I didn’t start a company, but I certainly appreciate the excitement of tackling a programming challenge back then when memory and disk were in short supply. Most of my early programming tasks had me worried about how much memory and disk I was using, trying desperately to minimize both.

    My first real exposure to Microsoft technology came after college, while working at a power utility. We had DOS desktops and were just starting to look at Windows 3.1. Until that point, I’d mostly lived in the Apple II space and then the mainframe/Unix space. I coveted a SparcStation with SunOS and had to settle for a PC architecture because my newly graduated budget wouldn’t support anything from SUN.

    I adapted to DOS and grew to enjoy the challenges of early Windows. I adopted Win95, learned SQL Server (OS/2 and Windows NT) and the rest is history for me. I’ve been using Microsoft technologies for 33 years now, and I’ve enjoyed the time using those tools. I also appreciate the great career that Microsoft gave me.

    Looking back at the times I had to work with autoexec.bat and config.sys files, when I used the probe account in early SQL Servers to check configurations, learning to track and read disk configurations for SQL Server 6.5 restores, moving from Windows NT 3.1 to 4.0 to the more modern architectures of Windows 2000 and beyond. Watching the “Visual” series of development tools and the Win32 API evolve into the .NET namespaces and the introduction of PowerShell to give us an easier way of working with non-compiled scripts. These are fun memories for me to look back on.

    Most of you reading this likely use some sort of Microsoft technology. What good (or bad) memories do you have?

    Steve Jones

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

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

  • The Return to the Office Debate

    At the end of last year, I ran into a friend I hadn’t seen in a long time. We were chatting and this person mentioned that they were looking for a new job. They had been laid off and needed something. This is someone with a lot of experience and skill, so I wasn’t worried for their career or future. At the time, they mentioned they had gotten an introduction and interest from Amazon, but they weren’t interested in a position because of the return-to-the-office (RTO) mandate that Amazon was implementing.

    I was recently chatting with another friend at a different company. This person manages a tech team, and was looking to hire another data engineer, but was told they could only hire in a certain city (City A)  in the US. In this case, it was the city with their main office. They have offices in a few cities, and a large one in City B, but the organization has been thinking of their own RTO plans and has limited hiring. My friend is now wondering if they need to consider moving to City A (not likely) or find a new job. They don’t want to have to go to the office every day in City B.

    Over the last five years, we went through a pandemic where many people moved to remote work. As we’ve come out of that ordeal, lots of organizations have questioned how to structure their workforce moving forward. Some want to have their staff in the office, some want to remain remote, and there are lots of reasons behind each approach. There is evidence that people can be productive remotely, and there is evidence that groups can be productive when they are co-located together. Inside most companies, there are wide-ranging opinions and desires on office work, from both management and workers, and there is no consensus on what works best.

    Tech professionals certainly can work remotely. They can also see benefits from being in the same office. The efficiency of their work habits can vary depending on the day and situation, so it’s not easy to decide how remote or how in-person someone should be, even week to week. It might depend on the job and tasks. I enjoy my commute down the stairs each day, but I also find the office invigorating. I like going to the office, and I think I’d go every day if my job required it. I’d get less done for the company each week, but I’d do it.

    How do you feel about remote work vs in office work vs hybrid? Do you have mandates? Would you look for another job? These are questions I see many people asking themselves these days as executives start to make new rules about their workforce. I don’t know there’s any good answer, but I am curious what many of you think. Leave a comment in the discussion below.

    Steve Jones

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

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

  • Staying Employed

    The revolution with GenAI has been quite the ride since 2023 and quite a few people have been concerned that their employment status might be in jeopardy. I can certainly understand that, especially in light of the tight budgets, widespread layoffs, and executive views on AI technologies.

    There was an article recently talking about AI taking over some jobs with a few tips on how to stay employed. While tech workers weren’t mentioned as being vulnerable, repetitive data-heavy jobs, such as data entry clerks, telemarketers, and cashiers were. That last one is interesting. Lots of companies have tried to use automated checkout stations, but this hasn’t necessarily eliminated cashiers. Maybe there are fewer, but lots of companies in the US have rolled back some of these efforts as fraud, mistakes, and slower checkouts have been an issue.

    The data-heavy group might include ETL developers for sure. I suspect this is an area AI is well suited to help build flows, map data, and handle updates more easily. This won’t eliminate the need for an ETL developer, but it might reduce the number needed and certainly reduce the skill level required to code data movement scripts.

    There are lots of jobs that might not be vulnerable, including tech people who work on AI, cybersecurity people, and others. I think DBAs aren’t likely to go, though perhaps we will need fewer DBAs and developers over time as AI models become more capable of repeating work.

    The tips for navigating this new world aren’t anything different than my advice for years. Improve your skills, both technical and soft. Learn new technologies, but more importantly, show that you add business value with your work. Don’t depend on someone else to tell you what to do. Learn what things are important to your boss and organization and tackle those things early and often. Work to be an effective and efficient worker wherever you can and learn about your business. Those skills and that knowledge make you more valuable than most AI models.

    Steve Jones

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

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