Voice of the DBA

Category: Editorial

  • 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.

  • 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.

  • Just Say No

    Just say no was a tagline from my youth. As I recall, it didn’t work well then, but I hope it will work better for a different audience and in a different context today. I was reading Brent Ozar’s note about one of the toughest things for consultants to do: saying no. While I certainly think this isn’t a problem for some people that can’t find work, I do think this is an issue, and one that isn’t just a problem for consultants.

    I have worked with many people across my career, and one of the things that most of them have struggled with is saying no. Maybe it’s fear over being scolded (or worse) by a manager. Maybe it’s the simple desire to please others. Perhaps it’s because we simple are eternal optimists, and we think we can handle everything thrown at us. No matter what your reason, many people find the inability to say no plagues them throughout their careers.

    I’ve learned to say no across the last decade. I probably say no to more things than I agree to accomplish. There are times that I worry about how much I decline to tackle things at work. However I have learned to deliver what I agree to, and deliver it well. I’ve learned that to do that, I can’t tackle every project, idea, or assignment. There are times I have to push back and refuse (politely) to do something.

    It’s a luxury for sure. I have been successful in my career, and I’m not in a position where the loss of my job would wreck my life. However I also realize time is the most valuable resource I have at work. Time is also the most valuable resource I have in life, and I have to learn to balance my use of that resource to continue to be successful. Hopefully you learn that as well.

    Steve Jones

    The Voice of the DBA Podcast

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