Voice of the DBA

Category: Editorial

  • Enriching Your Life

    As I was looking to build career goals for the new year, I think mostly about technical topics. That makes sense, given my focus and job, but I ran across an interesting thread on Hacker News that asked about skills to work on in 2020, and not necessarily technical ones.

    I did find it interesting that one of the first comments was self improvement, and quite a few comments on cooking, both as a skill to learn and a way to save money. There are plenty of comments on other non-technical skills, but since this is a technical site, I wanted to focus there.

    We’re over a third of the way into the year, and we’re dealing with a pandemic. Business is slow, many people have lost employment, and it’s possible many more will. Fewer companies are hiring, so there is a need to stand out more if you find yourself looking for a new job.

    With that in mind, what types of things would you work on if you knew you’d need a new job by the end of the year. Let’s say that you have seven months to prepare to look for a new job on Jan 1. What would you work on?

    Leave a comment and let us know today.

    Steve Jones

  • The Build Book of News

    Every year Microsoft has held the Build conference for developers. I’ve been lucky enough to go a few times, and I was hoping to get the chance to attend again. With the pandemic, the entire event went virtual, and was held across 48 continuous hours. I was slightly disappointed as a few sessions I wanted to see were early in the morning or late at night, but I am sure most of these will be available on demand later, so I can watch them if I wish.

    One of the things Microsoft has done is produce a Build Book of News, a 55 page PDF book of all their announcements and changes. You can download it from Paul Andrew’s blog, or you can look at the announcements online at Microsoft News.

    I randomly watched Build on and off this past week, having some of the sessions in the background while doing other things. There certainly were some interesting sections, though not a lot of data platform focus, but I found a few items that you might like.

    We’re all remote now, or the majority of us are, and I can see that remote tools are
    important. I know there has been some remote code work in Visual Studio in the past, but I didn’t think many people would use it. Now in watching some of the remote code demos, I think these tools might be interesting, especially when a few people are trying to debug a crisis situation. Being able to see the code on my own machine, and seeing what others might change or think is a better (or worse) solution could be very helpful.

    The mobile GitHub tools for review are getting better, and that’s good. Since it’s likely more of us might be in different locations, on different schedules, the ability to approve a PR could prove really helpful. Codespaces are especially interesting. Maybe not so much for databases, but maybe. I wonder if we could easily get data provisioning in here.

    Azure CosmosDB is still something I want to play with, though I’ve been hesitant to set up a db because of cost. Serverless CosmosDB might get me to try something. I have no real excuse since they’re an emulator, so maybe not. I wonder how many of you might try CosmosDB out. There are also announcements about PostgreSQL and MySQL on as PaaS services getting feature parity with SQL Server in many ways.

    Lots of Synapse changes, which might be of interest to those of you with larger warehouses and looking to take advantage of the cloud offering. Quite a few AI changes as well, with Bots, speech, ML, and more. I especially liked the keynote on AI, which I think was interesting. It provides some vision of what could be possible.

    Tons of developer sessions, and I’d suggest that you browse or search the sessions to see what interests you. There aren’t a ton on demand as I write this, but likely more will appear this coming week. I hope the Cloud Skills Challenge will also remain up there, as I’d like to spend some time experimenting with services. If you haven’t worked with the Azure services, I might give that a try and get a feel for what’s possible.

    Build is always interesting, and I’m not sure if I love this virtual format, but I’m glad the event was still available and once again I’m impressed with all the work Microsoft is doing to help developers build solutions.

    Steve Jones

  • Investing in Speed

    While most of us might not want to start our own company (or maybe we do), we can learn a few things from those that do. Building something new, being efficient, effective, and quick are skills needed when starting a company. I’ve read a lot about how companies are built and entrepreneurs work. Lately I ran across some advice from Daniel Gross, the founder of Pioneer, a former partner at Y-Combinator (from David Perell).

    Many of us are financially careful. We often are careful with how and where we spend money at home. I find lots of tech professionals frugal at work as well, often being careful with their budgets, or even with the requests they make of managers. That being said, here is a great quote:

    “Overbearing frugality prevented me from spending any money, which creates inefficiencies. Spend like a king on speed, like a pauper on everything else. Faster computer? Go. Faster Internet? Go. Better sleep? Go. Expensive dinner? Stop. Expensive dinner to close a candidate? Go. If you can, use your capital to move faster. Your competitor is taking the shorter flight. Book it.”

    Often I see companies get caught up spending or not spending based on some ideas that don’t have anything to do with efficiency. They don’t invest in things that improve the business, but invest in things they like, or avoid things they don’t like. I see this with choices as well, where a professional or manager may want to change a tool/platform/etc. because they like one over the other. Often without any good fundamental reason.

    Spending money isn’t bad if you are investing in driving your business forward. Learn to make that distinction and don’t be afraid of making good investments. It’s fine to indulge in anything, but in moderation. That might be the key to success for many hings in life.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Rolling Back One Bug for Another

    I was working with a customer recently that develops software for use by their clients. They work in a DevOps style flow, regularly completing work and sending that to their clients. In one case, they released a hot fix quickly to resolve a bug in their software. In this case, the developers received the report, triage’d the bug, and released the fix in less than a week. Their clients were happy with the response and speed at which the fix was delivered.

    Unfortunately, they also released another bug with the fix. The new bug was in an unrelated area of the software, created by separate changes to the code. Now they had a dilemma. The hot fix helped some customers, but the fix also broke some things that other customers cared about.

    What do you do here? If you were in charge of this software team, how do you decide what to do? You can pull the patch, but that means some clients might have broken software. You can leave the patch out there, but then you risk other customers being upset by a new bug.

    There isn’t a good solution here, and the more clients you have, the more likely that you have a large split of customers wanting version 1 versus those wanting version 2. You could rebuild the hotfix to remove the new bug, or you could make another patch that just addresses the second bug. The latter idea is what DevOps would suggest, with a roll forward to a third version of the software. The idea being you keep improving things and fixing bugs as you continue to develop new features. You will release some bugs, but you can fix them quickly.

    The downside of this is that if you release too many bugs, customers are loathe to upgrade. When this happens, you start to find yourself having to support many versions of your software. If you respond to customers with special patches that only fix bugs without adding features, you may end up with many more versions than you can track, which can be a real nightmare for developers to manage.

    How do you deal with patches causing bugs? I recently re-read a piece by Eric Sink in which he recounts releasing three maintenance versions to his customers in a week. Embarrassing for a version control vendor. It’s a good (but long) read, and one that might give you some perspective. We can’t squash every bug, and we can’t test for everything, but we can work to continue to improve, chasing the dream of bug free software. Or at least, regression bug free software.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.