Voice of the DBA

Category: Editorial

  • Habits and Familiarity

    This piece was originally published in Database Weekly on Oct 12, 2009. It is being re-run as Steve is away on sabbatical.

    I’ve heard that it takes 2-3 weeks to develop a habit. Do something every day for that length of time and it will start to be a routine for you. I’m not sure it happens that quickly, but I know that after a couple of months, running became a habit for me, and became more enjoyable. It’s something that I now look forward to daily.

    When something becomes a habit, or becomes part of our routine, we develop some skill with that. In our jobs, building those skills usually makes us more efficient. When you know the schema of your database or you can remember the syntax for a SQL command, you don’t have to look things up in Books Online, and you can code quicker. I know I’ve strived to develop habits over the years, ingraining certain tendencies that would allow me to get more work done in shorter periods of time, at a higher level of quality.

    However technology changes. And sometimes sticking with those habits, those tried and true methods of solving problems, isn’t the best way to build your software. As new features come about, or products behave differently in new versions, sticking with the same methods for solving problems might not be the best way to continue to do well at your job.

    I noticed a new blog series this week from Aaron Bertrand and Adam Machanic that looked at kicking some bad habits in the SQL Server world. There are some good posts in there, and I remember having some of these habits, and having to unlearn them and work on new habits. Moving from the old style joins to ANSI ones was a hard habit for me to break, but now I can’t go back. I even have trouble reading forum posts where someone has stuck to this style of join. Not all of these habits are bad in terms of performance, but I think it’s a good series on habits you can break that will make you a better coder on a team. Some of the items mentioned make it harder to share code with other people if you are still using them.

    While it’s good to break habits, I don’t think that it’s worth jumping in and experimenting with every new change that comes along. It’s good to have some habits and familiar techniques lying around that make you efficient. Use them as long as they work. But pay attention, educate yourself, and read about changes. Talk to friends and learn what new things they’re trying. If something becomes a standard and makes sense, add it to your toolbox, and pull it out as often as you can.

    That way you’ll build a new habit.

  • Motivating the Team

    This editorial was originally published on Oct 7, 2009. It is being re-run as Steve is away on sabbatical.

    You’re a corporate worker, building applications that your business uses to sell it’s widgets, gizmos, doohickeys, or ho-hums. Whether you’re a developer or a DBA, it’s not exciting work. Nothing to write home to Mom about with any level of enthusiasm. It’s a daily grind of CRUD applications designed to improve the efficiency of business workers who enter data, or view reports about how things work in the real world.

    That seems to be a story played out in many companies all around the world. Lots of creative, talented people, all stuck in boring jobs cranking out code that supports the business. Over time they become jaded, un-motivated, or burned out at their jobs, perhaps even questioning their choice of career.

    How do you motivate people in that situation?

    I’ve seen lots of business seminars and presentations designed to increase moral, or somehow get people excited about their company. Most of them have failed miserably for me. I haven’t left feeling motivated, especially  over the couple last decades where it seems so many corporations’ management care little about their employees, and only about what their quarterly number will be. Or what their bonus might be as executives.

    Even though they are paid differently, everyone has to feel appreciated. – Roger Staubach

    It’s a great quote, and one that I think tells us what motivates people. We want praise, we want to be challenged, and we want to enjoy our work, but what we really need is to be appreciated. Make a worker feel like they matter and they will put up with and even enjoy their jobs more.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available at sqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo atwww.everydayjones.com.

  • Farewell

    This is my last day of work this quarter as I start my sabbatical at 5 o’clock today. I’ll be gone for the next six weeks, away from SQLServerCentral, trying to improve and grow myself while staying as unwired as I can during that time. The rest of the staff here at SQLServerCentral will pick up the load, and I’m sure everything will be fine.

    This is a bit scary for me. I’ve pretty much been employed full time since I was 17, only taking a few, short, involuntary stretches of unemployment in almost 30 years. Even during those times without a job I was focused on finding a job almost every day, so it felt as if I still had the job of finding a job during those times. I’m nervous about taking the time off, and certainly worried a bit about SQLServerCentral as I’m not sure I’ve been away from the site for more than a week since it was founded.

    This is a temporary farewell, as I’m planning on being back on July 14th, just in time to head to the UK for SQL Bits. I’ll likely be doing a touch of writing, and trying to get a little coding done on some side projects, but for the most part I won’t be answering email or checking on the site. That alone will be a good test of my personal growth. If I can avoid www.sqlservercentral.com, I think I’ll be doing well.

    For those of you that are interested, I’ll be posting on my blog, under the sabbatical tag. I’m trying to document some of my adventures, and hopefully I’ll have something to show for my efforts at the end. I’m nervous, but also a little excited. Six weeks to work on some projects away from work seem like a dream on top of my already amazing dream job.

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • No Works of Art

    I used to pride myself on being able to run through menu selections and configuration options from memory. There have been times when I could describe over the phone  the process for using a GUI. I’ve been able to direct people to log onto SQL Server, choose a database, right click it, and choose restore. Then select device, choose NORECOVERY, etc, etc. I could walk people through many Windows dialogs, IIS configurations, and more, with verbal commands, picturing what they would see on the screen as I was holding my phone to my ear.

    People would be impressed, and I’d rarely make mistakes. I knew what was coming next, and where to click. However I did make mistakes at times, and while that’s human, that’s not what we want during software configurations. These days we find plenty of administrators and developers running an install program, and either selecting options from memory or using some sort of document that was given to them. The thing that concerns me is that any of those processes could be full of mistakes. Documents never get rev’ed to keep up with changes. Human memory is faulty, and certainly we find ourselves clicking the wrong button at times.

    When we install, or deploy, software in this manner, we’re asking for problems. Not every time, but if we manually configure, click, or select anything, then we are building individual works of art. That’s not what we want from our software environments. We want to know that the production environment is configured the same way every time, and if we need to recreate it in a DR situation, we can. We want confidence that the software that was tested in the QA environment will work correctly in production, which means we know that the states of the system are the same. We might even want to be sure that we’ve configured our development environments the same as production.

    As our tools get better, especially around virtualized systems, there isn’t a good excuse for not automating our installation and configuration through some sort of scripting. These days there ought to be no reason for a Windows, SQL Server, IIS, and most other platforms to not be easily scripted and deployed in a hands-free fashion. That’s one of the keys to engineering software at scale instead of sculpting it one system at a time.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.