Voice of the DBA

Category: Editorial

  • Getting Started Remotely

    My middle kid is about to graduate from college and is starting to look for a job. I suspect he won’t have too much trouble, as an aeronautical engineer near the top of his class, but I do think that it’s going to be more challenging to find employment than it was two years ago. Though likely better than last year.

    While my employer has continued to hire people throughout the last year, we definitely know it’s been a challenge for some of them to get up to speed, build relationships, and get productive. It’s likely easier for technical people, especially for those with experience, but not necessarily easy for those just getting their careers going.

    If you were starting your career now, I’m sure many of you would be better prepared than when you did begin. I’m wondering if there were things you might recommend to those getting started if they were doing your job. Tips, tricks, or habits to build?

    I was listening to a few people recently talking about this topic, and they gave advice that I followed early on. Keep working on your skills, growing your knowledge and ability to be better in your field. If you’re a programmer, practice and learn more about how to better build systems. If you are on the admin side, be sure you are learning to script and manage with code, rather than GUI clicks. If you are in some other area, like marketing, learn to better analyze what you do and how to manipulate data.

    No matter what, the one thing I always recommend to others is to learn to present an idea clearly to others. Communication, both written and spoken, is a prized skill, and one I find lacking in many people. Being able to present something in a coherent and cogent manner is important.

    Along with that, I emphasize the other half of communication. Learn to listen well and process what others say. This is as important as being able to present your ideas, especially in today’s world where much of our communication occurs with fewer body language cues and less context.

    Steve Jones

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

  • Cloud Database Growth

    The growth of the cloud is exploding overall, with all of the major vendors showing growing lots of revenue growth. Not all of them are profitable, but they are growing. This shows that customers want to use the cloud, and more of them are migrating all the time.

    I do think that databases are likely migrated less than many other services, though their use is increasing. Plenty of organizations would like to offload some of the overhead of owning and managing hardware, which may be one reason why the growth of IaaS in the cloud is one of the more popular options.

    For those databases that are being used in the cloud, can you guess which ones have the fastest growing usage? Since this is a primarily a SQL Server-based site, you might guess Azure SQL Database, and you’d be close. It’s one of the fastest growing, edged out by PostgreSQL.  That’s one reason we’ve been publishing some PostgreSQL articles; it’s very popular and being used in many organizations that also have SQL Server.

    While we know we can build cheaper systems on premises, and we can better control, or at least predict, performance, the cloud is attractive to many businesses. It’s not perfect, but it is an option that you should be able to knowledgeably talk about when someone brings it up. That means you need to learn a bit about how it works, the costs, the performance, and the differences with an on-premises system. The options change all the time, so don’t rely on your knowledge of the cloud from a few years ago or hearsay. Spend some time asking questions of people using the cloud today.

    You also might consider using VMs if someone wants to migrate to the cloud, as the system will appear to be very similar to the way your on-premises instance runs. The hardware setup is different, and you need to learn about the differences in the hardware, especially how you connect disks and their performance. 

    Knowledge is important, and for many of us, we are looked at as those with knowledge about these different platforms and technologies. That means we need to spend some time learning, and likely a bit practicing to understand the impact so that we can present a good argument about when it may or may not be appropriate to use a cloud database.

    Steve Jones

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

  • Holding Code in Your Head

    It is hard to write software. Many of us write lines of code, and often if we go back, we find flaws and problems in our code. As I look at the solutions others might give for the same problem, I’m sometimes amazed at the way they tackle the problem and what language features they use. I’m especially always intrigued when I see someone using STUFF() or APPLY in their queries. I know I have a bit of a hole here, as I haven’t done enough work with them in my career. It’s a tool I just don’t think to reach for.

    Part of that is that I don’t know I completely understand how they work in my head, at least not without effort. The lack of familiarity hurts me here, but it’s part of the issue that Paul Graham expresses in this essay about holding a program in your head (essay via Brent Ozar).

    I certainly have held entire programs in my head, and when I do, I think I work a little more efficiently. Certainly faster, and I can change things as I refine the solution I’m aiming for. I also find that when someone else is touching the code I’m working in, even lightly, it is distracting. The differences in reading my code vs. someone else’s are noticeable.

    I think this is where working in a team, unless you are pair/mob programming, can be challenging. While discussing issues with others might help find solutions, I do think that groups need to subdivide code into sections and allow each person/pair/mob to work on that code alone for a period of time. Some organizations do this well, but plenty do not.

    Perhaps one of the best reasons to be careful about touching the same code in a database is the last writer wins. While some tools might work with the code in memory on your workstation, many of the ways we capture and track T-SQL code come from the database itself. If multiple people change the same object in a shared database, we can easily lose code or frustrate programmers seeing strange behavior.

    There are a number of items that Mr. Graham thinks will help programmers write better, or more, code. However, I also think that his problem space is focused more on startups and new applications rather than the legacy code on which many of us work on every day. However, I do take the point that having a more succinct language might allow a programmer to hold more in their head and get more done.

    If they’re are intimately familiar with the language itself. I think that is a skill managers should promote in teams. And something I need to work on with STUFF and APPLY.

    Steve Jones

  • No-code Software Engineering

    Low and no code applications have been around for a long time. In my career, I’ve seen Access, Delphi, PowerBuilder, and various 4GL packages used to build software for business users. Some worked well, some didn’t, and often many didn’t scale. Not all, but many.

    The problems in many of these tools, at least to me, was that many of the “developers” using them weren’t developers. They were business people trying to get something done quickly. Often these weren’t people thinking about performance or software engineering in the way that many developers think of those topics.

    Arguably, there are plenty of Java, C#, and other developers that don’t think things through either. However, many developers do want to solve problems and build interesting solutions. They don’t (often) want the drudgery of moving around UI elements or reinventing CRUD data operations.

    I saw an interesting piece this week noting that No-code doesn’t mean we avoid software engineering. The author praises some of the no-code platforms because they allow developers to do the fun part of building logic and solving problems without the tedious nature of writing an IF statement with the correct syntax. There are a number of reasons given, which sound good.

    I don’t know that I think that no-code is the way to go, but I do get the idea of using lots of proven and tested components, features, services, and more rather than reinventing them. I think that connections to database objects, RDBMS or NoSQL, ought to be easy, and lots of the mundane work of plumbing systems together could be centralized and reused. I certainly think that LINQ or simple query languages make sense, though likely having a way to more quickly and easily build/test/refactor and deploy database methods as well as make them more flexible (select col from @table, anyone?) might simplify database coding.

    I doubt we’ll get rid of C#, Java, or other fairly low level code anytime soon. I write about better programming languages recently, and I can see us moving to more succinct languages over time, but that will take decades. There is far too much invested in current codebases by developers and organizations to think about quick switches.

    The best way to build better applications is to have developers continue to learn, practice, test, and change their coding. They need to seek to be better, which I think most of them do, but management and leaders need to demand this and invest in staff (time and money) to help them improve. Then I suspect that whether you use lots of code or none, all your applications will work better.

    Steve Jones