Category: Editorial

  • A Welcome Delay

    Always delay before you send an email, especially a strongly worded one.

    This editorial was originally released on Nov 30, 2007. It is being republished as Steve is traveling to the PASS Summit.

    Microsoft got in on a deal to Nigeria that Mandriva Linux negotiated with the government there. The story almost sounds like a bad email: the provider of a “free” product complaining that another company gave their product away for free? So does that mean that in a free market where the cost is the same ($0), that Windows is superior?

    There’s some other editorial on that topic, but in this case, what was interesting is that the CEO of Mandriva fired off an open letter to Microsoft, which you can read here. The tone of the letter was a little whiny, and it didn’t seem as though Mr. Bancilhon really thought through what he was writing.

    It’s Friday, and with the holidays approaching, I thought this would make a good poll.

    Do you pause before sending emails?

    In the old days, back when I was younger, if you wanted to fire off a letter, you had to write it and then mail it, usually ensuring some type of delay. Often you had at least one night to think about what you’d written before you dropped it in a mailbox.

    There are plenty of people that still recommend that you delay sending an emotional email for at least a day. I know quite a few people that rethink their position before sending, often saving the email to a drafts folder for ten minutes, an hour, some delay to give themselves a break between writing and proofing.

    I’m actually pretty bad. As I’m sure many of you have noticed, typos slip through the editorials from time to time, often because I’m in a rush. My self-proofing skills aren’t the greatest, and I tend to make mistakes more often than I’d like.

    However I’ve also learned that delays can be good things. I’ve often incorporated a delay in restoring a secondary log-shipped database to give me the chance to recover from an accidental deletion of data. Delaying the send of a potentially inflammatory email allows me the time to cool down and can prevent me from making a big mistake.

    Email is quick and a great tool, but it shouldn’t be abused. Take the time to be sure that the message you’re sending is the one that you want received.

    Steve Jones


    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    The 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 at www.everydayjones.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.

  • Checking In

    Just checking in for a few days

    It’s been a crazy couple of months for me, with the US tour of SQL in the City and the fallDevConnectionsconference taking me away from the ranch and to a variety of places. Those events had me away from home and delivering 14 talks on a variety of topics with a few more coming next week at SQL in the City – Seattle 2012. I’m just stopping by for a few days at home before I head back out to the Pacific Northwest for a few days.

    My job is not the typical job that DBAs have, and my schedule results in a number of trips all around the US and sometimes to Europe. Despite that travel, my daily chores still need to get complete. I don’t have to manage servers like many of you, but I do have a certain number of processes that need to run every day and require me to prepare things in advance when I’m away. I’m glad for all the automation since I’m not sure how I’d cope otherwise.

    It’s not that much different than my former production DBA routine. There were times when I was in a class, or attending an event, or even working on a large deployment of some application. At those times I’d often be away from my desk, and less available then other times, but I still had to keep an eye on the rest of the systems. Like many of you, I setup automation, crossed my fingers, and hoped that no major issues would crop up while my attention was focused elsewhere.

    Over time I learned to let go a little as a DBA. If something broke, then it had to wait, or a manager had to decide which crisis needed to be handled first. I realized I couldn’t stress myself out about other systems and had to count on them running while I was away. These days I also do the best I can, but I also realize that at times I might have something break while I’m away. I have to trust that someone else will fix it, or I’ll deal with it when I return.

    Next Thursday.

    Steve Jones


    The Voice of the DBA Podcasts

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

  • Software Teams

    Teamwork is important

    Today’s editorial was originally published on Dec 10, 2007. It is being re-run today as Steve is at DevConnections.

    I definitely used to not trust developers. At least not with my database code, requiring them to send requests to me and I’d build tables, stored procedures, etc. Over the years as I’ve talked to others and become a little more mature, I’ve started to believe that I can trust them more and let them build objects. I still think I need to review their work, but they can be trusted to get the job done their way.

    Apparently I’m not the only one and this is a good blog entry on software teams and some of the issues with managing developers. In the post Jeremy Miller talks about the need for teams to work together with great communication and not be bound or regulated by external groups that just want things to flow a certain way.

    It’s probably a lot of common sense, but it’s really good advice that you have knowledgeable people within and outside of the development team. You include people in discussions about architecture or implementation, you invite collaboration and you trust your people.

    Trust.

    That’s the big word and despite the fact that many of us say we trust our teammates, too often we just do something outself rather than ask or expect someone else to do it. Or trust that they will.

    We may say it’s because it’s quicker, we don’t have to explain it, we were already working on something similar, or many other reasons. But often it’s that we trust ourselves more than others.

    That’s understandable, but it doesn’t build a strong team for the long term. Working with others, letting them make some mistakes, maybe even take a little longer than you would, will pay off over time as you learn to trust each other, count on each other, build that bond that only a team that has all members working as one unit can achieve.

    And achieve a synergy that produces from work from the team than would come from the sum of each individual’s efforts.


    The Voice of the DBA Podcasts

    The Great Music

    The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    Today’s podcast features music by Joe Sibol. If you like it, check out his stuff on iTunes or at www.joesibol.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.

  • Keeping Your Job

    A little work from you can help you ensure you keep your job.

    This editorial was originally published on Nov 26, 2007. It is being republished as Steve is at DevConnections.

    These days it seems that the demand for IT workers is still growing, but there is no shortage of companies still looking to lay people off or get rid of employees that aren’t performing up to some standard.

    I saw an interesting article on how to better ensure IT job security and wanted to comment on a few of the items listed from the DBA perspective. I think that different groups of IT workers have different tendencies, but DBAs often are in a very strange position in a company and they need to ensure that their contributions are recognized as well as their work is valued and understood.

    I remember in the dot-com boom days when “quirky” IT workers were tolerated and even valued. The strange people wearing flip flops and t-shirts could perform wonders with computers and their eccentricities were tolerated. Often when they were just competent at their jobs and no one really understood just how much or little they actually could do with systems.

    The world has changed and expectations for most of our systems are higher than they were a decade ago. Management is more realistic in their view of their business, with most of our employers not expecting to get bought out by some large corporation and retire. Our job is to provide stability and long terms strategic value to our companies.

    As a DBA, you have a varied job. You’re in charge of data, need to technically manage the systems, but also work with business users to ensure their data is properly qualified, the meta data is understood (even if not explicitly written down) and you can help them ensure data quality and recognize the importance of the information that is being stored in databases.

    This means that you need to better fit into the business as well as providing value. You should respect the dress codes and other habits of the rest of the company. You also need to learn to communicate effectively with others. Don’t talk down to someone with technical acronyms and descriptions and make sure that you are trying to solve the business problems, not fit the solution into come cool piece of technology.

    By trying to better fit in, you become an asset to the business as a whole. People should feel comfortable asking for your help and appreciate the work you do.

    And they’re likely to keep you around for the long term.

    Steve Jones


    The Voice of the DBA Podcasts

    The Great Music

    The podcast feeds are now available at sqlservercentral.podshow.comto get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    Today’s podcast features music by Joe Sibol. If you like it, check out his stuff on iTunes or at www.joesibol.com.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.