Voice of the DBA

Category: Editorial

  • Learn to Earn

    Could you double or triple your salary by learning more technology skills? Sure, and here’s a great story about someone learning PowerShell and dramatically increasing their earnings. This is a good read, looking at the journey of someone through their career and how they credit learning PowerShell for the changes in salary.

    When I read this, I don’t view this as PowerShell being the reason that Mr. Duffney increased his salary. Instead, I think the takeaway is that professional learning and regular skill development, focus across time, and producing results for an employer as being the primary reasons for raises. I think that the right part of the salary curve in the post, which has a steeper slope, is also likely due as much to speaking and giving back as it is to solving problems. The other lesson in this piece is that Mr. Duffney is constantly gaining skills, and looking to move forward in his career.

    The world of technology is ever changing, with new platforms, additional features and changing paradigms constantly appearing. I’m sure many of you have experience with management that becomes excited by the latest buzzword or hot topic in the media, expecting that each of us can quickly build a proof of concept. Perhaps you’ve dealt with a boss that assumes we could buy a product or build a tool that easily solves some problem because they read about some other company in a publication having success.

    Tackling a new project or technology is a challenge, but we can learn to ease the way for ourselves. We should be constantly learning something, anything that exercises our minds. One of the best talks on the topic I’ve seen is from Andy Warren, and I’d encourage you to check it out. Andy talks about directing your learning in an area that can help you. That may sound daunting, but I think that building the habit of regularly learning something is important in this business. We never know where our career may take us, and being accustomed to the idea of picking up some new technology and using it for a task is a skill you should practice and develop. The more often you try to improve your skills, the more comfortable you will be with the idea of tackling some new technology. In the first piece linked, we see that Mr. Duffney had a plan to become a CCNA, but over time that plan morphed into something else, as did the focus of his learning.

    I certainly have been able to raise my salary by learning more about databases. This usually comes about not just from learning, but from applying that learning to my job, showing my employer (and potential future employers) that I provide lots of value for my salary. Using new skills in a valuable way is the method by which I’ve most often been able to translate learning into a raise.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.2MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • The Pressure to Compromise Ethics

    There have always been those that seek to defraud, deceive or mislead their customers. In order to do this, someone inside an organization has always been willing to pressure employees to compromise their ethics and morals. Construction companies may use substandard materials or ignore standards for construction. Financial companies falsify performance records of products. Medical professionals may order unnecessary tests to charge more. Perhaps one of the common areas many people feel cheated is with used vehicles, where there are numerous stories of deceit from companies and individuals. I’ve had my own experiences with cars to support this.

    It may be no surprise to you this is also happening in the digital world, which seem fundamentally more disturbing to me. After all, software is constantly changing in a way that many other industries don’t. We can fundamentally rewrite the rules under which systems work by deploying new code, something many of us do on a regular basis. What’s more, we have rules and regulations that fundamentally prevent us from disclosing how the systems work, limitations that don’t allow for anyone to easily audit or evaluate what the programming might be doing.

    This is different than a car, where we can examine the components and test them, or have a third party perform this for us. It’s different than health, where we can solicit second opinions. Even construction has inspections from independent groups that can verify some specification is met. However, none of that exists for software. In fact, our industry resists remotely attempting to implement any sort of ethics by limiting access to source code.

    There’s an article that lists some of the issues developers have encountered. It also talks about teaching ethics as a way to reduce the impact, which is a good idea. But without any sort of accountability or transparency into the actual code, I’m not sure ethics will help much. There are always people that need a job, and may be willing to write code that continues to provide a paycheck because they aren’t sure they can get another job. I know most of us would like to think we wouldn’t succumb to pressure, but it can be hard to be sure what you’d do until you are confronted with a particular situation.

    I do think this is a problem that will grow, and become more pervasive in the digital world, precisely because no one really knows what software is doing under the covers, and it’s hard to even determine what might be happening if you could access the source code. After all, can you be sure that code you get is actually what is running? You can, but not easily.

    What I’d like to see is some sort of framework that allows us to specify the behaviors of our software, along with the data movement and handling so that end users would have an understanding of how the software should work. Maybe some automated way of producing a “contract” based on the code. Then we could resolve disputes without ever needing to examine the source.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.4MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Finally, Create or Alter

    There are lots of reasons to upgrade to SQL Server 2016, but this is the one for me. We finally get a CREATE OR ALTER statement in T-SQL. This not only makes lots of code easier to write, it means that the ways in which you might script and schedule your future deployments will be cleaner. This is an exciting change for implementing a simpler and easier Continuous Integration/Continuous Deployment system in your organization.

    It’s not perfect news for a few reasons. First, this is a SQL Server 2016 addition to T-SQL only. That means until you have most of your applications have moved to SQL Server 2016 SP1+, you won’t be able to use this construct. That’s OK, because it will mean that at some point most of our instances will be on SQL Server 2016 SP1 or later, and much of our code will be cleaner. We won’t resort to including IF statements in our deployment scripts. We won’t need to create stubs of procedures and functions so our code is embedded in an ALTER script. In essence, you won’t need to maintain two separate code constructs to make a change.

    This isn’t perfect, nor is it complete. We still don’t have CREATE OR ALTER for tables. That’s the place where I’d really like to get a consistent way of coding items. What I really want is a complete view of the table each time I change it. By this I mean that if I create a table like this:

    CREATE TABLE Students
(
    studentname VARCHAR( 200),
    status TINYINT
);

    Then I want to be able to add a column like this:

    ALTER TABLE Students
(
    studentname VARCHAR( 200),
    status TINYINT,
    DOB DATE
);

    Or alter a column like this:

    ALTER TABLE Students
(
    studentname VARCHAR( 200),
    status BIT,
    DOB DATE
    );

    Or better yet, have a CREATE OR ALTER for tables.

    I know this might be asking for a lot, but I really think that we ought to get a consistent way of coding databases so that we can reduce the mistakes and make our systems easier to understand. I’m sure this may require substantial engineering, not to mention a great deal of understanding of how this would actually affect our systems when run, but it would certainly make our code cleaner.

    I doubt we’ll see these kinds of changes, at least not until we have an ANSI standard that encompasses them, but I would hope that as an industry we would mature and improve the way we work with databases, not remain bound by tradition and history.

    Steve Jones

     

  • Hire the Right People

    I’ve seen this list of why projects fail going around the Internet for awhile (recently from Brent Ozar Unlimited).  There are a number of items in here, and if you substitute some other field for the data scientist part, you might have seen some of these issues as well. One of the items that really struck me was number 5, which is titled: You shouldn’t have hired scientists. The other part of the slide is that ETL needs data engineers (whatever those are) and reporting needs BI analysts.

    I with that we had good ideas and definitions of what different jobs are supposed to do in a company, and what skills are helpful. The more I look at job descriptions and responsibilities, the more I find that DBA, analyst, data xxx-anything are just amorphous concepts that vary dramatically from organization to organization. In fact, since the title that one has often determines pay scales, I think that we start to covet titles and work towards getting a title, regardless of the work we do. This isn’t helpful for anyone, least of all HR departments that try to match salaries to value and pay for particular jobs.

    There isn’t a great solution here. Our industry is young and changing more rapidly than any other in history. New jobs are created out of thin air, to meet the changing face of software development and system administration. Build master, data scientist, blockchain engineer, and a few others didn’t exist when I started working in technology. Whether those jobs are needed in an organization might not relate to whether or not anyone has those titles, or if they perform the tasks we might expect of those positions.

    I think that many of us are expected to be able to perform any task tangentially related to our position. Or we should be able to learn it quickly. DBAs should understand replication as easily as they might Availability Groups and configuring Extended Event sessions. A developer should be able to write C# as well as T-SQL. Both should be able to use SSIS to import and export data. While I’m sure many of us could do those tasks at a rudimentary level, are we really competent and capable at each of those tasks? Maybe enough for our organizations, maybe not.

    When we embark on projects, there may be needs to accomplish tasks outside of the core competency of our staff. That’s fine, and since many people in technology are willing (and excited) to learn new skills, this situation may be perfectly acceptable for our project. When there are core skills critical to the project, such as a deep understanding of large scale ETL processes, we are probably better off hiring people that have those skills or investing heavily in just-in-time training for existing staff. Hoping that the average DBA or C# developer can just “pick up some tips” is a recipe for project failure.

    Steve Jones