Voice of the DBA

Category: Editorial

  • Hiring Guitarists

    guitarHiring good people is hard, though in some cases it might not matter as much as others. If I am hiring entry level developers or DBAs, I have a lot of candidates, I’m not investing a lot, and I shouldn’t be too concerned if I have to let someone go and find a new employee. Given the fact that the people are often unproven in this case by definition (they’re junior levels), I should be prepared as a manager to make more mistakes at this level.

    However at the senior level, hiring needs to be done more carefully. The high costs, the limited number of candidates, the responsibilities I give senior people, along with the trust I need to bestow upon them means that I can’t afford to make the same percentage of mistakes at the senior level. Most importantly, I don’t want to hire expert beginners instead of experts at this level.

    I ran across a post on a way to hire senior developers that I thought was very interesting. In particular, I was struck by the analogy of hiring a guitar player. For the most part, I’d agree that if I wanted an experienced guitar player, I’d want the expert, not the expert beginner. If for no other reason than I don’t want to argue with an employee that does things my way, including making the same mistakes I’d make, and then explaining to me this is how I had specified things to be. I want a senior people to warn me, and influence me to do better.

    I’m not sure how I’d devise a similar level of test for a senior level DBA, though I do like the idea of giving them some scenario or simulation that has flaws or problems and seeing if they’d correct them, point them out, or leave them in place as they moved on to “play” the scenario. I’m sure there’s a way to do this, and a balance between how to evaluate the responses.

    Ultimately I want senior people to fix things, make them better, and provide a smooth path to increase quality. I want them to point out flaws, and warn me about issues. If I insist on making poor choices, I want their support, but if they can influence me to do better, I’d prefer they did. That’s one mark of a senior person.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Programming

    programmingTechnology is here to stay, and those of us working in this business probably realize more than most people how dependent and integrated our lives are with technology. Even in countries that don’t have the infrastructure or economies of first world nations are using more and more technology in their lives. Mobile technology seems to be at the forefront of much of what we do, but I’d argue that data is fast becoming more important than the software itself.

    The one thing I’m becoming more convinced of is that this article is right: programming is a core skill. It doesn’t matter if you’re a developer building mobile apps, or a contractor scheduling workers, or a homemaker that wants to balance a budget. While there is software that might help, it seems many people are quick to open a spreadsheet, add some data, and start building formulas. These days the jokes about people not understanding how to program a timer on a DVR are fading quickly as more and more non technical people are using technology to make their lives easier, or perhaps, more complex, as they manipulate data and software.

    I suspect the fundamental skill of logically analyzing a problem and coming up with a set of steps to solve it is becoming more important all the time. In many businesses the ability of workers to think for themselves and handle a variety of situations is more desirable than the ability to follow orders. Even in industries where workers need to follow instructions, those instructions might be coming from computers more and more often. There will be a huge gap between workers that can think for themselves, perform data manipulation and make business decisions and those who cannot. That gap might take the form of compensation differences, opportunities, or something else, but in many industries, those that can build their own programs, whether in code or processes they follow, will advance faster and further.

    Not everyone will want to be a computer developer, but most everyone can benefit from understanding how calculations and instructions can be chained together to build a process or workflow. With newer generations becoming familiar and comfortable with technology from early ages, my vote would be that we should add programming to the three Rs for future generations.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Reporting on Data

    I would think that most DBAs and SQL developers out there realize they need to understand some basic statistics and mathematics to write meaningful reports for their customers. Since many of us write our reports in T-SQL, if we correctly write the formula for one row, it expands to work the same way for all rows returned from the database. That should hold true in Excel, if you cut and paste the formulas across the all the rows or columns. However since each cell could have a different formula, you can’t always be sure that the calculations for all rows are the same.

    This was brought to light in a blog that looked at the problems with a public policy analysis based on an Excel worksheet. The audit-ability problem of validating results in Excel was one issue, and it comes about because you would have to manually verify the formulas in every cell to be sure they were correct. I’m not sure how many people want to do that, though I like the transparency of providing the formulas with the data. Someone will verify them.

    The other part of the blog talks briefly about other issues. One is that to accurately represent the meaning of data, we need to do more than show simple aggregates like range or average. The reduction of a set of data to a single or small group of representative values may not describe the information in the data. An average without knowing the variance or standard deviation may not be the data you want to base a business decision on.

    As we seek to provide more accurate information to our customers and clients, we need to better understand the data we are querying. At some point it won’t be enough to understand the basic aggregates in order to report on data. Big data can provide many false patterns, but tiny data suffers from a similar problem. We need to learn more about statistics and analysis to ensure that as we work with business people to query data, we understand what information we are extracting out of data sets.

     

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Your Frame of Reference

    sql_cat_logo_smIs a database snapshot in SQL Server update-able? Most of us would say no, but I ran across a blog from the Microsoft SQLCAT team that proposes a method of issuing an insert, update, or delete statement in a database snapshot context. You can read the article for the details, and we could argue if this is really allowing a snapshot to be read/write, but that’s not what I noticed as I read this.

    This is a very creative way of approaching a problem. It changes the frame of reference slightly so that we rethink what the customer is trying to accomplish instead of what the technology limitations are. There might be more elegant, or more easily maintained solutions, but I found this to be creative, and perhaps useful, approach for solving a certain domain of problems.

    I think quite often we get caught in viewing problems in terms of our frame of reference, or in terms of common technology implentations without thinking through the problem from the customer’s frame of reference and working on an effective solution. That’s our job most of the time: being effective as we solve problems. If we view all problems within the narrow range of our past solutions, we are relying on our experience, but that may prevent us from building applications that work better than our past work, go beyond what our customers want and get them excited about using the end result.

    However it’s a balance. I’ve seen hacked solutions that didn’t perform well, or didn’t scale and ended up causing problems for years. Looking at the problem from the customer’s viewpoint needs to be tempered with the requirement of building a solution that performs well and fits within the framework of the environment. Ultimately I think the way to get better at building applications (and databases) is to increase your knowledge and experience. Learn more about other people’s solutions, and engage with the rest of the community to sanity check your approach.  Learning new techniques that have worked for others, and experimenting in your environment to build better software over time.

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.