Voice of the DBA

Category: Editorial

  • Tracking Professional Athletes

    I used to read about technology to allow computers to track a single person’s movements from video footage. We’ve seen this shown in Hollywood movies, where casinos can take a picture of a person and backtrack all their previous movements throughout the day. I have no idea if this is possible, but if it is, it’s a scary proposition.

    However in specialized, controlled circumstances, we can track people very well. The NBA (with SportVU) is tracking all player’s movements and gathering more data that can be analyzed to better evaluate player’s performances. I expect in the next year or two, players will start to review this analysis and learn how to better adapt to the situations on the court.

    The NFL is also starting to use sensors to track their players, but with different goals. They are monitoring workloads, trying to ensure the health and peak performance of players. It remains to be seen how else they might use this data, but in the linked article, there are perhaps more implications for us as data professionals.

    Can you imagine more tracking data, for any movable object available? People, machinery, who knows what else will be tracked, and what else we might need to analyze. I thought spatial data had tremendous possibilities when I first saw it introduced in SQL Server 2005. However across the last decade I think we’ve barely scratched the surface of what location data might mean for applications, using it mostly for mapping locations and routes. If this data does become useful, that means that learning to aggregate, trace, and analyze location might just need to be a valuable, if not core, skill set for the DBA and developer in the future. If you want to get started, maybe run through this article on your system and see what you think.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Ongoing Costs of Building Software

    I’ve almost never heard of a developer backing down from solving a problem quickly. In fact, I think most developers assume they can solve many problems quickly and whip up useful software. I know I’ve felt this way numerous times in the past. Need a little monitoring? I can knock that out this week.

    However there are costs to maintaining software over time. While many of us can build scripts and small programs that solve problems, we also learn that those little pieces of software need some care and attention over time. That’s well illustrated in the piece titled If You Build It, They Will Complain.

    I had a similar path to that of the author. I built a utility, then another, then another for various departments and people inside of my company. I knocked out useful software that others used. And then I got caught up in enhancing, repairing, and otherwise attending to said software. It was an eye opening experience to realize that often software is never done, unlike the experience I’d had in school.

    I saw a very experienced SQL Server professional note a few years ago that they would never write monitoring software again. It’s not that this person couldn’t, or that they wouldn’t do a good job, it’s that they didn’t want to maintain the software, and there are plenty of good packages that do most of the job needed. This person could fill in missing functionality in small areas, while spending their time on more valuable tasks.

    That’s how I think most of us should look at software. We should look to reuse and take advantage of software that’s written to accomplish tasks, evaluating costs against our time. It’s far too easy to discount an employee’s time, when we could easily outspend the cost of a piece of software already written by someone else if we tackle it on our own.

    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.

  • The Advent of Code

    In early December, I ran across a post from Jeremiah Peschka on practicing your coding skills. Apart from the points made about practicing skills, he referenced a site called the Advent of Code. It’s a site that uses a Christmas theme and a little gaming to get people to solve programming problems. I mentioned it on my blog, and across a few weeks, a few people in the SQL Server community started working on the problems in SQL.

    Probably like most people that started this, I didn’t finish in December. In fact, I didn’t work on problems most days because life got in the way. However I haven’t given up. Around vacations and other events, I’ve continued to work on solving the problems in multiple ways, using different languages. I’ve tackled problems in Python, PowerShell, and T-SQL.

    I’d urge you to give some sort of programming challenge a try, mostly just to gain some practice in building algorithms and investigating the ways in which you can solve problems with software. If nothing else, the exercises challenge your brain and exercise your mind.

    I’m considering working on something like this for SQLServerCentral next year, with a series of complex problems that you can work on to practice your T-SQL and SQL Server skills. I don’t think I’ll make it an Advent of T-SQL for Christmas, but I do think having a series of challenging problems is a good way to drive your learning.

    If you’ve got suggestions for other programming exercises, feel free to pass them along.

    Steve Jones

    The Voice of the DBA Podcast

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

  • 100 Hours

    How long does it take someone to learn to be good at building software in some language? I’m sure many of you have heard of the 10,000 rule that notes the truly gifted in a field need 10,000 hours of practice to become experts and master their craft. There’s some debate about how true that is, but certainly becoming an expert takes tremendous dedication, certainly years of time.

    I ran across a piece that referenced a slightly shorter rule, the 100 hour rule. The rule is fairly simple: “for most disciplines, it only takes one hundred hours of active learning to become much more competent than an absolute beginner.”

    One hundred hours is nothing. That’s a long week or two of active learning to get good at something. But how good? If we look at software development, what can you accomplish in 100 hours? After all, absolute beginner is a low bar. That’s the level my Mom is at and I’m not sure how much I could teach her beyond “Hello, world” in a few hours. Even in 100 hours, I’m not sure she could solve many problems.

    The good thing is that most of us aren’t absolute beginners, especially in software. We have frames of reference for many parts of how computers work. I suspect that 100 hours of deliberate, guided, practical (meaning typing and practicing skills), would turn lots of people into a good junior developer, maybe even a mid level developer. I think many senior developers would be very competent in a new language in a few hundred hours, because they’d learn the syntax translation quickly and then start understanding the tips, tricks, and gotchas that experts in that language might know. The algorithms and problem solving skills are often the same between languages.

    For most of us looking to grow our careers and improve our technology skills, I would guess we could learn a new skill every year, becoming competent, with 100 hours of practice. Reading books and articles is good, but the hands on practice is most important, and that’s what really drives home active learning. That’s something I’d encourage many of you do, with exercises, puzzles, or maybe even start a small project that help you learn. It will help your career, by improving skills, and might even be fun along the way.

    Steve Jones

    The Voice of the DBA Podcast

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