Voice of the DBA

Author: way0utwest

  • Rethinking Hiring

    We’ve had endless discussions here, and elsewhere on the Internet, about hiring qualified candidates. We’ve had conversations about interviewing unqualified candidates. There are also no shortage of talented people, evidenced by the the knowledge and code they share on the Internet, who struggle to find good jobs that fit their skills.

    It seems that overall, we have a problem in matching people with jobs. Many companies bemoan the difficulties of finding talented development staff, and I understand the challenges. Certainly there is no shortage of individuals that don’t bother to expand their skills and learn good, fundamentals about their craft. Often this lack of skill shows up in interviews and leaves many of the interviewers thinking they’ve wasted thier time, or the candidate has misrepresented their experience.

    However, I think part of the issue is the lack of training and investment in individuals the companies make. Maybe one of the more problematic issues I see is that we don’t have good paths for teaching and progressing knowledge, whether inside of a company or as a person seeking to learn. It seems that while there is a huge amount of information available, it is poorly organized, and very cumbersome for an individual to manage. Even with companies, we don’t seem to have well structured training that adapts and helps our staff grow.

    I thought this was an interesting piece on how many companies don’t do a good, basic job of deciding who to interview. Too often companies have fallen back on the general guidelines of a degree or years of experience in a job. That’s not a great solution, and since most of us don’t have great track records in hiring, this limits the chances we’ll see good candidates. There are definitely failings on both sides of this equation. I hear constant horror stories from people interviewing DBAs and developers that don’t know basic concepts. However I also hear from candidates that aren’t even called to interview for positions because they don’t have a degree or some other generic qualification.

    I do think that many people can learn new skills and new jobs. I think as developers and DBAs, we should be trying to learn new skills, or improve our existing ones regularly. I also think that companies should look to invest in their staff and improve the skills of individuals. I realize that this is a tough task, and there aren’t necessarily easy ways to do this, especially as it seems talented staff might just leave for another position right away.

    I hope that in the future we find companies that look to grow their staff’s skills at all levels, with the understanding that they might leave, but they might stay, especially if they are treated well. And if they do leave, a good training program will help minimize the impact, since other people should have some idea of what work is being performed, and new people can be taught the skills they lack.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Changing Scales and Creating Disappointment

    I got an email recently that notified me that session feedback from the Summit was available for my talk. I’d had a lot of people in the room, and was curious how things went. I think the session was OK, a little off on time, a few too many questions I tried to answer, and perhaps a bumpy flow.

    However when I got my scores, I had a 2.85 for the session overall, with various aspects of the talk being rated from 2.5 to 2.9.

    Well, I sucked.

    That was my first thought. I’ve been getting rated, and evaluating speakers on a 5 point scale for quite a few years at PASS events. I was surprised, and disappointed, and then a bit embarrassed that I hadn’t delivered a good talk at the Summit. Since I hadn’t delivered that talk in public anywhere prior to the conference, I thought I had made a big mistake. Apparently my practice that week in my hotel room had been for naught.

    However then I saw this note in another email: One of the changes this year was to move from a five point rating scale to a three-point scale.

    Hmmm, I missed that in my email somewhere, and didn’t notice this as I filled out a couple of session evaluations.

    I don’t think there’s anything wrong with changing the scale. Personally I like the 3 point scale, but it wasn’t a change I noticed. The first communication with speaker feedback didn’t mention this.

    Scale matters. Many of us know that by manipulating scales, we can make data look different, We can prove a point that might not be supported by a different presentation of the data on another scale.

    Our clients and business users come to know and expect the various ways we present data. They will start to internalize scales and interpret data based on their expectations. We can change scales, but we need to make it clear and visible that we have changed scales.

    Personally I would have appreciated the results being reported as:

    Overall Session Score: 2.85/3.00

    instead of

    Overall Session Score: 2.85

    That little extra information can mean a lot. Keep this in mind as you make fundamental changes to the way you present data.

  • The Auditor Attack Vector

    The phone on the desk buzzed. The CEO picked it up, expecting his assistant to let him know his next appointment had arrived. Instead he was told a person had called and wanted to discuss why his managers were paid less than some of their direct reports.

    The CEO was puzzled, and worried, so he accepted the call.

    “Did you know that you have programmers making more than some of their managers? ” the caller asked, quoting the specific people and their salaries.

    The CEO did know, acknowledged this, but declined to discuss the matter. Instead he asked who was on the phone, and how did they know the salaries of his employees.

    The caller declined to give their name, but told him that they had found a USB thumb drive outside on the street and had plugged it into a computer. A number of spreadsheets were on the drive, with one containing the salaries and organizational structure of the company. The called left the story there, promising to mail the drive back to the CEO.

    The CEO was upset, and worried, but waited a few days to get a package in the mail. He had been planning to terminate someone for carelessness. However when he opened the package, he realized none of his employees was to blame. Instead, this was a device given to an auditor who was verifying the accounting practices of the company.

    I don’t know the rest of the story, but it was given to me by someone that runs a decent sized company. It’s a scary story and shows a concern one that has nothing to do with most of us that work in technology departments. However this does show that there are always holes in our processes and practices. We need to consider the fact that many of the businesspeople we work with value convenience much more than security. We need to be sure we take precautions where possible, such as encrypting all data at rest, and in transit, wherever possible.

    It might not be our fault, and it might not be something we’re blamed for, but I certainly would feel some guilt if I had copied the data onto the USB drive without providing additional security, such as encryption or at least a password.

     

     

    Steve Jones

    The Voice of the DBA Podcast

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

  • NoSQL Complaints

    I think that NoSQL databases are a really interesting set of technologies, however they aren’t necessarily a panacea for many problems, including scalability. There are likely some problem domains where a particular NoSQL technology might work better than an RDBMS, and perhaps some situations where many types of databases would work well.

    I ran across a piece that looked at some of the complaints that companies have with NoSQL technologies. It’s a generic piece, perhaps too generic, since a graph database is not like a document database. However it does talk about the issues that companies see, such as performing analytic queries. While a row-based RDBMS isn’t ideal for these queries, often the platforms work very well for a wide variety of reporting requirements.

    I do think some of the problems people have noted have to do with the maturity of the systems. There are a lack of references for how to run a high uptime NoSQL database, not many data models to review that may or may not work well, and relatively few administrative techniques to maintain these databases. The problem isn’t that NoSQL databases can’t meet your needs, or run quickly, or provide many 9s of uptime, but rather many enterprise professionals might not know how to find the information to accomplish these goals. That’s something easily solved across time.

    Ultimately I think the NoSQL world has a lot of maturing to do, and we, as professionals and media, need to start to differentiate among the various flavors of databases. I am glad to start seeing articles and blogs refer to graph databases when they cover a product like Neo4j rather than writing NoSQL. Slowly I am seeing MongoDB referred to more often as a document database, not a NoSQL database. It’s good to start to separate technologies and not confuse one with another.

    One thing in the piece I did notice is that it’s likely that we will see more platforms and products incorporate both RDBMS and non-RDBMS technologies together. We see that in SQL Server already with the addition of columnstore technologies in the last few versions and Polybase to SQL Server 2016. I expect we’ll also start to see some of the capabilities of DocumentDB added to SQL Server, along with, perhaps, graph based technologies in the future.

    Steve Jones

    The Voice of the DBA Podcast

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