THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Arnie Rowland

Discussion of issues related to SQL Server, the MSDN SQL Support Forums, the complex interplay between Developers and SQL Server Administrators, and our sometimes futile attempts to have a 'normal' life.

  • An Open Letter to the SQL Community: Requests of Speakers

    (Part 2 of 2 -about and for Speakers.)


    In the previous article, Speakers were acknowledged for their dedication, passion, sacrifices, and contributions to the global SQL Server community, graciously providing tens of thousands of hours of free training around the world.


    Now I'm going to kick it up a notch, and say unequivocally, SPEAKERS, WE CAN DO EVEN BETTER! It really won't take much effort or time to propel yourself into the top tier of community Speakers.


    After the recent SQLSaturday Oregon, we conducted multiple surveys, of attendees, Speakers, and volunteers; we even surveyed those who registered, but for various reasons, did not attend. We gathered quite a bit of very useful data -information that will most certainly inform our future event planning. I'm going to share some of the results that directly impact Speakers.


    I'll start off by mentioning the obvious - please pay attention to details, especially in communications. I, too, am a Speaker; and we get a lot of invitations, requests, and notifications flowing through our Inboxes -I get it.  BUT after you summit an abstract, or accept an invitation, PLEASE pay close attention to communications from the organizers. It is incredible how often I receive an email, or get asked at the event, about some detail that was clearly described in a previous email notification. And since about  45% of our Speakers didn't respond to the survey request, I have to assume that they didn't read the email. I prefer not to acknowledge the alternative that they just chose to blow it off.


    Let's now look at what the community wants from Speakers, as expressed in the surveys. I offer this with hope, and trust, that most Speakers will readily accept these as considerations for improvement.


    • Session Titles and Abstracts. The most comments regarding Speakers revolved around how the size restrictions on abstracts prevented attendees from having enough detailed information about the session content. Quite a few respondents were disappointed, feeling that the abstract was inadequate and led them to choose an inappropriate session.  Suggestion: Post a detailed session description and outline to your Blog or web site and include the URL in the abstract. Also, from my experience, I know that sometimes our session content may evolve over several presentations. If that happens, be sure to update the abstract.


    • Session 'Level' Consistency. Several respondents expressed concerns that they would go to a Beginner session and find the material way over their head. Some expressed frustration about what to them seemed like some form of more advanced  'insider' discussion between the Speaker and a few other attendees. And they felt left out, unable to keep up. Suggestion: Ask someone with the SAME level of experience as your session is tagged to review your material and let you know if it fits and flows well.


    • Marketing: Experiment with new opportunities to market your session. For our recent SQLSaturday, we invited Speakers to offer a 2-5 minute Intro video that attendees could use to better decide which session to attend. It was a resounding  success, with several respondents lamenting that all sessions did not have Intro videos. Suggestion: Create a 2-5 minute Intro video for your session, host on your web site and include the URL in the abstract. (For examples, see:


    • Deliverables. Quite a number of respondents expressed a desire to have deliverables (Slides and Demos) available immediately so that they could go home and capture this new information, and perhaps revisit the demos  while fresh in their mind. Suggestion: Post your deliverables before your session. By so doing, you are less likely to get busy and forget, and you will gain greater respect from your audiences.


    Finally, consider 'owning' your own feedback mechanism. What is important for you to know in order to evolve in your quest to be a more comfortable and sought-after Speaker? Don't assume that the organizers will be on top of asking for audience feedback, or that they would ask the questions that would provide you the most value. Personally, I find that many of the questions often asked provide little actionable value foe me. Do a Bingle for suggestions about questions used for speaker evaluation. Bring your own evaluation forms, or use an online service, such as SpeakerRate.


    And most importantly, have fun. If you aren't having fun, you're definitely overlooking something -and short-changing yourself in the process. Attend all Speaker receptions and dinners  you can, embrace the #SQLFamily, contribute to #SQLHelp, and ride the #SQLTrain.

  • An Open Letter to the SQL Community: Regarding Speakers

    (Part 1 of 2 -about and for Speakers.)


    The SQL Server community stands out as one of the most open, sharing, and giving technology communities. Around the world, there are active and robust User Groups, free all day SQL Saturdays, and regional events, all with the singular focus that all who use SQL Server and the Microsoft data platform can quickly and easily gain the knowledge and skills to enhance their, and their organization's productivity.


    There is a very special sub-group within the global SQL Server community, and it is comprised of those that passionately, time after time, step forward to offer  their knowledge and experience as volunteer Speakers at SQLSaturdays, User Groups, and many other free community events. These Speakers  tirelessly inform, explain, educate, answer questions, and serve as ambassadors of the community, to the community.


    They often travel great distances, at substantial costs, both to their budget and family. They spend considerable amounts of time preparing their presentations, perfecting their demos, pondering the questions they might, and do, encounter. They invest time and energy communicating with those that have attended their sessions. As a bonus, they often learn from the attendees asking questions that hadn't been previously considered.


    It's important to keep in mind that Speakers, like all of us, are only human. In spite of all their preparation, things go awry. Demos don't always work as expected, equipment fails, connections don't connect, and sometimes things just don't go right. Maybe they misspoke and offered a piece of information that caused confusion, or weren't completely up to speed on some nuance or edge case feature, and sometimes they may have responded in a manner that seemed a bit less than desired. But you know what? Audiences are for the most part, very supportive, accommodating, and forgiving; they usually realize that the presentation, like any labor of love, may have a few rough edges. They realize that the Speaker is doing the best she/he can at the moment, under the circumstances, in that particular situation. Our audiences are excellent.


    Except forthat guy. You know him. We've all been in sessions with him; we've been annoyed by his distractions, rambling questions that seem to be more about showing his knowledge or experience, or his attempts to discredit the Speaker. It's all about him. We find ourselves wishing that he would just STFU! If you are reading this, most likely, you're not that guy. You obviously care about enough the Speakers that you want to know more. If you encounter that guy in a session, politely remind him that you're there to hear from the Speaker, about the session topic, and that the diversions are distracting. I guarantee you that the Speaker will appreciate everyone's effort to keep the session on topic.


    This community of Speakers deserves our appreciation, our heartfelt thanks, our acknowledgement that the SQL Server Community is robust and thriving because of THEM! Having such a high quality  community of folks willing to freely share their expertise and knowledge in virtually unparalleled in most professional fields. We all benefit from this great community of SQL Server Speakers.


    Please join me in saying THANK YOU Speakers!

  • Wanted: Senior DBA or Dev-DBA (And So Darn Hard to Find!)

    I mentor, teach, and consult about SQL Server. It’s an incredible tool –it is an extremely flexible, adaptable, and complex data environment. SQL Server is capable of bringing tremendous value to an organization when it is configured, tuned, and used appropriately. And one of the things that I am occasionally engaged to do for a client, is to help interview candidates and find an FTE Senior DBA or Senior Dev-DBA. And finding such a resource quite often proves to be a very difficult quest.


    Let me be perfectly clear. SQL Server is so complex that no one, and I’m very certain about that, is capable of being an ‘expert’ in all of its’ capabilities. And the few that are true experts with various SQL Server technologies and components are in high demand –secure and very well paid if an FTE, or perhaps even more so if they have chosen to be consultants.


    Which brings me back to the purpose of this article. What do I look for in Senior level folks, and just as importantly, how can a candidate more readily assess if he/she really is a Senior level candidate. From an interviewer’s perspective, I’ll give you a few tips about how to properly assess your own readiness to be called a Senior level DBA when you are exploring the market for opportunities. And I’ll offer a few pointers about what you can do to make the leap to truly being a Senior level resource.


    Experience. What constitutes experience is always a big question. But what constitutes Senior level experience? That is a big IT DEPENDS kind of question. But one thing is certain for the clients I’ve interviewed for in the past year –experience means doing a lot of different things to solve complex business needs and problems. It does not mean doing a lot of the same tasks, week after week. If your biggest challenge every week is looking through your monitoring reports to verify that everything is working as expected, I don’t care how many years you’ve been doing that, and how many hundreds of servers you monitor, you’re really not the Senior level resource my clients are seeking. They are looking for folks that have set up Clustered servers, Availability Groups, Change Data Capture, database Mirroring between multiple data centers, configured and used Server Broker, or StreamInsight –AND failed. (As an important aside -do you even know what StreamInsight does?) But most importantly, they expect the Senior level person to be ready to try again. They expect a Senior  level DBA to bring in experience from trial by fire learning. At Enterprise scale, things rarely go as designed, or expected, or even hoped. But we pick up the pieces and take another stab at it, cherishing our failures as much as our successes. If you are interviewing for a Senior  DBA or Dev-DBA  position, and you can’t readily talk about some really major failures, and what you learned as a result, then you have not been in a very challenging environment, and you still have a way to go to really earn being called Senior.


    A hallmark of the ‘mid-level’ FTE is doing the ‘same old, same old’, day after day, week after week, doing safe work, in a safe environment, rarely expected to work outside of a typical workday eight-hour shift. (I anticipate that there will be healthy disagreement with my characterization of the requirements of being Senior. But with many of my clients, in rapidly changing competitive business environments, Senior means being ready to ‘saddle up’ and just get the job done.)


    Maybe you knew that, and now you want to make the leap and try on the Senior mantle. What can you do in order to be taken seriously and be given an opportunity to even try. Sure, your previous positions were not really challenging, but you think you are ready. So you’re considering submitting yourself as a candidate for a Senior level position. You are going to go for the interview. What should you expect? What can you do to prepare yourself? How can you stand out and be noticed -AND considered, by the interviewers?


    Product knowledge. Be prepared to respond to questions about the current version of SQL Server. Sure, you current employer is still using SQL 2008 (or 2005, or heaven forbid, SQL Server 2000), but if you can’t answer questions about current capabilities and features, you will be quickly relegated to the ‘also-ran’ list. It is an acceptable response to indicate that you are not currently working with ‘x’, but you know about it and think that it could solve certain problems. Visit the SQL Server website, read the product literature, download the evaluation version, perhaps even purchase the ‘Developers Edition’ (about $50), and set up a server on your home computer. Start exploring and learning about the other stuff, there are a significant number of online labs and tutorials that are free for you to use and learn from. But gosh, don’t go into an interview without current product knowledge. Recent candidates had no clue about Columnstore indexes; heck, several didn’t even know what an ‘Include’ index was about. One ‘experienced’ DBA had no idea about data compression or page level verification. A few alleged Senior Dev-DBA candidates didn't even know how to start profiler. And the list is embarrassingly long.


    Learning and Training. Be prepared to disclose how you learn about SQL Server. Do you have a test environment? Do you read significant blogs? If so, whose blog? Be prepared to talk about those you rely upon for product information. If you are not regularly reading blog postings by Randall, Tripp, Delaney, Berry, Kehayias, Beauchemin, Mechanic, (and many others)  then you are truly loosing out to a candidate that can tell me what he/she read recently that caused a pause, and a learning opportunity. I don't really care which of these writers you may read, I just want to know that you are connected in with some of the best minds in the business. Do you attend your local SQL Server User Group? Do you even know about it. If you don't, I will be concerned that you are working in a vacuum, failing to take advantage of opportunities for knowledge transfer and networking. What was the last technology conference you attended? Was it a 'FREE' event that you gave up a Saturday to attend? Was it an event that was important to you and you paid some of most of your expenses? I want to know that -it communicates that you invest in your career. If your training, conferences, networking only happens on the organizations time/money, then I have real concerns that you are most likely not adequately keeping up with advances in SQL Server.


    Certifications. From my perspective as an Interviewer, I value certifications as a testament to (1) setting a goal, (2) doing the prep work, (3) investing time and resources [$], and (4) obtaining the goal. Bottom line for me is that it becomes a gauge of a candidate's ability to commit, study, retain, and use, new information. Granted, it may be less than ideal information, sometimes even contrary to 'real world' demands. And a certification does not give much assurance that information has actually been retained. But is does give me a way to evaluate a candidate's drive. AND the candidate's willingness to invest personal time and money to further his/her career. Candidates that only learn on the clock, and when being paid, are often quickly dismissed. This technology moves too fast, and changes too frequently to not have a commitment to invest personal time/effort/resources. You can't tread water, you either sink or work hard to move ahead. There is no easy path. It takes sincere commitment.


    Résumé.  Presenting a detailed list of every technology that you think I might be interested in is going to be a problem. First, if you allege that you have Senior level expertise  in  8 or 10 SQL Server technologies, you are probably not being very honest. Yes, you may have passing awareness, or perhaps even dabbled in a lot of various SQL Server technologies, but what is your true expertise? Be prepared to defend your assertion that you have Senior level  knowledge and experience if you have it listed on your résumé. And if you list technologies unrelated to SQL Server, I wonder why you think I care, this interview is for a SQL Server position. I expect that you know a mix of ancillary electronic work tools.


    If you have a series of short, 3-6 month engagements, be prepared to talk about it. Perhaps even mention why on your résumé. This organization is not going to invest six months getting you up to speed in their organization just to have you walk out. If there appears to be a pattern of short work experiences, expect to be grilled about it and have convincing responses ready. Unless I see something special about you during the interview, an equally qualified candidate with longer tenures will be in front of you on the short list.


    And finally, during the interview, if you are asked why you are leaving your current position, don't tell me that you are bored, that you feel unappreciated, that your boss is a jerk. That may be true for you, but guess what, I really don't give a twit. I want to know why you think that this opportunity will be a good match for you -and for this organization.


    Do your homework -be prepared to tell me a few things about this organization. What is its' purpose, business, market -use the internet to research it out for gosh sake. An interview is a two-sided conversation; you should be prepared to ask questions -about the company, the specific job/tasks/duties under consideration. A candidate that is seeking to escape a bad situation is far less attractive than a candidate that is seeking to join a new situation that may provide new and interesting challenges.


    Being a Senior level professional means so much more than just having survived a number of years at a job -it is not about age, longevity, or being the first in the door.


    Being a Senior level SQL Server professional is about drive, experience, knowledge, learning, and mastery. You don't get to call yourself Senior -you have earn it.

  • Current Thoughts on Interviewing and Hiring Conundrums

    For many organizations, data is the lifeblood that keeps them in business. If the data becomes imperiled, the very existence of the organization is threatened. The folks entrusted with managing the data are often the most critical to the long term success of the organization. Think about it. Great developers are creative, inventive, solve business problems, and generate new revenue. BUT if the data gets bollixed up, the organization suffers unnecessary expenses, loss of business, loss of confidence, and the risk of failure. Successfully managing the organization's data over time is one of the most critical, and often, underappreciated, operations that just MUST work as expected. There is little room for error -or learning by mistake.

    During the past few weeks, I have been in several conversations with hiring managers about how to find 'highly' qualifed candidates for open SQL DBA or SQL Developer positions. These were managers that have, in their opinion, been wasting their time with interviews. In every case, they came with the same question: "How do I cut through the crap and ensure that I'm attracting and interviewing 'real' qualified candidates?"

    As we explored the issue, variations of the following were woven in and out of the conversation.

    • "I can't find a candidate that really knows his/her 'stuff'."
    • "I'm wasting my time with 'pretenders'."
    • "I can't seem to attract the level of candidate that would give us a good selection."
    • "I spend time interviewing someone that appears to be just the right person, and he/she is obviously put off by our compensation package."

    I usually offer that the current market is highly skewed against the employer -the demand for expert help with SQL Server is so high that highly qualified candidates can be very selective. Many positions are filled through networking and are never publically advertised. Additionally, the highly qualified candidate is most likely employed, very well compensated, and just not actively looking for a new opportunity. At least not at the compensation packages a lot of organizations can afford to offer.

    So what's a hiring manager to do?

    First, engage a SQL Server consultant to conduct a thorough job and task analysis, and research local salary ranges. You should know the bare minimum experience and knowledge that you can accept. It is a very rare organization that needs someone highly experienced with every SQL Server technology. And even in the organizations that do, there are often multiple folks, each with a specialty niche. And stop with the 'kitchen sink' requirements list -it only serves to deter candidates that just may be a good match for your needs.

    Once that is complete, you can address the question of what are the primary qualifications to look for in a candidate?

    Obviously, the candidate must sync with the base qualifications and experience that was identified (see above.)

    But most importantly, you need to know if this candidate gives you have a solid platform to build upon. You want to explore the candidate's investment in self and career.

    Questions to ask:

    • Is the candidate invested in self-directed learning activities?
    • Does the candidate participate in the local user group opportunities in order to learn from others?
    • Do the candidate participate in other technology community learning events, such as: Code Camps, SQLSaturdays, professional conferences?
    • What was the last class or conference the candidate paid out of pocket to attend?
    • Does the candidate freely share knowledge with others? How?
    • Is this candidate someone that can, and does, ask for help?
    • Can this candidate be transparent about his/her mistakes? Is there a track record?


    • Stop the use of overly broad acronyms and the use of 'alphabet soup' that really doesn't tell anything about the Job.
    • Tone down the 'kitchen sink' set of requirements, expectations, training, and experience.
    • Hone in on exactly what is required to be successful with the position today.
    • Find the candidate that happily invests his/her time and energy in learning and career advancement. Then invest in that person.
      • Send them to advanced training.
      • Contract with an expert that can serve as a Mentor.
      • Give them time and support to be involved with the technology community.
      • Allow for, and honor their commitment to their family.
    • If you provide comp time for spurts of long hours, honor the exchange. Don't make it difficult to use the comp time. Word does get around, and candidates will find out.
    • Make your organization the kind of place where folks want to be. Your employees spend almost one-half of their awake life at work -it should be a great place to 'hang out'.

    Be cautious about where you advertise your positions. Some places tend to attract the 'least' qualified candidates and may sully your organization's aspirations by association.

    Your local Technology User Groups are a great place to find folks that are committed to investing their time to enhance their skills and career. Consider sponsoring or Networking with appropriate User Groups.

    If you choose to work with one or more recruiters, or staff augmentation firms, approach your selection with the same zeal and jaundiced eye as you apply toward a potential candidate. Be sure that they know that if they waste your time with unqualified candidates, you will stop accepting their submissions. You are the customer, and the submitted candidate is the product. Just like with anything else, if you don't see the products you want, tell the vendor, or shop elsewhere.

    Be very clear on what you want, communicate that very clearly, and you will be more likely to find it. Take that first step, analyze your requirements, research the market, and get a better understanding about who you really need to hire, and what you may 'have' to afford. And consider how your organization's flexibility can be used to help a candidate grow into the position.

    You may not be able to afford the person you want, but that doesn't mean you can't get there. Like a successful vintner, you need to have great 'root stock', provide a fertile environment, tend the vines, reap the fruits, and nurture until you can sip the sweet wine of success.

  • Rules of Holes #7: Some Will Look Down on You.

    I've been extoling the Rules of Holes, hoping to give you both courage to get out of your Hole, and solace for having allowed yourself to get in a Hole in the first place. How about the others, the folks that see that you are up to your neck, the folks that could guide you out, the folks that are secretly glad that it is you down in the Hole instead of them.

    So this brings us to Rules of Holes #7: When you are in a hole, some will look down on you. Only a few will offer their hand, and of those, only a few will be able to provide you the help you require.

    As was mentioned in Rules of Holes #6, you have to be careful when folks offer to help you out of your Hole. You need to carefully evaluate the probability of success with their help. If it is the wrong person, without the needed skills or expertise, you will just end up pulling them down in the Hole with you. And a crowded Hole can be a very unpleasant place –as well as quite unproductive. In a later Rule, I'll explore how to better identify those that can genuinely help you get out of your Hole.

    But with Rule #7, you realize that some will gain delight in watching your struggle to get out of your Hole. It takes their attention away from their own struggle to escape from their own Hole. By figuratively 'looking down on you', they are able to falsely elevate their own stature. They may be telling themselves that they would never dig so deeply, or ever find themselves in such a predicament. The truth is, they are most likely indeed in a Hole.  Actually, maybe by watching your plight, they can continue denying the reality of their own Hole -but that is another story...

    Look up and smile, for one day, much sooner than they could imagine, the roles will be reversed. And then just maybe you will be able to extend your hand and offer the help needed, or at least assist in locating the help needed. But I hope that as a result of your experiences with your Hole, you refrain from just looking down on the hapless occupant.

    (I am in the process of compiling a more complete list of 'Rules of Holes', and in upcoming weeks, I'll share them with you. And if you have developed your own 'Rules of Holes', i invite you to share them with us.)


  • Rules of Holes #6: Don't Draw Others Into the Hole with You

    In the Fifth Rules of Holes, you were encouraged to seek help from others in order to extricate youself from the Hole. And it should have been clear in that Rule that you want to seek out those that can actually help you. Not everyone, or just anyone, will be able to help you get out of a Hole. Hopefully, you have a mentor, or will take the opportunity to enlist a mentor. Just be selective.

    Being selective will help you with Rules of Holes #5: Drawing more people into the Hole with you is not likely to get you out.

    You need someone that knows how to keep from being sucked into the Hole with you. From experience, or training, or good fortune, the ideal candidate will have learned how to avoid and even escape a Hole. You need THAT person to help you get out. That person will be better equiped to help you without getting sucked in themselves. Drawing inexperienced others into the Hole with you most likely will not serve to get you out, it only makes the Hole more crowded and confusing. Of course, there are those that would draw others into the Hole just so they can clamor over their bodies in order to escape, leaving them behind. But often that is just committing career suicide. It might work once at the cost of leaving a lot of ill will, and a lot of folks hoping, or even working, to see you fail.

    You need to be strong enough that you can gently rebuff those that would be pulled into the Hole with you, and would not be able to get out themselves. Folks are generally curious, they will want to look at your Hole, they may even want to experiment with escape techniques. But if they don't have proven escape and avoidance skills, they will just be in your way, making it more difficult for you to get out of the Hole. Additional baggage that you now have to look out for since drawing them in with you was your responsibility. You could have declined their offer to help, instead seeking out someone that could truly help you without getting pulled in by your plight.

    In order to escape your Hole, seek help from those capable of assisting without becoming trapped themselves.

    (I am in the process of compiling a more complete list of 'Rules of Holes', and in upcoming weeks, I'll share them with you. And if you have developed your own 'Rules of Holes', i invite you to share them with us.)

  • Rules of Holes #5: Seek Help to Get Out of the Hole

    You are moving along, doing good work, maintaining a steady pace. All seems to be going well for you. Then BAM!, a Hole just grabbed you. How the heck did that happen? What went wrong? How did you fall into a Hole?

    Definitely, you will want to do a post-mortem and try to tease out what misteps led you into the Hole. Certainly you will want to use this opportunity to enhance your Hole avoidance skills.

    But your first priority is to get out of this Hole right NOW..

    Consider the Fifth Rule of Holes. Most likely, you will need someone's help to get out the hole.

    Sure, perhaps you got yourself in this Hole without anyone's help. Perhaps you were led -or pushed. But the truth is, you are in a Hole. You didn't see it coming, or you were not skilled enough to avoid it, or you rushed in without fully considering how you were going to get out.

    Most likely, You will need someone's help to get out. It may be just an observer that can give you a perspective that you can't get from down in the Hole. It may be someone that is willing to extend a lifeline to you, or it may be someone that has experience with this particular type of Hole and knows how to get out. But unless you are super-human, or incredibly lucky, you will not get out of the Hole on your own.

    But you don't need just anyone's help, you need help from someone that can get you out. How do you find the right person? Well, you network; you look through your network of co-workers, and friends -with special emphasis on mentors, both past and current, and future. A mentor will have your best interest in mind. After all, they are your mentors because you have determined that they are especially capable of providing you direction and guidance, AND they have agreed to work with you in that role. Now is the time to seek the help of your mentors. Ask for their guidance in getting out of the Hole.

    And if you don't have a mentor, it's time to question why not? What's keeping you from seeking out one or more mentors? Look around you, there are people that have a lot to offer you, there are people that can help you avoid or get out of a Hole. There are people that will be honored that you would consider them as one of your mentors.

    Ask. What have you got to lose -except maybe staying in the Hole?

    (I am in the process of compiling a more complete list of 'Rules of Holes', and in upcoming weeks, I'll share them with you. And if you have developed your own 'Rules of Holes', i invite you to share them with us.)

  • Rules of Holes #4: Do You Have the BIG Picture?

    Some folks decry the concept of being in a 'Hole'. For them, there is no such thing as 'Technical Debt', no such thing as maintaining weak and wobbly legacy code, no such thing as bad designs, no such thing as under-skilled or poorly performing co-workers, no such thing as 'fighting fires', or no such thing as management that doesn't share the corporate vision. They just go to work and do their job, keep their head down, and do whatever is required. Mostly.


    Until the day they are swallowed by the Hole.


    This brings us to the Forth Rules of Holes: If you do not see the bigger picture, you just might be in a hole.


    Without seeing the 'bigger picture', how can you possibly know your part of the puzzle? How can you possibly know when you are being truly successful? How can you possibly know where to spend your scarce time preparing for your future? In fact, how can you possibly know that you are NOT in a Hole?


    Holes are insidious, they consume all that blindly enter. And when you are in a Hole, you can't see out, and you eventually become accustomed to thinking that everything that you see is all that there is, and that you need not be concerned with anything else. Wrong! The Hole has consumed your ability to be rational.


    Technology is changing at an increasingly rapid pace. You must be watching the horizon in order to prepare and position yourself for the future. If you don't, you won't have much of a future in technology. Not so long ago, around 1999-2000, folks that could only code basic HTML were very well paid. and many were unemployable just a couple years later. Technology moves on, the Hole doesn't want you to leave -it needs you to survive.


    So look for your horizon, scan for the future, pay attention to where you are and where you wish to be next year. Be prepared AND keep a big picture.


    (I am in the process of compiling a more complete list of 'Rules of Holes', and in upcoming weeks, I'll share them with you. And if you have developed your own 'Rules of Holes', i invite you to share them with us.)

  • Rules of Holes #3: A Better Shovel is NOT the Answer!

    You stopped digging. You looked around and saw that you were still in the Hole. You needed to get out.

    AHA! Problem solved, you thought. You'll just get a better and more efficient shovel!

    I regret to tell you that the Third Rule of Holes applies: Switching to a more efficient shovel is unlikely to help you get out of the Hole. Yes, your resumed digging may be faster, more directed, and even well planned and articulated. But you will still be in the Hole, and digging. And that's just not the solution.


    A new process (scrum, kanban, whatumaykalit), or a new language (C++, C#, R, CLR, etc.), or playing 'buzzword bingo',  -even a new team or manangement structure, that keeps any form of a shovel as its primary tool will not get you out of the Hole. You got in the Hole by digging -and you won't get out by only digging more.


    Remember, the first step to getting out of the Hole is to STOP DIGGING. Even with a new and improved shovel!


    (I am in the process of compiling a more complete list of 'Rules of Holes', and in upcoming weeks, I'll share them with you. And if you have developed your own 'Rules of Holes', i invite you to share them with us.)

  • Rules of Holes #2: You Are Still in a Hole

    OK. So you followed the First Rule of Holes -you stopped digging yourself in deeper.

    But now what? You are still in a Hole. Your situation has not changed much, but at least you are no longer making it worse. You need to redirect the digging effort into escape and avoidance efforts. The Hole has a singular purpose -consuming all of your time and effort. AND it has succeeded! But now you are going to redirect your efforts for your own survival.

     You have encountered the Second Rule of Holes: When you stop digging, you’re still in the hole.

    You need to look around, take stock of the situation. Try to understand how you got in the Hole. Learn from your previous digging. When did you first start feeling that you were in a Hole? What kept you from taking action on those feelings when they were fresh? Why did it take so long for you to decide to put the shovel down? Make notes to better provide yourself an early alarm the next time you start digging.

    We can't help getting in Holes. Sometimes it happens because we were not paying attention to our direction. Sometimes we strayed from our path. Sometimes we blindly followed someone else into the Hole -or we were pushed.. And sometimes, it was just a matter of timing -the Hole opened up and swallowed us just as we came by.

    If you are very, very lucky, the Hole is still relatively shallow. You just might be successful in scampering out on your own. But if you have been digging efficently, and not paying attention to your environment, you just may be in so deep that you cannot get out by yourself.

    You have two equally important and separate tasks now. (1) You have to marshall the resources to get yourself out of this Hole, and (2), you need to assess how you got here so that you are better prepared to avoid the next Hole that comes along. Sometimes these are intertwined goals, such as learning new coding paradigms or techniques -useful for getting out of the current Hole as well as better avoiding furture Holes..

    As you survey the situation, look around for resources to enlist in your effort to get out. Is there someone that can give you a hand? Or toss you a rope? Do you have a lifeline? Someone to reach out to and talk with? If you had a mentor, you could have leaned on her/his experience and perhaps you would not have blindly fallen into this Hole. Assess what you need to get out and stay out of Holes. Can you do that on your own, or do you need guidance? Maybe you will have to expand your network of contacts to have better resources to draw upon. Maybe, just maybe, someone is positioned to extend their hand to you and you couldn't see it while you were busily digging.

    Stopping the digging was just the first step.

    But you are still in the Hole. And will remain in the Hole until you decide to take further action.

    (I am in the process of compiling a more complete list of 'Rules of Holes', and in upcoming weeks, I'll share them with you. And if you have developed your own 'Rules of Holes', i invite you to share them with us.)

  • Rules of Holes #1: Stop Digging

    You may have heard of the 'First Rule of Holes'. It goes something like this:

    "When you suspect you might be in a hole, stop digging."

    That seems like obvious, and good advice, but what does it really mean? How does the Rule of Holes apply to you? How does it apply to your job?

    When things are not going right, stop doing the "same ol', same ol'"

    • You find yourself involved in doing the same type of coding over and over. Maybe it's time to stop, step back, take a little time and learn something new. There just may be a better way.
    • Your team spends hours in meetings, yet the results are always less then spectacular. Don't continue doing that type of meeting -do something different.
    • You find yourself doing the same re-engineering over and over again. Stop. Spend more time in educating and mentoring.
    • You are constantly restarting a failed replication subscription. Stop, Examine the objectives. Perhaps there is a more robust and better method.
    • As a DBA, you find yourself in the same conversations with developers over and over. Stop arguing and defending. Try to understand their needs and help them be successful. They will be more likely to work with you to understand your needs.
    • As a Developer, you are constantly pushing the DBA(s) to remove some of the impediments to being successful in completing your tasks on time. Ask the DBA(s) to help you understand their pressures, try to understand their job. They too, have an important part to play in being successful.
    • You are still using cursors for non-administrative tasks? Stop it! Explore. There may be a better way.(Maybe not, but in exploring alternatives, you will learn a lot that will be useful elsewhere.)

    The point is to explore doing things differently. Your solution should be a rational decision for the problem at hand, at this moment, in this environment. Not what worked last year, or even last month, or on a different server. Avoid digging holes, and when you realize that you are in one, stop digging. Do something different.

    I am in the process of compiling a more complete list of 'Rules of Holes', and in upcoming weeks, I'll share them with you. And if you have developed your own 'Rules of Holes', i invite you to share them with us.

     Meanwhile, stop digging.

  • Financial Transparency is Good for Community

    I  was recently in a conversation with several people that had previously organized one or more community events. The topic evolved into a discussion of Sponsors, and eventually, fund raising. Being able to adequately raise the funds necessary is critical to producing a successful event. Many vendors will readily provide products for raffles and give-aways (SWAG), but the success of the event hangs on being able to raise cold, hard, cash. Venues and equipment have to be rented, refreshments and lunches purchases -and insurers seem to always require payment. Being able to draw upon the supporting community of vendors for sponsorship funding is essential to producing free community events.

    One of the topics we discussed is an issue that seems to be just below the surface in the community at large -it’s there, and no one really wants to bring it into the open. (Andy Warren wrote about the subject in this post just a few months ago.) The issue we discussed is about financial transparency -including what to do with excess funds after the event. And further, is it necessary or appropriate that all funds raised in the name of an event be expended solely for that event? It was even emphatically stated that it was good to over subscribe sponsorship for the event and re-direct the excess funds to other purposes. Some adamently postulated that intentionally over selling sponsorships allow funds to be used to support other seeming worthwhile community activities.

    And I thought -just hold on now. To me, that’s approaching being misleading, if not outright deceptive to sponsors -and to the community at large.

    My concern is this: If we approach a potential sponsor for funds to produce ‘Event A’, in my mind, the sponsor has an expectation that the funds go to produce ‘Event A’. If some of the funds are diverted to support activities B, C, D, etc., sponsors may feel that they are being unfairly used to support activities that they may not have chosen to support outright. Or at the very least, they were not provided the opportunity to make a rational decision to support activities B, C, or D. Vendors vote with their dollars -they give money to events that make sense for them. They are calculating the ROI for access to the attendees -factoring in the competitive environment with other sponsors. More sponsors means less access. When events are over subscribed, the calculation becomes skewed. When unknown amounts of sponsor money is diverted to other purposes, the calculation becomes almost worthless.

    If organizers deliberately use the event fund raising as a cover to gain funds for other purposes, no matter how worthy, there is a real danger that sponsors will stop giving money. If that happens, everyone loses.

    I propose that community events embrace transparency and provide a public accounting of Sponsor funds. Granted, there may be valid reasons to not disclose individual Sponsor contributions, and you will notice that is not being called for here. I propose to break this down into just a few simple categories -such as:

    Total Received, less

    1. Venue, Equipment Rental & Insurance
    2. Banking Fees and Taxes (Including Paypal Fees)
    3. Printing, Signage & Misc Supplies
    4. Volunteer Expenses (Shirts, pre/post Event, etc.) 
    5. Speaker Expenses (Gifts, Shirts, Dinner, etc.)
    6. Event Food & Refreshments
    7. Attendee SWAG (shirts, etc.)
    8. Attendee After Event

    Amount Left Over

    And then provide a statement of how the left over funds (if any) will be used to support the community. This level of transparency will allow sponsors to understand how their funds are being used.

    I recognize that there may not be simple agreement to this level of public disclosure, that situations can be complex, and that there may be valid justification for some financial obscurity. Let’s start a public discussion about what is best for the community at large. To continue the status quo, where there are below the surface grumblings, questions, and even suspicions, is not good for the community at large.

    I’d like to hear your thoughts on this.

    • Should all funds raised for an event be spent solely for that event?
    • And should event organizers be more transparent about funding AND expenditures?

    (The recent SQLSaturday Oregon 2011 Financials are published here.)

    (Originally published at

  • Paying for Free

    It seems like there is a widespread malaise in the country these days. Everyone's clamoring to cut taxes -but no one wants to have their neighborhood school closed, or fear bridges collapsing underneath them, or damage their automobiles while driving over deteriorating streets and roads. They expect Fire and Police personnel to magically appear when needed. The list can go on and on. Folks want and expect so many things to be available, yet they don't want to pay for them. They don't care if someone else has to pay more, they just want to pay less.

    In the computer technology field, there is an excellent array of 'free' professional activities. User Groups, Code Camps, and SQLSaturdays are just a few opportunities often provided where you can pick up information about upcoming technology changes, gather a few tips and tricks, network with others, and even find a job. These events are made possible with the generosity AND self-interest of Vendors –companies that want the opportunity to put their message in front of the audience. In exchange for their money, these Vendor/Sponsors get exposure for their products and company message. Their logos may be on signs, they provide printed material, they offer raffle items, and they even send their personnel to be on hand to talk with attendees. They are trying to be noticed. They are trying to have the opportunity to put their product or message before a receptive audience for consideration.

    To me, it seems like such a simple bargain. I go to the event and consume whatever learning / skill / networking opportunities that fit my interests. I have rarely left an event thinking that it was a waste of time -I always gain from being there. In exchange, I listen to a few sales pitches, see a few new products, pick up some literature, and even expect to receive an email or two. It's not too burdensome. If the vendor's products and my needs are out of sync, then I ask to be removed from their mail lists. I get a great free opportunity, and the vendor gets the opportunity to show me their product.

    In my experience, Vendors that sponsor technology events are reputable and ethical. If, upon receiving their after-event email, I ask to be removed from their mail list, they readily do so. And on occasion I have actually discovered that I really do wish to continue contact with a particular vendor.

    As a 'free' event organizer, I am personally dismayed about how many folks, when registering for the event, automatically 'opt out' from receiving after-event email contact from the event sponsors. It seems like they just can't be bothered to receive an email from a Sponsor, and then, after receiving that after-event email, make an educated decision about remaining in contact with the sponsor.

    That just seems so wrong!

    Life is about balance. Everything has a cost. It's not sustainable to always expect and never be willing to pay. If you are going to accept the opportunity to improve your knowledge, skills, and professional network (and I truly hope that you are) -be willing to play the game and pay the Piper. It's not only fair, but it will help ensure that in the future, similar opportunities are available for you. If everyone opts out, one day the sponsors will all opt out too. Then we all lose.

    Support FREE events, give yourself and Sponsors a chance.

    Am I wrong here? What are your thoughts?


    (Originally published at

  • There should only be one ...

    When visiting clients, I often find that one or more databases have a table (or several) containing metadata. Most often, these tables have only a single row of data containing metadata about the company, the application, or the database itself. Quite likely, there should only be a single row of data in these metadata tables.

    Sometimes, I find an INSERT TRIGGER employed to make sure that another row of data is not accidentally added to the metadata table. The TRIGGER may count the rows in the table, or it may call a function that counts the rows in the table. I've even discovered SQL Agent jobs running on some schedule to remove accidentally inserted rows.

    By far, the simplest solution is this:

    • Add a column with an integer IDENTITY value.
    • Set a table constraint where the integer IDENTITY value column has to be greater than zero, and less than 2.

    The code example below demonstrates the simplicity of this approach.

    -- Use a scratch pad, don't make permanent database changes for a test
    USE tempdb;

    -- Create a table with an IDENTITY column and a CHECK constraint
    CREATE TABLE [dbo].[MetaDataTable]
      (  [RowId]     [INT] IDENTITY(1, 1) NOT NULL 
                 CHECK (([RowId]>(0) AND [RowId]<(2))),
         [MetaData1] [NVARCHAR](15) NOT NULL
         [MetaData2] [NVARCHAR](15) 

    -- Add the First (and should be ONLY) row of metadata
    INSERT INTO [dbo].[MetaDataTable]
       VALUES ('Test, Row 1''Some data');

    -- Verify the data
    SELECT *
    FROM [dbo].[MetaDataTable];

    -- Try adding a second row of metadata
    INSERT INTO [dbo].
    VALUES ('Test, Row 2''Some other data');

    -- Error 547, constraint violation

    -- Clean up
    DROP TABLE [dbo].[MetaDataTable]; 

    A constraint acts quicker and with less impact than a trigger.

  • Project Phoenix: Additional Proposals Receive Awards



    Two more eligible developers and deserving projects have been selected.


    Any proposals submitted but not selected this time will be reconsidered at each upcoming award cycle. (Refer to this to review the award criteria, details, and benefits.)


    In no order of implied importance.


    Michael Peterson, Leesburg, VA

    Class Roster Management for Leesburg Open Arms School. The school currently uses a spreadsheet with a bunch of ugly macros to manage their class rosters.  The information is duplicated from an existing childcare management solution.  The existing childcare management solution backend is SQL Server Express.  I would like to build them a solution with a separate database (so that software upgrades don’t affect it) that links the child record back into the childcare management database.  There will be a service layer built using WCF that abstracts all the data access code from the front end with various interfaces to plug in different backend integration.  The front end will be a rich UI built using WPF with the ability to do things like move a child from one class and to another using ‘drag and drop’.   The primary technologies that the project is expected to use are: WPF, WCF, MSSQL.


    Gary Chin, Newton, MA

    A Sunday School Classroom Aid for the Boston Chinese Evangelical Church (  I plan to implement a Silverlight application that would be a web application or a web part to SharePoint for the purpose of listing Sunday School students in various classrooms, provide attendance, identify potential non-attending students and possibly store classroom training material.. The primary technologies that the project is expected to use are: Silverlight 4, Expression Blend 4.0, SharePoint 2010 and possibly PowerPivot.


    Congratulations to Michael and Gary. These both seem to be very useful and valuable projects. The  Details about your awards will be forthcoming in email.


    You will be receiving the following:



    We are encouraging both Michael and Gary to host their projects on so that other developers and non-profits can benefit from their efforts.


    Consider helping a non-profit, school, or church by offering your skills. See this for more information.

More Posts Next page »
Privacy Statement