Voice of the DBA

Category: Editorial

  • Help Your Manager

    Most of us have some sort of review with a manager on a regular basis. It might be once a year, once a quarter, or even monthly. Some of us like these, and some don’t (me), but the review is often a way to assist your manager in evaluating how you are performing in your job. This is quite common, and I’ve gotten used to this, though I never really like the process.

    I do know reviews are important. This is a time when you have an opportunity to shape your career. A good impression here can help you with a raise, a promotion, even the choice of a project or work you want to do in the future. I learned early on in my career that these reviews were important.

    I also learned that my manager often wasn’t up to date on what I’d done across the last time period. I used to have annual reviews, but even with quarterly reviews, managers have their own career (and review) to worry about, other employees to worry about, and they can lose track of your accomplishments.

    I saw a link in the Brent Ozar newsletter listing things that your manager might not know. Not everything on the list would be things that I cover in a review, but these are things to think about as you look to tailor your job to suit you. If you want something fixed or are having issues, make sure you explicitly call these out to your manager. Not imply something is bothering you, but directly state what you want or what is wrong.

    Read the list, but for me, the important things are to track the extra things I’ve done, the things that impact the company, or that help other people. If I save the company money, or better, increase revenue in some way, I want to make a note and bring those notes to my review. If I spend extra time to make someone else’s job easier, bring that up.

    Your manager often doesn’t know the details of what you do across time. Usually, they do track the current tasks, but they often don’t remember at review time what you did 3 or 6 months ago. Often I don’t either.

    That’s why I keep notes about my successes. They help me drive my career forward in the direction I want it to move. It can help you as well but start keeping track of things today, as a way to prep for review time.

    Steve Jones

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

  • Unix vs PowerShell

    I saw an article on using awk, sed, and grep on Linux. I used to know how to use those, though I was by no means an expert. However, working with a stream of text with an input and output was a valuable skill I’ve used over and over in my career. There are plenty of times when I’ve needed to handle a long set of text, and my practice with Unix in university helped me a lot. I’ve only lightly needed to use Perl and regex in my career, but I was glad I had some idea of what I was doing.

    In the last few years, I’ve spent quite a bit of time working with PowerShell (PoSh) instead of text-based utilities. While I found some of the design cumbersome and unintuitive, overall, the idea of working with objects instead of a stream of text is really nice.

    PowerShell was devised to get around some of the complexities of these utilities. It was built to be an integrated shell, with lots of improvements on the way one might use the utilities above in a bash or Korn shell. While it can take a bit of getting used to, in many ways, I do think it’s superior to the old paradigm of chaining together lots of utilities.

    What’s more, it’s fairly easy to enhance PoSh with your own routines, and many vendors have taken advantage of this to provide APIs and interfaces with their tools. Plenty of corporate Ops and IT departments have done the same thing, publishing routines that anyone in their organization can expect to exist and use.

    I loved Unix, way more than DOS in most ways when I was in university. If I’d been a decade younger, I might have even evolved into Linux and pursued a career in that environment. These days, with plenty of MS software, including SQL Server, moving to Linux, I’m happy to change to that platform. However with PoSh being available cross platform, I think I’d be looking to use PowerShell as my shell and scripting platform of choice, even on Linux.

    Steve Jones

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

  • The State of Data Growth

    About a decade ago I did some presentations on Filestream and Filetable in SQL Server.  These were technologies that Microsoft added with the idea that lots of data would need to be linked to data in a database, but wasn’t necessarily a good fit for a relational table. At the time, I looked at the growth of data, which was incredible back then. Statistics I had from that time were from the invention of the printing press for the next 500 years, we created 1 EB of data. In the 2011/2012 time frame, we created 2EB each day.

    That’s changed. I saw a blog on the story behind the explosive growth of data, which looked at a recent IDC report that showed we created and replicated (a strange term) about 64ZB of data in 2020. With a ZB being 1000 EB, we can see that a decade has brought us multiple orders of magnitude of data growth.

    That doesn’t mean we need to store all this data. The report notes that a lot of this is consumption data, which is transferred, but not saved. This means that we do need strong networks, but that most of the time the data is being viewed and not actually stored. That’s certainly the case with things I see on Netflix, where I may end up transferring part of a show multiple times to get through it, usually because I fall asleep.

    The estimate for the next 5 years, through 2025, does indicate that we expect to need 200% more storage capacity and that a lot of data storage is going to be at the edge, in devices and server machines, as well as in the core, made up of data centers, cloud and private. While plenty of this data will be outside of databases, and plenty will be in non-relational stores, this does tell me that working in the database business as a career is one that’s going to be in demand for a while.

    I’ve enjoyed my career working with data, and I expect to keep doing so for the foreseeable future. I am confident there will always be work for those that know how to work with data in a variety of situations. I also expect a very high demand, and high compensation for those that do it well.

    Steve Jones

  • New Old Architectures

    Many years ago I was starting in a software development role using dBase and Clipper. I needed to upgrade a DOS based dBase program to Clipper to take advantage of some graphical libraries. Around this time, we were also moving many clients machines from DOS to Windows 3.1, giving them a GUI experience. Also, to the dismay of the management, access to Solitaire. One of our early jobs was to remove that game and Minesweeper from installs.

    In any case, I started to experiment with compilers that would allow Clipper programs to run in Windows as native apps. This meant moving to a more event-driven style of programming instead of the procedural way that DOS programs worked. This change was a paradigm shift for me and I spent many hours at home experimenting and trying to understand event-driven programming.

    It’s much easier to build a Windows app now, with many frameworks and libraries that handle the low-level events. However, the idea of using event-driven programming can be important in many distributed applications. When we work on the request-response model, it’s easy for a failure or problem to create a poor experience for the user, especially if there’s an intermediate layer between the client and the data. Certainly, there are retry and error handling techniques, but far too few developers implement them in a comprehensive way.

    I saw an article that introduces the idea of event-driven architectures as something you would want for microservices applications. It’s a good read that helps you gain an understanding of how this architecture would work. I’d recommend this to data professionals, as I expect more of us will encounter developers wanting to implement microservices as a way of magically making your software better. They might even want to implement a broker and queue system in SQL Server.

    There are many ways in which you might implement this type of system, and many technology choices, but an understanding of the overall concepts might help you guide developers to choosing an architecture that makes your life easier rather than harder. Event-driven architecture and microservices aren’t magically going to make your application run better. They could easily create bottlenecks that cause your phone to ring and ticket queue to grow.

    It’s helpful to learn about the things developers want to try and build. They get enamored by new technologies, some of which are amazing. Some aren’t, however, and some knowledge can help you point out potential problems and influence decisions. We all want better software, and as data professionals, we want to have intelligent conversations about how to get better software built.

    Steve Jones

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