Voice of the DBA

In the last few years, I’ve noticed that the quality of technical workers can vary quite a bit in many organizations. I think most people get things done, but often not at a high-quality level. It’s one reason that I write, speak, and try to motivate more of you to work on your skills and your career. I want to see better software being built.

I tend to work with more database developers than application developers and I tend to see more SQL code than C#/Java/etc. And I see a lot of poorly written SQL Code and poor data models that seem to have been built without a lot of thought put into them. Whether this is because of ignorance or just poor skills is hard to know, but I see a lot of code that makes me slightly cringe.

Over time, many of us see that this technical debt limits our ability to improve things or make changes. Often these systemic issues linger because the development staff a) doesn’t know how to fix them, b) has other, higher priorities, or c) is afraid to try and make changes. Often it’s a combination of all three, which further limits the agility of the database and application teams. We end up struggling to keep up with customer demands, or we may pile on more and more technical debt. Often this leads to increased performance problems in the database.

I was reading about development and staffing in this piece, which had an interesting quote: “I currently believe that there’s only one way to buy yourself out of technical issues and bad data models, and that’s buying a really talented engineer whose sole focus is fixing the problem.” Essentially, you need to do two things here. First, hire a smart engineer, and second, empower them to effect change. In many cases, I think you actually need two smart engineers: one database engineer and one application software engineer. Those people have to focus on improvements, refactoring bad data models and the code that depends on them, and slowly raising the level of quality.

The piece gets a little sidetracked with the way vendors promise their products will fix your problems. In general, that’s not true, at least not without you adapting your process to their software. In my role, I’m careful not to promise more than I can deliver, and not try to minimize the effort required to change. I know it’s somewhere between using 10% time and a major overhaul, and I hope I convey that to clients.

Ultimately, I think that we haven’t commoditized lots of software development, which is the point of the piece and the quote above. We need to get talented people, or we need to train them, or both. We need people that enjoy their jobs and find some purpose or satisfaction. Part of that is making their jobs more interesting and enjoyable.

That also means there are many opportunities if you learn to be good at your job. Learn to build good data models. Keep up your skills that write efficient code, learn how to troubleshoot, and learn how to work well with others. None of those are easy skills to develop, nor are they quick to learn, but they can be learned with some effort. Document your progress, blog/write/speak, and I bet you’ll find your career prospects improving.

Listen to the podcast at Libsyn, Spotify, or iTunes.