Voice of the DBA

Category: Editorial

  • DBA to Data Engineer

    When I was starting my career, I expected to be a programmer. That’s what people who wrote the software were called. At some point they adopted “developer” instead, shunning the programmer label. Now I see software engineers has replaced developer in many organizations. I’m not sure the job is much different than it was in 1990, other than the specific technologies used.

    The DBA used to do a lot of system administration-type work on database instances. Check logs, set security, run backups, and maybe look at some queries. However, in many cases, their work was limited to things running inside the database software, or the database software itself (patches, related configuration for the host OS, etc.). I saw recently that DBAs have started to adopt the data (or database) engineer label as a new job title. Presumably, this pays more because, well, it sounds like it should. Data Professional sounds more comprehensive and skilled than Database Administrator. Database Engineer sounds better than both.

    Is it better? I do think that many people working with databases are being asked to learn and do more (and new) tasks as a part of their daily work. We often need to support and maintain a wider variety of different systems. If it’s the same platform, then we often support more versions, especially with the 2-3 year cycle of releases of SQL Server. However, we may also need to learn a bit about other platforms, like Oracle, MySQL, PostgreSQL, etc. We can add the ability to work with and deploy new languages, like R or Python, and that might help us land a new position. Certainly understanding cloud database platforms and options, their deployment, and monitoring can be useful in asking for a raise or interviewing for a new position. Scripting, PowerShell, and DevOps are good skills to showcase as well. All of those might be in a Database Engineer description.

    Why bother adding these skills? Especially if you have a good job and are comfortable. You never know when things will change. Your company might downsize, as Ken’s did. They might get bought by another organization and your job could change (or disappear). It’s possible that your family situation or some life event might make you look for a different job. There are lots of possible reasons why you need to change your current employment.

    If you want a better job, perhaps more compensation, better hours, remote work, less late night calls, or something else, then it’s not a bad idea to beef up your skills. Learn to automate things in a better way, which might make your current job easier. Experiment in the cloud, maybe do a small PoC of how you might move or deploy a current workload into a VM, a PaaS service, or even a new platform. Can you migrate from one database platform to another? That’s a useful skill to showcase.

    I have found that a lot of the really good jobs are a hodge-podge of different skills. Being adaptable, comfortable learning, and trying to grow are important skills to demonstrate. Even more important, learning to talk smoothly with others about why you made a decision or recommend something is a key skill to getting hired.

    Sprucing up your titles can help, especially with HR where new titles often mean new salary ranges. SRE Engineers were only at Google at one point and their high salaries set a bar. Engineer, Scientist, Architect, these are all better than Administrator. Boost your skills (tech and soft) and you might find a new position that is even better than the one you have today with potentially a new title.

    Steve Jones

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

  • Reducing Debt and Increasing Security

    Many of us know that reducing financial debt in our lives leads to a bit more security in our minds. We are better able to cope with unexpected expenses when we have the ability to get credit or pay for something in cash. If you’ve ever had a major house repair, car calamity, or (hopefully not) medical issue, you know what I mean. At least in the US. That last one is less of an issue in many other countries.

    We know that our code has technical debt, and often we fight a battle with project managers and business people over whether we should spend time paying down that technical debt or developing new features. We certainly can do both, but often that’s not a choice we are given. If we do get the chance to reduce technical debt, it’s a tiny fraction of the time that is allocated to adding something new.

    There might be a better argument for reducing some technical debt: security. There’s an article that talks about the security risk posed by moving too fast and not ensuring there is rigorous security testing. This is a common problem in many companies that adopt some parts of DevOps, but forget that quickly deploying new code isn’t the only principle. We also need to learn from our mistakes and quickly correct them.

    I am a big fan of releasing often, especially for security purposes, but those releases need to build on each other with not only new code but refactored old code that doesn’t perform well or has a security issue. More importantly, we need to ensure when we find issues in code, that all developers are aware of the problem and don’t repeat the issue. We also need to update our testing to ensure that humans don’t continue to write code in a style that causes known issues. We want to avoid antipatterns in our code.

    This is less of a developer issue than a managerial one. The C-suite and all management that are involved in software need to prioritize security so that known issues are fixed quickly. This also should involve ensuring that technical debt is kept under control as a lot of this poorly written code increases the chances that a vulnerability is in the code. Either because the code isn’t well written or because developers avoid touching the code in the future.

    The best solutions, to me, involve DevOps. Make small changes, deploy them, instrument them, and learn if they work well. If not, fix them quickly. While this might end up delaying some features, ultimately it ensures that our software is in better shape, with a reduced risk of simple security mistakes upsetting our customers.

    Steve Jones

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

  • DevOps is Mostly About People

    I was giving a talk on DevOps recently and one of the questions from a person in the audience was how to get others to buy in. This person also had complaints that “DevOps” wouldn’t work because their boss wasn’t interested.

    I think these are great examples of things that many developers and managers don’t think about when they look to embrace DevOps. While there is no shortage of technical articles and videos on how to introduce automation or deliver features in a new way, what gets lost is the need for cultural change.

    DevOps is all about people. It’s about learning to trust each other and work together. It’s about adapting and changing how you write or deploy code to make the process smoother. It’s about sharing your knowledge with others and learning from them. It’s about being blameless and also accountable. It’s about support from management to improve the software and the process.

    It’s about people.

    The automation is cool and it’s a lot of what is easy to demo and explain. I show that because I don’t know the people involved in your environment and I can’t explain how you can get them to change how they work. Instead, we tend to focus on the tangible things that an individual can learn: the technology. Use version control, validate and test with CI, deploy consistently with release servers, and build packages that are versioned and reviewed. Those are the easy parts.

    The culture is what really matters, both in development teams, in conjunction with ops teams, and with support for management. There is no magic to software development and DevOps doesn’t bring any. All it helps you understand is that you need to be a team to build great software.

    Steve Jones

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

  • Look Beyond What You See

    One of the sales managers at Redgate Software posted an origin story about how he came to work at Redgate Software. It’s an interesting story, and while I don’t work in sales or have the same origin story, I don’t know that I could have seen the place I’m in now early in my career.

    When I saw the video, it made me think of this movie scene, where Rafiki asks us to look beyond what we see. I think this is a hard thing for many of us, especially when many of us have been leaning on our skills in the past. What we know and what we are good at doing has led us to this place. Picking a new direction, or thinking in a new way might be hard.

    For lots of us, we might be concerned about the cloud, and what we should learn or where this might lead us.  Azure or AWS? Some might be concerned about moving into management. Will I be good at it? Will it be a better career for me? Others can wonder about specific technologies. Power BI or Tableau?

    I wouldn’t recommend a specific thing for anyone without knowing more about their situation, but I do advise people to be open to opportunities, investigate and ask questions, and embrace possibilities. Look for what might be slightly out of focus or uncomfortable for you. Look beyond what you see and consider what you haven’t seen before.

    My origin story is getting an electrical engineering internship. Finding that the group needed help with Lotus 1-2-3 macros. Realizing I liked working with computers more than walking around a power plant and working with electricians to follow designs. I then realized that I didn’t love programming or network support, but I saw an opportunity in 1991 to work with SQL Server, and I took it. I looked far beyond what I had thought about as a teenager, as a college student, and even as a young person in my career. I embraced an opportunity to write an article and that led me to SQL Server Central and now Redgate Software.

    Think about the directions you could take in any situation and open your eyes to the possibilities. You might find an opportunity that changes your life.

    Steve Jones

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